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.
Planning Ahead
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.
The Move
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.