The process of merging data from one Exchange organization to another is, by its very nature, a migration. The...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
circumstances leading up to why you need a migration may vary, and the environments in which the migrations occur will also vary. However, we want to get the mailbox data from point A to point B with the least amount of administrative effort and without focusing on the two messaging systems' interoperability.
A large factor that affects a migration's success is the level of coexistence. If the two organizations can communicate with one another, there are more options than if the organizations can't directly communicate. Most migration scenarios and tools assume that the organizations are able to communicate directly with one another.
In a merger or acquisition scenario, it's a best practice to configure a full messaging coexistence so the mailboxes in both organizations can collaborate as a single organization. The configurations made to facilitate the collaboration will allow you to perform cross-forest mailbox moves between the two organizations.
For example you could use the following high-level migration procedure.
- Create cross-forest certificate trusts.
- Create a two-way trust between the forests.
- Establish mail flow with send/receive connectors.
- Run PrepareMoveRequest.ps1.
- Create New-MoveRequest.
For more on moving mailboxes to Exchange 2010 from other forests, read more on how to manage remote move requests. Identity management tools such as Forefront Identity Manager can be used to synchronize the Global Access List; ADMT 3.2 can be used to facilitate user account migrations to preserve their passwords and security identifier histories.
There are some alternatives if you can't establish any level of coexistence between the organizations. Exchange 2007 and Exchange 2010 provide tools to export and import mailbox data to PST files. Because your source mailboxes are in Exchange 2007, you'd run the Export-Mailbox cmdlet. Your Exchange 2010 destination servers would use the New-MailboxImportRequest cmdlet to complete the process.
There could be more challenging situations, such as a disaster recovery scenario in which the source organization is completely offline and all that remains are database backups or offline copies of Exchange information stores. In these types of situations, you need to use third-party tools; some tools that specialize in these types of data recovery/migration scenarios include the Recovery Manager for Exchange from Dell and the Ontrack PowerControls from Kroll Ontrack.
About the author:
Richard Luckett is a consultant and instructor specializing in messaging and unified communications. He's been a certified professional with Microsoft since 1996 and has 20 years of experience in the public and private sectors. He's a Microsoft Certified Trainer with more than 15 years of training experience with the Microsoft product line and received the Exchange MVP award in 2006, 2007 and 2008. He's also an expert in deploying and integrating Exchange Server and Lync Server. He leads the Microsoft training and consulting practice at LITSG.
Dig Deeper on Exchange Server Deployment and Migration Advice
Related Q&A from Richard Luckett
Some folders in a mailbox on Exchange Server 2013 are not showing up on the folder list in the OWA virtual directory but do appear in other views.continue reading
We have a Client Access Server and Mailbox Server on Exchange 2013 and we want to install an Edge Transport role on another machine. I joined the ...continue reading
How can I enable Outlook Anywhere to allow internal use for all users and external use for only some users in Exchange 2013?continue reading
Have a question for an expert?
Please add a title for your question
Get answers from a TechTarget expert on whatever's puzzling you.