Last week, I talked a bit about some tools for migrating to Exchange Server from other messaging systems. This is currently a hot topic as Microsoft and IBM Lotus fight it out for total domination in the collaboration space, but there's actually more action in the Exchange Server 5.5 migration space. A surge of migration activity occurred last year as companies rushed to move away from Exchange 5.5 before it hit the end of its 10-year support cycle; after January 1, 2006, customers still running Exchange 5.5 must buy custom support contracts if they want support. Naturally, this has spurred many of them to accelerate their Exchange Server 2003 deployment plans (arguably something that should have been considered last year, before Exchange 5.5 went end-of-life!)
I recently met with a new client company that retained me to help it come up with an Exchange 5.5-to-Exchange 2003 migration plan. It's a financial services company with about 500 mailboxes spread across 13 servers in five sites on two continents. This isn't a huge environment, but it's more complex than most similarly sized sites because it uses replication software to provide disaster-recovery capability to a remote site and because it has a fairly complex SMTP routing structure that doesn't rely on Exchange.
After my initial meeting with the company, I was impressed by some things the technical staff had done--and not done--to make the migration process as smooth as possible. - They did their homework. When I arrived, they'd already spent a good deal of time reviewing my design proposal, and they asked detailed questions that showed clearly that they had read up on the process. Research is almost always free, and Microsoft spends a huge amount of money building free technical content that you can absorb to help make your own migration projects smooth. - They knew what they wanted. Many companies never define an explicit service level agreement (SLA), so they're at the mercy of whichever group of users yells the loudest. This company had a clear SLA that defined what service levels were required for normal working hours, weekends, and holidays, and which groups of users it applied to. This made it much easier to build a design that delivered the required service levels without wasting time or money. - They asked lots of questions. Although they'd invited me to participate as an outside expert, by no means did I get a free pass from questions. I had to be able to justify every point of the proposed design, indicating both the high degree of preparation and their clear understanding of what they wanted. My job was to tell them how to get there, and their questions helped move us all to that end. - They got their hands dirty. Before I ever met with them, the administrators had spent time trying different things in a test lab. They already knew that their proposed iSCSI SAN configuration would work for SAN booting, for example. This let our discussions focus on how to find the best possible configuration, not on guessing what would or wouldn't work. 5. They didn't rule anything out. The technical staff at this company had some clear preferences for how they wanted the new Exchange environment to look, but in my discussions with them, it quickly became clear that their number one goal was to keep the users happy and productive. As we occasionally uncovered business requirements that forced changes to the Exchange design, they made the needed changes and moved forward. No time, energy, or money was wasted on arguing or fighting over changes that could ultimately be overruled by the business folks who were signing the checks. 6. They didn't rush things. Even though they were very, very interested in moving to Exchange 2003 as quickly as possible, they took the time to plan a series of short pilots that helped them simultaneously build experience with Exchange 2003 and validate various aspects of the design. This approach let them move from success to success without unnecessary delays.
At this point, you might think that this is an unfair portrayal of an organization with lots of budget and a deep bench of talent. However, you can apply the same principles to your own Exchange environment even if you're on a shoestring budget or face technical or political constraints that slow things down. Given the huge amount of migration documentation out there, where should you start? My recommendation is simple: Run the ExDeploy tool from the Exchange 2003 CD-ROM (or download it from http://www.microsoft.com/downloads/details.aspx?familyid=271e51fd-fe7d-42ad-b621-45f974ed34c0&displaylang=en) and see what it tells you about your environment. If you don't understand the reports it generates, use that to guide your research; as you review ExDeploy's recommendations, you can tailor your design to reflect your needs. If there are holes in your plan, ask questions (either in public forums or of your favorite consultant) to help plug the holes. Doing these things instead of rushing headlong into an ill-planned migration will give you the best results in the long run.
