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 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.
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.
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.
Figure A The Model Wizard allows you to begin creating a virtual model of your network.
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.
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.
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.
In this article, I have talked about some best practices for planning your Exchange Server 2007 migration. In the next part of this article series, I will cover more migration best practices that take place once the planning process is complete.
Got a question? Post it on our Exchange Server Forums!