Choosing an Exchange 2000 Upgrade Strategy

Microsoft announced to partners this week that Exchange 2000 release to manufacturing (RTM) would be delayed until this fall (see more in the news section below). Based on feedback from Joint Deployment Partner (JDP) customers, the company wants to ensure product quality. With RTM coming this fall, many administrators are focusing on how they will upgrade Exchange 5.5 Server to Exchange 2000. For our site in Redmond, the thought process is complicated: We're lucky enough to have an Exchange 5.5 cluster, which adds a degree of difficulty to our upgrade process.

We have two options for upgrading our cluster: We can bring up an Exchange 2000 cluster, add it to the Exchange 5.5 site, and simply move mailboxes; or we can perform an in-place upgrade of the Windows NT 4.0/Exchange 5.5 cluster to Windows 2000/Exchange 2000.

Initially, the mailbox relocation strategy seemed the most attractive for our organization. We just get some extra hardware, bring up a cluster, move the mailboxes (we have only about 40), and "decommission" the Exchange 5.5 cluster. However, as we looked closer at this strategy, we found some concerns. Because an Exchange 2000 cluster can't be the first server you install into an Exchange 5.5 site (because Site Replication Services—SRS—aren’t supported in a cluster), we would need to deploy another Exchange 2000 server into the site and make it the bridgehead (the cluster is currently the bridgehead). Adding this server to an additional cluster setup makes the mailbox relocation strategy complicated and expensive. Our interest in this approach has waned in favor of the in-place upgrade.

The in-place upgrade process converts the NT 4.0/Exchange 5.5 cluster to a Win2K/Exchange 2000 cluster. At first, this approach looked rather scary to us. The upgrade process, which Microsoft documents in the Exchange 2000 release notes, involves upgrading to Win2K, removing Exchange 5.5, renaming databases and directories, and converting databases. The process is labor-intensive and subject to operator errors. However, you need no additional hardware (assuming your current hardware configuration can support Win2K/Exchange 2000), and you can complete the upgrade process in a weekend (depending upon your information store—IS—size). We're leaning toward this strategy, with hope that the process will be less messy than the mailbox relocation strategy.

We can't take the in-place upgrade approach lightly, however. We have other complications that we need to research and test before we upgrade. For example, our Exchange 5.5 cluster nodes are NT 4.0 BDCs, and we plan to eliminate the domain controller functionality during the upgrade. Also, we need to develop a back-out plan in case the whole process goes sour and we have to revert to the original configuration. The database conversion and upgrade process is perhaps the scariest part. Although we've tested a nonproduction database and the process worked well, we're more cautious about our production IS.

We still have many questions about our upgrade from Exchange 5.5 to Exchange 2000. We have several things to test in the lab before we perform the real upgrade. My guess (and hope) is that everyone planning an immediate move from Exchange 5.5 to Exchange 2000 is going through similar effort to support a successful migration. You might not have the same concerns as we do in our Redmond site, but I'm positive you'll have a similar amount of research, planning, and testing to do for your deployment.