Issues to be considered while thinking about moving mailboxes to Exchange 2010 using the Microsoft native tools
Below is a table of the issues to be considered while thinking about moving mailboxes using the Microsoft native tools in both the ‘upgrade’ and ‘deployment’ scenarios supported by Microsoft.
Note: If you’re using the Priasoft Migration Suite for Exchange this article does not apply to you.
Exchange 2003 To 2010
- You need to use “move request” cmdlets in 2010 shell to move the mailboxes.
- Move requests are performed by the Microsoft Exchange Mailbox Replication Service (MRS) that runs on all Client Access servers (CAS). Therefore, CAS servers are busy moving mailboxes and not servicing clients’ requests.
- If you implement Exchange 2010 as an upgrade, some features of Exchange 2010 will not be available until the migration is completed and the organization in moved to a native mode state.
- You must never try to manage a 2010 mailbox using a 2003 management tool or snap in
- You can’t use 2003 System Manager.
- You must be careful to use a split administration model while co-existing to not cause problems with migrated objects.
- The mailbox move is offline, which means that the users can’t access the emails while it is moved.
- No roll-back support – If something goes wrong you may need to go back to tape to restore the mailbox
- No support for native tools – if they don’t work they don’t work.
- No Outlook client profile automation for migrated mailboxes. No automatic enabling of RPC encryption for Outlook 2003 based clients. You will need to do them manually or you will need to disable RPC encryption on Exchange 2010 (not recommended)
- No Public Folder migration tools
- No distribution group migration tools
- You can’t move mailboxes if running Exchange 2003 SP1 or earlier, you must update all servers to 2003 SP2+
- You can’t perform message tracking configuration tasks between Exchange 2010 and Exchange 2003
- You must use Exchange 2003 messaging tracking tools within your Exchange 2003 organization, and Exchange 2010 messaging tracking tools within your Exchange 2010
- Side-by-side management for Exchange Server 2003 and Exchange 2010 management tools isn’t supported, because Exchange Server 2003 management tools can only be run on 32-bit machines
- In order to do Cross-forest move requests must create mail-enabled users with the required attributes in the target forest or it won’t work
- Depending on the scenario you just may be able to preserve mailbox folder delegates and send-on behalf of delegates
- If upgrading, you must run the setup /PrepareLegacyExchangePermissions command so that the Exchange 2003 Recipient Update Service functions correctly
- If upgrading, you are required to update the Active Directory schema for Exchange Server 2010
- If upgrading, you must Upgrade Custom LDAP Filters to OPATH Filters
Exchange 2007 To 2010
- You can use 2010 console or “move request” cmdlets in 2010 shell to move the mailboxes.
- If you implement Exchange 2010 in mixed mode, some features of Exchange 2010 will not be available until the migration is completed and the organization in moved to a native mode state.
- Move requests are performed by the Microsoft Exchange Mailbox Replication Service (MRS) that runs on all Client Access servers (CAS). Therefore, CAS servers are busy moving mailboxes and not servicing clients’ requests.
- You can’t use “move-mailbox” cmdlet in 2007 shell.
- No roll-back support – If something goes wrong you may need to go back to tape to restore the mailbox
- No support for native tools – if they don’t work they don’t work.
- The mailbox move is online, which means that the users can be online while the move happens.
- You can’t move mailboxes from 2007 SP1 or earlier, the source should run 2007 SP2+
- Exchange 2007 Mailbox databases can’t be managed from the EMC in Exchange 2010
- No Public Folder migration tools
- No distribution group migration tools
- No Outlook client profile automation for migrated mailboxes. No automatic enabling of RPC encryption for Outlook 2003 based clients. You will need to do them manually or you will need to disable RPC encryption on Exchange 2010 (not recommended)
- The EMC in Exchange 2010 can’t manage Exchange 2007 mobile devices
- Exchange 2007 Mailbox databases can’t be managed from the EMC in Exchange 2010
- You can’t use message tracking configuration tasks between Exchange 2010 and Exchange 2007
- You must use Exchange 2007 messaging tracking tools within your Exchange 2007 servers, and Exchange 2010 messaging tracking tools within your Exchange 2010 servers.
- Exchange 2010 and Exchange 2007 servers can only be viewed from their corresponding version of the EMC
- In order to schedule Cross-forest move requests must create mail-enabled users with the required attributes in the target forest or it won’t work
- If upgrading, you are required to update the Active Directory schema for Exchange Server 2010
- Depending on the scenario you just may be able to preserve mailbox folder delegates and send-on behalf of delegates
Exchange 5.5 And 2000 To 2010
- Not supported by Exchange 2010 native tools
- If you want to move to Exchange 2010 using native tools from Exchange 5.5 you must first migrate to Exchange 2003/2007 then to Exchange 2010
- If you want to move to Exchange 2010 using native tools from Exchange 2000 you must first migrate to Exchange 2003/2007 then to Exchange 2010
In short, it’s not as simple as tossing in a CD. Can it be done? Sure, would we want to do it? Nope.
We highly recommend you consider the resource forest model for Exchange 2010 to avoid trying to mix the old with the new. This model, in our opinion, allows the most flexibility during migration, allows you to build your Exchange organization to your needs, and provides benefits well into the future. It also helps to reduce risk. Something we all like!
This is not a complete list of issues nor should it be used as a roadmap to moving to Exchange 2010. We are providing this simply as a comparison and we do not take any responsibility whatsoever for the information contained. You are encouraged to do your own due diligence and research.
Ready to Talk Through Your Migration?
Priasoft has been handling Exchange and Microsoft 365 migrations since 1999. Whether you're scoping a new project or recovering from a stalled one, our engineers have seen it before. No sales pitch — just a working conversation with people who have done this work at scale.

