Timing is everything, whether you're ballroom dancing, skeet shooting, or deciding when to upgrade your Exchange Server environment. Many organizations that have resisted upgrading or migrating to Exchange Server 2003 are reconsidering now that mainstream support for Exchange 2000 Server and extended support for Exchange Server 5.5 have ended. But with the next version of Exchange, code-named Exchange 12, looming on the horizon, is migrating to Exchange 2003 Service Pack 2 (SP2) worth the time and effort? Let's consider your options.
Your Options, Pro and Con
Microsoft uses two terms to describe moving between different versions of Exchange. A migration is the process of moving from Exchange 5.5 to Exchange 2003 or Exchange 2000. An upgrade is the process of moving from Exchange 2000 to Exchange 2003, a fairly simple process. For this article I'm going to follow this usage instead of lumping the two terms together. The big difference between these two processes involves changes required to the underlying OS and directory architecture.
Organizations running Exchange 2000 or Exchange 5.5 have three options for moving to newer versions of Exchange, each of which has advantages and disadvantages. One option is to keep running whatever you've got until Exchange 12 ships (most likely sometime in the first half of 2007). You'll avoid spending money on new software for the interim; however, you'll have to have 64-bit hardware for Exchange 12—a requirement your current hardware probably can't meet—and your support options will be limited. (See the sidebar "Support Savvy" for an explanation of Microsoft support options.) If your environment is stable, these limitations might not worry you. But ask yourself what you'll do if Exchange stops working for some reason. For production email systems, having support available is always a good idea. You should carefully evaluate your organization's ability to deal with a serious problem without any support from Microsoft and your organization's willingness to pay for customized support services if necessary.
The second option is to move to Exchange 2003 now or very soon. If you do so, you'll be moving to a supported, stable platform that still has several more years of mainstream support, and you won't have to wait for Exchange 12 to ship. Although moving now might disrupt your existing environment, particularly if you haven't moved to Active Directory (AD), the disruption could also give you an opportunity to make changes to your environment to reflect the best practices now used for Exchange and AD design. These practices have changed significantly in the 6 years since the introduction of Exchange 2000. Bear in mind that this will buy you time, but eventually even Exchange 2003 will hit the end of the product lifecycle, and you'll be facing the same decision.
The third option, which is beyond the scope of this discussion, is to move to another messaging system. Although some companies find that switching to another system gives them more functionality than their current Exchange implementation, no other messaging platform offers features and benefits equivalent to those of Exchange 2003, particularly when you consider the integration between Outlook, Exchange,-Microsoft SharePoint Portal Server, and Microsoft Office Live Communications Server 2003.
One thing you should consider, which I didn't include in the previous calculations, is the role of the Microsoft Software Assurance (SA) program. The idea behind SA is simple: When you buy a product with SA, your license costs are spread across a 3-year period. If new versions of the products you've bought are released during that 3-year window, you get them for free. This can be a good deal in some cases, less so in others.
However, now that Microsoft has articulated a range of planned ship dates for Exchange 12, anyone who buys SA for Exchange 2003 now will get Exchange 12 when it ships. The same is probably also true for the next release of Windows Server, code-named Longhorn Server, if you buy Windows Server 2003 to support your new Exchange implementation.
Migrating from Exchange 5.5
I'm always surprised to hear of uncertainty and complaint surrounding migration from Exchange 5.5 to a newer version, given that Exchange administrators have had to deal with the associated challenges of migration for almost 6 full years. The process of moving mail and directory data from Exchange 5.5 to Exchange 2000 or Exchange 2003 is well understood by now. Microsoft offers a ton of guidance about the process; third parties such as Quest Software make migration tools that greatly ease the burden of the actual migration; and in-the-trenches articles, blog entries, and other helpful resources abound. Having said all that, organizations that are still using Exchange 5.5 probably believe they have good reasons for choosing not to migrate.
Cost is one reason why organizations resist migrating. Spending money to upgrade something that's already working is hard to justify. However, "working" in this context is a bit of a misnomer. The scalability, security, and functionality improvements between Exchange 5.5 and Exchange 2003 are many. For example, being able to recover data to a Recovery Storage Group (RSG), instead of needing a recovery server, is worth the upgrade cost for many organizations, as are the integrated support for wireless access to email and the vastly improved Microsoft Outlook Web Access (OWA) interface. What's more, server consolidation, when properly planned and executed, can drive down the cost of your messaging operations. A 2004 report by Ferris Research (available from http://www.microsoft.com/exchange/evaluation/MigrateLowCost .mspx) pegs the migration cost for moving from Exchange 5.5 to Exchange 2003 at less than $200 per mailbox.
Unfamiliarity with AD is another reason why some avoid migration. True, moving from Exchange 5.5 running on Windows NT 4.0 systems can be complicated, particularly for organizations that haven't used AD.
However, NT passed into the netherworld on January 1, 2005, and most organizations have already done the groundwork to move to AD. Those that haven't are putting their organization's security at risk because Microsoft no longer makes NT security updates broadly available (unless, of course, you've purchased a custom support agreement). In its security documentation, Microsoft vigorously warns against using NT in production networks.
Yet another reason for stalling on migration is the "if it isn't broken, why replace it" argument. Nonprofit organizations, small government agencies, and schools often find that Exchange 5.5 is good enough for what they want to do, so justifying the expense of migrating, given that many new features in Exchange 2003 will probably remain unused, can be difficult. However, such organizations need to realize that the benefits of security and stability are as important in their situations as in enterprise scenarios. There's enough documentation and guidance from Microsoft to make the cost of learning how to do the migration, and how to manage the new environment, minimal. It's true, software licenses drive up costs, and you might have to factor in training expenses for users who are upgrading to new versions of Outlook. However, if you put these costs into context by comparing the potential savings from server and site consolidation to the outlays required for the migration, you'll find that migration comes out ahead.
The migration process requires several steps. I won't go into great detail here, but it might be helpful to check out the articles listed in the Need to Know More? box. Microsoft also has a wealth of documentation (see http://www.microsoft.com/technet/prodtechnol/exchange/2003/up grade.mspx) that explains these steps.
First, if you haven't already installed and set up Active Directory Connector (ADC), you'll need to so that ADC can copy your Exchange 5.5 directory data to AD. Organizations that are running Exchange 5.5 on Windows 2000 have probably already taken this step. (For more information about ADC, see "Get Inside Active Directory Connector Synchronization," February 2006, InstantDoc ID 48589 and "Fine-Tune Active Directory Connector Synchronization," March 2006, InstantDoc ID 49022.)