Planning and Migrating a Small Organization from Exchange 2003 to Exchange 2013 (Part 1)

If you would like to read the other parts in this article series please go to:


If your organization is still on Exchange 2003 and you are eager to upgrade, you are certainly not alone.Although there is not a direct upgrade path from Exchange 2003 to Exchange 2013, a migration can still be straightforward. In this series we’ll examine how to plan and perform this migration.

Our Example Organization

Current Exchange 2003 Organization

Our example organization is Lisa Jane Designs, a craft company that employs 500 people. The organization wishes to provide larger mailboxes, provide simple High Availability as well as take advantage of end user improvements in Exchange 2013. The current relevant topology is shown below:

Figure 1: One site with AD domain controller, FE and BE servers

Target Exchange 2013 Organization

Our target Exchange 2013 organization will make use of low-cost physical hardware to provide high availability using a small number of servers. After migration, our infrastructure will be as shown below:

Figure 2: One site, AD domain controllers, two DAG nodes


There’s more than one way to approach a migration to Exchange 2013 from Exchange 2003. Our main constrain is that Exchange 2013 and Exchange 2003 cannot be installed in the same Active Directory forest. Let’s examine just a few of the options available.

Cross Forest Migration

A resource forest is an additional Active Directory forest installed alongside our existing one used to run Exchange within. This approach allows you to migrate users to Exchange 2013 whilst Exchange 2003 is still installed in the original forest, allowing for a degree of coexistence. An example topology is shown below:

Figure 3: Two AD forests, one with Exchange 2003 and 2010 migration server, another with Exchange 2013

The downside of such a migration is that once the migration is complete, two Active Directory forests must remain in place introducing additional servers and management complexity. For a small organisation, this approach will be too complicated.

Third-Party Tools Migration

A range of third party tools exist on the market allowing simplification of the migration by allowing us to remove some steps from the process. In the example below, we are still using multiple Active Directory forests but instead of introducing Exchange 2010 as the bridge to Exchange 2013, the third party tools allow direct migration:

Figure 4: Two AD forests, one with Exchange 2003 and third-party migration server, another with Exchange 2013

Although this approach helps reduce the additional servers required – especially if a hosted tool is used – we’ll still have the same additional Active Directory resource forest to manage post-migration.

Migration via Exchange 2010

If you’d prefer something a little more akin to a normal upgrade without needing to resort to cross-forest or more drastic methods then upgrading first to an interim version may make sense, particularly for a small organisation. In this scenario, we’re looking to perform a rapid upgrade between subsequent versions without coexistence, effectively double-hopping the user base. You’ll see the first step with the migration to Exchange 2010 below:

Figure 5: Single site, Exchange 2003 and 2010 installed

Followed by a migration straight over to Exchange 2013:

Figure 6: Exchange 2010 and 2013 installed ready to complete the migration and rebuild the Exchange 2010 server

Technically it’s just as possible to migrate to Exchange 2007 and then to Exchange 2013 instead, however the disk throughput requirements of Exchange 2007 are higher than Exchange 2010 meaning that the hardware required to temporarily support users will need to be of a higher specification.

Choosing the right method

For larger organizations, using a resource forest for Exchange 2013 may well make a lot of sense. A medium to large organization that expects to complete the migration relatively quickly may prefer to use Exchange 2010 as a bridge when moving mailboxes to minimise costs. Larger organizations with multiple sites who expect a longer period of coexistence will benefit from third-party tools which provide features like online mailbox moves and calendar and shared mailbox synchronization.

For smaller organizations like ours, we benefit from a smaller number of users making it possible to move all mailboxes swiftly and it’s important to keep the number of servers required to a minimum – not to mention ensuring that management of the infrastructure remains simple. Therefore we’ll be choosing the latter option and double-hop to Exchange 2013 via Exchange 2010.

Key Migration Tasks

Before we begin our migration we’ll take a few moments to get an appreciation for the tasks we’ll need to accomplish. As we’ve seen there’s a few ways to accomplish our migration so it’s important to understand that we’ll tackle our double-hop migration using the following steps:

  • Discovery. We’ll need to use a range of tools to understand the Exchange 2003 environment so that we know what relevant settings are in place and need migrating, what clients are currently used within the environment and which third-party applications are being used.
  • Planning for Deployment – good migrations require good planning, so we’ll draw up the plans for the migration and the new Exchange environment.
  • Getting the environment ready for the upgrade – before we begin the migration, we’ll perform tasks against the existing Exchange infrastructure, Active Directory and clients to get things ready. To make things simpler we’ll also be removing Public Folders from the environment prior to the upgrade during this stage.
  • Getting the servers ready for Exchange – we’ll be installing both Exchange 2010 and Exchange 2013, but on each server we’ll need to make some preparations. These tasks will install pre-requisites and ensure the storage is configured correctly.
  • Testing disk performance – the servers we’ll migrate to will have to support two different version of Exchange; so we’ll need to ensure that we use JetStress to verify that our new servers are up to the task.
  • Installing the Exchange 2010 Multi-Role Server – Our server in the middle of the migration need to be installed alongside Exchange 2003. We’ll perform a rapid install of Exchange 2010 and configure it with basic settings that will facilitate a quick migration from Exchange 2003.
  • Preparing the Exchange 2010 Migration – We’ll test base functionality to ensure that our temporary Exchange server works correctly, test backup and restore, and then move services like inbound and outbound mail flow over to Exchange 2010.
  • Migrating Mailboxes to Exchange 2010 – Our rapid migration of mailboxes from Exchange 2003 will affect users from this point on, especially as we can’t perform online moves and won’t use coexistence.
  • Decommissioning Exchange 2003 – As soon as we’ve moved mailboxes successfully to Exchange 2010 it’s imperative that we decommission Exchange 2003 as soon as possible.
  • Installing the first Exchange 2013 Server – We’ll be installing two Exchange 2013 servers, but during coexistence with the Exchange 2010 server we’ll have just the one server. We’ll need to install Exchange 2013 and after configuring base settings, configure mailbox databases, our load balancer and create the Database Availability Group.
  • Preparing for Exchange 2013 Migration – as with the Exchange 2010, we’ll test base functionality, ensure backup software works and then move inbound and outbound mail routing across to Exchange 2013.
  • Migrating Mailboxes to Exchange 2013 – Our move of mailboxes to Exchange 2013 should be much smoother for end-users than the jump to Exchange 2013, as we can take advantage of both online mailbox moves, and the ability to suspend mailbox moves when they are ready for completion, and then switch all mailboxes at around the same time. This will allow us to minimise the time needed for coexistence and simplify the end-user experience.
  • Decommissioning Exchange 2010 – Just like Exchange 2003, we’ll be removing Exchange 2010 from the environment ready to install Exchange 2013 on the same server and build out our Database Availability Group.
  • Installing the second Exchange 2013 Multi-Role Server – with our server that ran Exchange 2010 now ready for Exchange 2013, we’ll install the new version and configure it with same settings as the first Exchange 2013 server, including adding the same database copies, updating send and receive connectors and adding it to the Load Balancer.
  • Ongoing Maintenance of Exchange 2013 – After migrating to Exchange 2013 we’ll have a highly available, reliable infrastructure but it will require some monitoring and maintenance to keep it in top shape. We’ll look at some of the tasks required and how our Database Availability Group will minimise downtime.


In the first part of this series we’ve looked at our example organization, which is intended to be reflective of many small organizations looking to move to a newer version of Exchange. We then examined a number of available approaches worth considering when tackling the migration, before running through the high level tasks we’ll need to accomplish to move to Exchange 2013. As you’ll see the migration involves a few steps, however using this guide it should be fairly straightforward.

If you would like to read the other parts in this article series please go to:

Leave a Comment

Your email address will not be published.

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top