Migrating your existing Exchange organization to Exchange Server 2010 can seem like a complex process, but with the right approach it doesn’t need to be difficult.
In this article I will break down the Exchange 2010 migration process into five stages that will make it easier for you to manage, which will help you to deliver a successful Exchange 2010 upgrade for your customers.
The Planning Stage
A successful migration to Exchange Server 2010 begins with the planning. This stage of the project involves discovering all of the important business and technical details that will guide the direction that the overall project takes.
A lot of these details can be collected using tools such as the Exchange Profile Analyzer and Exchange Pre-Deployment Analyzer. However some of it can only be discovered by actually talking to people within the business about the tasks and business processes that they rely on email for.
The information that you collect is then used along with the guidance on Microsoft’s website to create the design of your Exchange 2010 environment.
Download a free, comprehensive Planning Guide for upgrading to Exchange Server 2010 right here:
- Planning guide for Exchange 2003 to 2010 Migration
- Planning guide for Exchange 2007 to 2010 Migration
The Deployment Stage
When your design is completed you can start the deployment stage of the project. This stage involves installing each of the Exchange 2010 server roles in your environment, and then configuring them according to your design.
During the deployment stage there is a small risk that you will make a change that causes an impact to your existing Exchange environment, possibly even causing an outage for your customers. But as long as you are aware of the specific risks and take the right steps to avoid them you can complete the deployment stage without incident.
The Testing Stage
After the new Exchange 2010 servers have been installed the testing stage can begin. This is an important project stage because it will identify any problems before they have a change to impact production systems or end users.
Testing should cover off each of the technical and business requirements that were discovered during the planning stage, or at least the most business critical ones.
One test that should always be performed is Exchange 2010 backup and recovery. Before any production mailbox migrations take place it is essential that full functioning backups are in place for the Exchange 2010 servers.
The Migration Stage
Now that the Exchange 2010 deployment has been thoroughly tested the migration stage of the project can begin.
There are two migration approaches that can be used. The first is co-existence, in which mailbox data is migrated over a period of days, weeks or even months. The second is a full migration, for example in a single weekend, which is possible for smaller environments.
The co-existence approach requires some additional set up steps, such as configuring the legacy namespace, so that remote access methods such as Outlook Web App (OWA) and ActiveSync work for users with mailboxes on both versions of Exchange during the migration.
But if the entire migration can be done in a single window of time then there may be no need to set up co-existence, and a full migration is often the better approach in those scenarios.
The Decommission Stage
When all of the mailboxes, public folder data and services have been migrated to Exchange Server 2010 then the decommission stage of the project can be started.
Decommissioning is not as simple as just shutting down the old Exchange servers. There are a series of steps required to ensure that features such as the Offline Address Book and the Email Address Policies continue to work correctly.
The old Exchange servers also need to be cleanly removed from the environment so that no legacy issues remain.
Once all of the decommission steps are complete the Exchange organization will have been successfully upgraded to Exchange Server 2010.
For more detailed guidance on upgrading to Exchange Server 2010, including step by step instructions for each stage of the migration process check out the Exchange Migration Guides: