Last March, I wrote a four-part series for this newsletter called "When Companies Merge". Since then, many of you have asked me to discuss an important topic that I omitted in the series. You'll recall that company ABC.COM acquired XYZ.COM, and we needed to integrate the two companies' messaging systems. I covered several requirements that the project delivered, but I didn't include details about the final step of moving mailboxes from XYZ.COM to ABC.COM. Therefore, let me provide you with a belated "When Companies Merge: Part 5."
At the point we begin our discussion, we've already migrated the Windows 2000 Active Directory (AD) accounts from XYZ.COM into the ABC.COM AD forest, but the accounts still point to mailboxes located on XYZ.COM Exchange 5.5 servers. (These are mailbox-enabled accounts that have a home Exchange server/mailbox in a separate trusted forest.)
We need to migrate mailbox data from XYZ.COM's Exchange 5.5 mailboxes to new mailboxes located on ABC.COM's Exchange 2000 servers. We can use several methods for this process. One option is to provide minimal mailbox migration: Create a mailbox in the new organization (ABC.COM) but don't move any of the data between the old and new mailboxes. We simply export legacy mailbox data to a personal store (.pst) file and let users do what they want with the data. This option makes life easier for the Exchange administrator; however, the user experience might be a bit unsatisfying.
To provide a better user experience, we must look at methods to actually migrate mailbox data from XYZ.COM mailboxes to new ABC.COM mailboxes. Many third-party vendors, such as NetIQ, have tools available to not only migrate Windows accounts but also to migrate mailboxes and mailbox data. In many cases, these tools are the ideal solution for this scenario but come at some cost (both in terms of software and implementation). However, Microsoft also provides some free tools that will do the job. If you only need to move mailboxes between servers, the Microsoft Management Console (MMC) Active Directory Users and Computers snap-in can manage the task (Exchange Tasks, Move Mailbox). However, this snap-in doesn't work for mailbox moves between organizations. For cases such as ours, Exchange development has provided the Exchange Migration Wizard. Only the Exchange 2000 Service Pack 1 (SP1) version of the wizard helps here, though. The SP1 version supports mailbox moves from an Exchange 5.5 organization to an Exchange 2000 organization. The next release of the Exchange 2000 Migration Wizard will hopefully add support for interorganizational Exchange 2000-to Exchange 2000-mailbox moves as well (most of the third-party tools support all forms of mailbox moves between different organizations and versions of Exchange). For now, if you're moving from Exchange 5.5 to Exchange 2000, the Exchange 2000 SP1 Migration Wizard will certainly do the trick.
Moving mailbox data is only part of the migration task. We must also provide continuity during the migration process and legacy support after migration is complete. We must provide mechanisms that let users in both organizations send and receive mail after we've moved accounts and mailboxes, which usually means that we have to add a custom recipient or contact in place of the migrated mailbox in XYZ.COM. Also, after users get their new mailboxes in ABC.COM, they need to be able to reply to old mail (either in a .pst file or mail that has been migrated to the new mailbox). This approach usually requires that we apply a legacy X.500 proxy address to the AD account that represents the old Exchange 5.5 distinguished name (DN). Regardless of the methods and tools, we shouldn't compromise user experience, functionality, and service. If you are embarking on this path, take some time to research and test your options and choose the best approach for your organization.
