Manage Learn to apply best practices and optimize your operations.

Five commonly overlooked aspects of Exchange 2010 migrations

Are you planning an Exchange 2007 to Exchange 2010 migration? If so, make sure to remember these five items that aren’t covered in Microsoft documentation.

A migration from Exchange Server 2007 to Exchange 2010 should be a straightforward process, but it’s easy to neglect important steps. Here are the top five items that Exchange Setup does not make clear and are most often overlooked during migrations.

1. Make sure all third-party products are compatible with Exchange 2010.
Don’t forget about Exchange-related third-party products when planning your Exchange 2007 to Exchange 2010 migration. I once witnessed an organization successfully work through the entire migration process only to discover that its antispam product didn’t work with Exchange Server 2010. Similar problems can also occur with antivirus and backup applications, archiving products and management tools.

2. Plan for coexistence.
If you read Microsoft’s Exchange 2007 to Exchange 2010 migration documentation, a lot of emphasis is placed on coexistence. Even so, many organizations that run Exchange Server think they can ignore the coexistence-related part of the documentation if they migrate all of their mailboxes to Exchange Server 2010. The problem is Microsoft does not allow in-place upgrades from Exchange 2007 to Exchange 2010. Migration is the only option.

You cannot get around the coexistence period, even if the two versions only coexist for a couple of hours. You must plan for coexistence, even if it is only for the short-term.

3. Step out your migration
Because the migration process is so straightforward, small- and medium-sized Exchange shops often complete the process in a single night or over the course of a weekend. While quick migrations are feasible, they are not always the best idea.

Certain aspects of your Exchange Server infrastructure may not function correctly after you’ve completed the migration. One of the first rules of troubleshooting is that when problems occur, first check for any recent changes in your Exchange infrastructure. A migration to Exchange 2010 will alter numerous aspects of your network. These changes can make it difficult to troubleshoot post-migration problems.

Be methodical about your migration and complete the process in phases rather than all at once. For example, the first step in the migration process is to make sure that all of your Exchange 2007 servers have Service Pack 1 or above. If you haven’t installed Exchange 2007 SP1, do so and make sure that your Exchange 2007 servers are stable and functional before proceeding.

Likewise, when the upgrade completes, you may be tempted to immediately move your end users’ mailboxes to Exchange 2010. Instead, first verify that your Exchange organization is properly functioning after the upgrade, then perform a few pilot mailbox migrations. This way, you make sure everything works correctly before you move all the mailboxes.

There are some migration steps you can delay until you make sure everything is working correctly. Perform the migration in stages to facilitate troubleshooting in the event that anything does go wrong.

4. Don’t forget about split DNS
During an Exchange 2010 migration, domain name system (DNS) entries change. Microsoft provides plenty of guidance in this area, but most of the documentation does not mention split DNS. Not all organizations use split DNS, but if you do, remember to modify both your internal and external DNS entries during the migration process. If you don’t, internal users will get redirected to Exchange 2007, and external users get directed to Exchange 2010, or vice versa.

5. Be cautious when repurposing old hardware.
I recommend virtualizing your Exchange 2010 servers whenever possible. However, if you use physical servers, be careful about repurposing your old Exchange 2007 servers after they are decommissioned.

Organizations often perform leapfrog migrations where one server is migrated at a time; meaning then the old server is decommissioned, reformatted and used for the next phase in the migration process. Exchange Server 2010 needs more memory and CPU resources than Exchange 2007 did, so if you plan to re-purpose your old servers, make sure they can handle Exchange 2010.

Brien Posey is a seven-time Microsoft MVP with two decades of IT experience. Before becoming a freelance technical writer, Brien worked as a CIO for a national chain of hospitals and healthcare facilities. He has also served as a network administrator for some of the nation’s largest insurance companies and for the Department of Defense at Fort Knox.

This was last published in October 2011

Dig Deeper on Exchange Server setup and troubleshooting

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.