Let's say, for the sake of argument, that the decision has already been made: Your company is moving its messaging infrastructure to a hosted Microsoft Exchange Server provider. The pros and cons have been weighed, and outsourcing has won the day. You might not have been in favor of the decision, but as the resident messaging expert, the migration project falls squarely in your lap. So let's take a look at what you can expect to find during the process and see how you should prepare to make your migration to the cloud run smoothly.
As a first step, you'll want to have a clear picture of your current network and messaging infrastructure and know what your needs are going to be going forward. You'll need to figure out how much legacy data you'll be moving over to the hosted service because that will determine both how long the migration will take and what migration methods you'll use. This might be a good time to consider whether you need to maintain fifteen years of email correspondence or only two or five.
As Exchange expert Tony Redmond said, "You need this intense data gathering exercise to understand just what happens inside your internal network before you even have that initial discussion with the hosted provider and say, 'We've got this huge mess inside our internal network and we'd like to make you responsible for it and we'd like you to deliver 99.999 percent uptime.' You haven't got a hope in hell of having an intelligent discussion unless you know what you're talking about." The larger an organization is, the more complicated the systems are likely to be and the more data they're likely to have—and the less likely it is that the organization has a clear picture of how it all fits together.
Keep in mind any custom or third-party applications or add-ons that you're currently running in conjunction with your messaging system, and check with your chosen hosting provider to make sure they'll still work. Depending on how they integrate with Exchange or Outlook, they could pose a problem with the migration or simply not be usable with a hosted version of Exchange. Larger organizations are more likely to run into this type of problem, but if you have such an application that's mission critical to some segment of your company, you'd better have a plan in place to replace or rewrite it before moving forward with the migration.
There's a lot of technical content that needs to be spelled out during the contract negotiation, so it's important that the IT department is involved in this process from the beginning. Of course, the service level agreement (SLA) is a huge part of the contract, and your legal department will no doubt have much to say about it—but ideally they'll use the IT department's input. You should also verify what provisions the hoster has in place for procedures such as e-discovery—do their timelines for providing necessary data match your expectations or requirements? "This is the kind of example that you've got to think through as you establish a contract with the hosting provider," Redmond said. "You can't afford to just assume that everything is going to be normal, that operations are going to continue smoothly. You are going to have hiccups." It's best to consider these issues up front—before the contract is signed—so that you can avoid nasty surprises later on.
Another key point Redmond suggests you take into account is having a back-out plan. It could be dissatisfaction with the provider; it could be budgetary; it could be changes in your company's legal or security requirements—you don't know what it will be going in, but at some point you might need to move away from this hosting provider. How will you get your data out and how long will it take? What assistance, if any, can you expect from the hoster to perform the anti-migration? This probably isn't a point that hosting providers will be eager to discuss with you; nonetheless, if you can get all of this spelled out in your contract, you might save a lot of headaches down the line.
For most organizations, the migration is probably going to involve exporting data from your current Exchange servers and transferring them to the new host. However, larger and more complicated moves could involve setting up dedicated data pipes and installing agents to synchronize the systems before cutover. As hosted services provider Intermedia COO Jonathan McCormick said, "Migration looks different for a three person or ten person company than it does for a hundred person company." Imagine how different things are going to look for a 1,000 seat or 10,000 seat organization.
Most organizations, however, will have a simpler path, and the hosting provider should help you determine the most effective method to move your data and give you a good idea of how long that process should take. James Bond, vice president of product and software development for hosted services provider Apptix, said, "Apptix—and most every other hoster as well—one way or the other, will walk the customer through doing a mass export, such as ExMerge in Exchange, with a massive dump of all the users." For the smallest organizations, it might be possible to send the exported data to the hoster over the Internet, but most companies will find it more expedient—as well as what the hoster recommends—to store the data to a portable hard disk and ship the unit to the hoster. "Frankly, it's faster to send a couple hundred gigabytes on a hard drive than it is to try to fit that over the Internet," Bond said. "Regardless of the bandwidth that they have on their side, it's not fast enough."
Exchange hosters should be responsible for recreating your Exchange organization in their data centers based on the information you've given them. When they receive your data, they'll upload it into the new infrastructure so that it's ready for your users to access. Next, you'll need to determine the appropriate time for the cutover to the hosted system, which essentially is accomplished by changing the MX record to point to the new host's system. You should try to schedule the cutover at a time when it will have the smallest impact if something goes wrong. The final step is a differential export of any new data since the first, major export, and uploading that data to the hoster.
How long the migration takes will vary based on the size of your organization and the amount of data you need to transfer. McCormick said that for typical medium-sized businesses that are migrating historical data and an Active Directory (AD) structure, Intermedia expects its full-service migration to take two weeks. For larger or more complicated organizations, naturally it will take longer. For instance, Apptix's Bond told me about a 100,000 seat Exchange migration that was scheduled out over six months and involved split domains and moving discrete segments of the user base at different times.
This added complexity is likely a factor keeping many large organizations from moving to hosted Exchange. As Redmond said, "If you're a large company that's been around for a while, there are all sorts of artifacts that are going to get in the way. If you're a small company, you can make it happen. The small company, too, tends to be a little bit more flexible. The sheer number of people in a large company creates this drag—it's like the Titanic Effect. How quickly can I move around the iceberg? You know, if you're a small, little company, you can quickly zigzag. The Titanic, as reality proved, took a little longer and didn't quite get there."
One of the biggest trends from hosted Exchange providers currently is offering some form of migration assistance package. "The industry today has seen mostly early-technology-adopter types, and they're self-doers. A lot of those people are fine with their own migration even if they have to do a lot of manual effort," McCormick said. "But more and more, as we move to the mainstream and the masses come to the cloud . . . they require the full-service migration."
Intermedia has been ahead of the curve in this area, offering a free Exchange Concierge service with dedicated staff for migration assistance, but the field is catching up. Pay close attention to exactly what your provider offers. Some will provide only phone support; others might offer on-site support but at an additional fee; some might have documentation or training materials both for IT staff and end users. Apptix, too, has focused on this customer service angle. "The trend used to be, it was hands off. You never talked to us. Those days are changing a lot," Bond said. Now, he said, "we go onsite sometimes and are talking to the executives of the company, teaching them how the migration strategy is going to go because they want to hear from us."
The version of Exchange you're currently on and the one you're moving to can also have an impact on the difficulty of the move. As Redmond said, "If they're coming from Exchange 2003—which, let's remember, a lot of people are still using Exchange 2003, despite Microsoft's best efforts to make them move to a more up-to-date platform—for those guys, it's a little bit more complex." Also, if you're migrating from a mail system other than Exchange, you can probably expect the process to be more difficult and the Exchange service provider might have little or no migration assistance to offer. In that case, your hosting provider might put you in contact with an outside consultant or point you to third-party tools for data conversion, but those will be your additional expenses.
What You Do Next
Keep in mind that outsourcing your Exchange infrastructure doesn't have to mean the end of your IT job. There are still messaging tasks that need to be managed inhouse, and unless you're that rare case of a dedicated Exchange administrator, you probably have many other IT tasks to focus on as well. How you manage the migration project can show how important you still are to your company's goals.