Best Practices for Exchange Server Migrations

Any time that I think about server migrations, I always have to cringe a little bit. I’m not anti-progress or anything, it’s just that my memory always reflects the way that we used to do migration at a company that I worked at in the early 1990s. Although it was a large, enterprise environment there always seemed to be a haphazard approach to migrations. Typically, when we needed to perform a large-scale migration, the IT staff would arrive early on Saturday morning with software licenses and caffeine in hand, and hope that we could ever written functioning by the time that everyone showed up for work on Monday morning.

Obviously, this type of approach simply is not acceptable today. Network servers are far more important to companies today than they were back then. As such, migrations need to be handled in a way that ensures their success, and that limits any disruption to the business processes. Having performed my share of migrations to Exchange Server 2007, I wanted to take the opportunity to share with you some best practices for the migration process.

Before I Begin

Before I get started, I just want to point out that the information I’m about to share with you does not come from any sort of Microsoft best practices guide. The techniques that I will be discussing are based solely on real world experiences.

A Multi-Step Approach

Rather than taking the old-school approach of getting hyped up on caffeine, and trying to knock out a migration and a weekend I tend to think that a more controlled, multistep approach works better. In the remainder of this article, I will be discussing the steps that I recommend taking in the migration process.

Step One: The Plan

The first thing that I recommend doing the migration process is going over your existing network architecture with a fine tooth comb. This means taking a honest look at how the Exchange servers on your network are currently performing, what the current exchange routing topology looks like, and what network resources are available. Only then can you determine how the migration process is going to affect your network, and what your hardware needs are going to be.

Once you come up with a plan for how you intend to bring Exchange Server 2007 into your Exchange Server organization, I recommend testing the plan. Unfortunately, you aren’t going to be able to use LoadSim or any of the other performance monitoring utilities to measure the impact of the upgrade, because the upgrade has not happened yet. Even so, there is a viable way in which you can perform some initial testing.

Microsoft offers a free utility called the System Center Capacity Planner. This tool allows you to create a diagram of your network and then use that diagram as a tool for simulating how your network will perform.

I will be the first to admit that the System Center Capacity Planner is one of those tools for which you get out exactly what you put into it. Creating an accurate depiction of your network involves a whole lot of work. If you do put the work in though, and create an accurate model of your network infrastructure, then the tool is invaluable because it allows you to experiment with a number of what if scenarios. Not only can you determine how well your proposed changes to the network are going to work out after the migration is complete, you can experiment with other designs, and even see what effect future network growth is going to have on your proposed design.

If you look at Figure A, you can get an idea of what the System Center Capacity Planner looks like. In this particular screen capture, I am using the Model Wizard to begin constructing a model of my network. I will probably end up covering System Center Capacity Planner in more detail in a future article series, but for now though you can at least get an idea of what the tool looks like. As you can see, this is a fairly advanced tool.

Hopefully from the figure you can tell that the System Center Capacity Planner is easy to use, but that it is also very tedious. There is a lot of work involved in creating an accurate model of your network, or of your proposed network.

Step Two: Create a Prototype

The next thing that I would recommend doing would be to create a prototype of your proposed deployment. Unless you have a lab that perfectly mimics your production network, you won’t be able to fully test your deployment plan. Even so, I would still recommend taking the time to set up a few lab servers, and configure them as similarly as possible to the way that your production network is configured. Once you have done so, you can bring Exchange 2007 into the mix and perform some trial migrations. This will give you some experience with the migration process, and depending on how closely your lab environment mimics your production environment, it may help you to figure out how to work through any glitches in the migration process.

Step Three: Administrative Training

Once you have a lab network in place, and you have performed a sample Exchange 2007 migration, and I would recommend using the lab for training purposes. Exchange Server 2007 is completely different from Exchange 2003, and this seems to catch some administrators off guard. In fact, I recently saw a real life situation in which an administrator successfully performed a migration to Exchange 2007 only to realize that he did not have a clue as to how to perform the day-to-day administrative tasks in the new environment. It is therefore critical to make sure that the administrative staff is trained on managing Exchange Server 2007.

Step 4: Focus on the Clients

Your users aren’t going to get the full benefit of your Exchange 2007 migration unless they are running Outlook 2007. An upgrade to Office 2007 isn’t an absolute essential, but it is a good idea, and pretty much every company that I have assisted with the migration process has adopted Office 2007 as a part of that process.

One thing about Office 2007, and Outlook 2007 in particular, is that you don’t have to wait until you perform the Exchange Server migration to deploy it. In fact, I personally use Outlook 2007, even though my mailbox is on an Exchange 2003 server.

One of the best things that you can do to ensure a smooth migration is to go ahead and get your users trained on Office 2007, and then deploy it. Training is important, because the Office 2007 user interface is quite a bit different from the one used by previous versions of Office. If you are not familiar with these differences, then you can see what the Outlook 2007 user interface looks like in Figure A.

The reason why I suggest moving forward with the upgrade to Office 2007 is that it will give your users time to get used to the new version of Outlook before you actually perform the Exchange Server migration. That way when you do eventually migrate the user’s mailboxes to Exchange 2007, the change won’t be quite so dramatic.

I also recommend going ahead and putting Outlook 2007 in place ahead of time because Outlook 2007 contains an automatic discovery mechanism that will automatically detect the location of the user’s Exchange mailboxes. This helps to simplify things after the migration since Outlook will be able to automatically detect the mailbox’s new location.

Step 5: Research Potential Side Effects

The next thing that I recommend doing is to take some time to research some of the side effects to bringing Exchange 2007 into your existing Exchange Server organization. There are a number of Exchange 2000 features that were discontinued when Microsoft created Exchange 2003, and there are also a number of Exchange 2003 features that Microsoft dropped in Exchange 2007. In most cases, you can continue to use the discontinued features by leaving a legacy Exchange Server in the organization, but that is not always the case. Some legacy Exchange features are completely incompatible with Exchange 2007. You can find a list of the discontinued and deemphasized Exchange 2007 features here.

Step 6: Perform a Pilot Deployment

The next step that I would recommend performing is a pilot Exchange 2007 deployment. Ideally, you should perform the pilot deployment in a lab environment. The lab should be configured to mimic your current domain controller and Exchange Server configuration. You can then experiment with installing Exchange 2007, and moving mailboxes to the Exchange 2007 server. This will allow you to get a feel for the migration process before you have to perform it in a production environment, and may also help you to spot any potential gotchas ahead of time.

If your company does not have the resources for a full blown lab deployment, then I recommend going ahead and bringing an Exchange 2007 server into your production environment (assuming that you have done the proper planning and made backups). You can then either set up some dummy mailboxes to experiment on, or you can pick some users with non critical job functions and migrate their mailboxes as a part of a pilot deployment.

Step 7: Move Forward with the Migration

By now you should be ready to move forward with a full blown migration. There are two pieces of advice that I would give you prior to the migration though. First, you should make a full system state backup of your existing Exchange Servers and your domain controllers prior to the migration.

The other thing that I would advise is scheduling some down time if possible and running a database integrity check on your existing Exchange servers before you start migrating mailboxes. This can step is a pain, but it can save you from a failed migration related to unexpected database corruption.

Conclusion

Having a roadmap is essential to the migration process. This article series has laid out the steps that you need to perform in order to have a successful migration.