Running Exchange 2003 and Exchange 2013 in the same domain

Exchange 2003 and Exchange 2013 in one domain: is it possible?

Before we get into any details, one thing should be made clear – the only true answer to the question “Is it possible to run Exchange 2003 and Exchange 2013 in the same domain” is “no”. Coexistence between Exchange 2003 and Exchange 2013 is flat out impossible – no “buts” or “howevers”, and neither are there any workarounds or patches. But this leaves us with a new question: what are the closest alternatives?

If you’ve ever tried to install Exchange 2013 in a forest, which contains servers running Exchange 2003, you already know that in this scenario the Readiness Checks tool always returns an error (like the one on the image below) and does not give you an option to proceed. Any further attempts to run Exchange 2003 and 2013 in one domain will just leave you ending up in the same blind alley. See this TechNet post for more.

Exchange 2013 setup Readiness Checks after detecting an Exchange 2000 or 2003 installation in the domain

You have to migrate to Exchange 2013 somehow, though. So what’s next?

First let’s get the most arduous methods out of the way:

PST file export and import (e.g. using ExMerge)

Drawbacks:

Exports and imports must be done manually on a user-by-user basis
Free tools like ExMerge come with many limitations (maximum 2 GB PST size, risk of data loss, etc.)
LegacyExchangeDN X.500 and X.400 addresses have to be converted manually user-by-user
Public folder permissions are not migrated
Major impact on service availability
Risk of delivery issues following the migration

EDB file export and import

Drawbacks:

No direct Exchange 2003 to Exchange 2013 path
Necessary conversion to PSTs and then user-by-user import
All limits and risks related to using ExMerge

Cutover cross-domain migration using PowerShell

Drawbacks:

A massive amount of PowerShell scripting
Required downtime period

Due to the extensive effort needed to apply the above methods, they should only be attempted if your budget for the migration is minimal. Otherwise, you should consider employing more user-friendly approaches, such as:

Double-hop migration

The most often suggested upgrade path, given that doing in-place upgrades to Exchange 2010 and then to Exchange 2013 is not supported.

The main advantages of this method are that you can do it within your existing domain, and with little or no impact on end-users. The latter is achieved thanks to the possibility of maintaining coexistence Exchange 2003 – Exchange 2010 and Exchange 2010 – Exchange 2013 deployments.

The downside is that, unless you had Exchange 2003 running on a high-end server, you will most likely have to purchase separate boxes for the Exchange 2010 and Exchange 2013 installations. Additional considerations: purchasing a throwaway upgrade to Exchange 2010 and installation of all Exchange 2010 service packs.

Cutover migration using CodeTwo Exchange Migration

An efficient option that’s completely invisible to end users:

Deploy Exchange 2013 in a new local domain
Automatically create mailboxes for all your users on the new server
Use CodeTwo Exchange Migration to replicate the Exchange 2003 users’ mailbox contents in corresponding Exchange 2013 mailboxes (you can do it in one go or perform an initial migration during the day and a differential sync during off-work hours)
Rewrite all MX records to point to the Exchange 2013 domain. Make sure to also direct all other services and appliances (e.g. firewall gate) to the new machine’s IP address.