Home » Exchange Server Upgrades and Migrations

Exchange Server Upgrades and Migrations

Upgrades and migrations for Microsoft Exchange Server can seem like a complex and difficult process. However in most cases a migration is able to follow a standard process, with only those special or unique characteristics of the Exchange Server environment likely to cause problems or require additional planning and effort.

The first thing to be aware of when planning your Exchange Server migration is that in-place upgrades of Exchange Server are not possible. For example, you cannot upgrade an Exchange Server 2007 server to Exchange Server 2010, or an Exchange Server 2010 server to Exchange Server 2013.

The reasons for this are that the server architecture and internal workings of Microsoft Exchange Server often change so much between major releases that upgrades would become perilous exercises that are nearly impossible to adequately test for. Instead, an Exchange Server upgrade from one version to another involves a migration of services and data from old servers to new servers.

The upgrade scenarios for Exchange Server are typically N-2. In other words, a version of Exchange Server can be migrated to from the previous two versions, but not from any older versions. For example, Exchange Server 2013 can be migrated to from Exchange Server 2007 and 2010, but not from Exchange Server 2003. An Exchange Server 2003 organization would need to first migration to 2007 or 2010 before they could migration to Exchange Server 2013.

For more information on some of the supported migration scenarios refer to the following resources:

Exchange Server Pro has published a number of migration guides for Exchange Server migration scenarios:

I’ve also produced a Pluralsight training course for Exchange Server 2016 migration:

For the purposes of this article an “upgrade” refers to the process of moving your organization’s Exchange Server environment to a newer version, for example from Exchange Server 2010 to Exchange Server 2013. If you are looking for information about upgrading in the sense of service packs or cumulative updates, please refer to the following resources instead:

Alternatives to Exchange Server Migrations

For organizations that do not wish to upgrade their on-premises Exchange Server environment there is also the option to migration to Exchange Online, which is the cloud hosted version of Exchange Server that forms a part of the Microsoft Office 365 service.

Office 365 migrations can be performed in multiple ways. For an overview of the Office 365 migration scenarios, read my article on methods for migrating to Office 365.

For more information on Office 365 click here.

More Articles

Here are some more recent articles with tips and troubleshooting solutions for Exchange Server migrations:

2 comments

  1. Aliasgar says:

    Hi team,

    I dont know if this is the right page to post this question as I did not find a relevant post.

    We recently migrated our exchange on prem mailboxes with a cut-over migration. Post that everything seems working OK and the on prem exchange servers are powered down since last one month. Now we want to remove the exchange servers so what would be the suggested approach?

    1. In case there is Dir Sync in place
    2. In case Dir Sync is not in place.
    3. Would it affect any user attributes if we cleanly uninstall the exchange from Add/remove programs? in both the above cases.?
    4. Or if we simply clean up the servers drive ? would it leave any traces on AD or schema which would cause any issue later?

    Appreciate your suggestion.

    • If you want dirsync then you need to keep an Exchange server on-premises to remain supported. This TechNet article is relevant. Don’t be distracted by all the hybrid stuff, it covers the points about dirsync as well:

      https://technet.microsoft.com/en-us/library/dn931280(v=exchg.150).aspx

      Powering an Exchange server off for a month is not a great idea.

      Retrofitting dirsync after a cutover migration is tricky. It’s better to plan a migration method that accounts for your dirsync needs, like staged or hybrid. But you’ve already done the migration, so that’s just a hurdle you’ll need to deal with moving forward if you want dirsync.

      If you do decide to remove the server, it must be cleanly uninstalled, not just left powered off, and not removed via ADSIEdit.

Leave a Reply

Your email address will not be published. Required fields are marked *