Running Exchange 2003 and Exchange 2013 in the same domain: available alternatives

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 Microsoft 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)


  • 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


  • 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


  • 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:

  1. Deploy Exchange 2013 in a new local domain
  2. Automatically create mailboxes for all your users on the new server
  3. 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)
  4. 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.

Suggested reading CodeTwo Exchange migration for Exchange 2003 to 2010/2013 operational review
Exchange 2013 migration guide and PDF checklist

Tools for Microsoft 365

Leave a Reply

Your email address will not be published.

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>