Home » Exchange Server » How to Decommission an Exchange Server After Office 365 Migration

How to Decommission an Exchange Server After Office 365 Migration

In a recent article I discussed the requirement to retain an on-premises Exchange Server after migrating to Office 365 when directory synchronization is being used. That article addresses a very frequently asked question in online forums. However, a less frequently discussed scenario is the safe decommissioning of on-premises Exchange Server when directory sync is not being used.

There's a few ways to end up in a post-migration scenario where Exchange can safely be removed:

  • You used a cutover migration to Office 365, and have no plans or business requirement to later implement directory synchronization
  • You used a staged migration to Office 365, and have turned off directory synchronization
  • You used a hybrid migration to Office 365, and you've removed the hybrid configuration and have turned off directory synchronization

The common element of those three scenarios is that directory synchronization is not being used. If you still plan to use directory synchronization, your server needs to stay.

Assuming it's safe to get rid of Exchange, the biggest mistake people make at this point is just turning off the Exchange Server. Some people do it because they're unaware of proper removal steps, and others do it because they might want to turn it back on some day to recover some data from it.

Exchange Server does need to be properly uninstalled from your environment due to the integration it has with Active Directory. You might think that it doesn't matter, your email is running in the cloud now anyway, but one day in the future you might have a need to reintroduce Exchange to the environment, and the existence of an old server object in AD is going to cause you problems. On one project I worked on, the customer needed to off-board from Office 365 to on-premises Exchange. The consultants who had previously migrated the customer to Office 365 had just turned off the old Exchange 2007 server. When we came along to install Exchange 2013, we ran into problems with the old server object that ultimately cost more time (and money) than a proper removal would have in the first place.

To correctly remove Exchange you need to uninstall the Exchange Server software from the server it is running on. At its simplest, that means going in to Add/Remove Programs and hitting the Uninstall button for Exchange. But there are some preparation steps involved.

To begin with, Microsoft does publish some information about uninstalling Exchange.

If you're unfamiliar with removal of Exchange servers you should read through those articles. You'll notice they repeat the same concepts, and even though none of them cover the topic in full they all give you an idea of what's involved. I've also written some tutorials for removing Exchange servers after on-premises migrations.

If you haven't completed any of the preparation steps to allow Exchange to be uninstalled, you'll be blocked and a message will explain what you still need to do (e.g. disable remaining mailboxes, remove connectors). Setup can't detect all of the dependencies though. For example, if your on-premises Exchange server is still performing SMTP relay for devices on your network, that won't stop it from being uninstalled. You will still need to inspect your transport or protocol logs to determine when the server is no longer being used for that purpose.

The last point I want to address is the data recovery scenario. This usually comes up after a cutover migration when the customer is not 100% confident that the migration successfully moved all of the mailbox contents. As a “just in case” measure, the on-premises server is turned off and kept in place for potential data restores in future. Proper removal of Exchange would conflict with this goal, so the proper removal is never performed.

I don't think this is a good long term strategy, because the server is usually forgotten about (see my earlier notes about future deployment blockers due to the legacy Exchange server still existing in AD). Perhaps for a short time it is acceptable, but I think you should always aim to remove Exchange correctly. If you want to retain just the EDB files for restores, you can do makes copies of them prior to uninstalling Exchange and then use a tool like Veeam Explorer for Exchange to extract data from them later.

For recovery from tape or other backup media, you can spin up a temporary virtual environment to perform the restore, which also isolates the restore from your production environment which is a good idea in case of operator error.

Hopefully this article helps clarify the need to correctly remove Exchange from an environment when it is no longer needed after migrating to Office 365. If you have any questions please feel free to ask in the comments below.

Photo by EJ Yao on Unsplash

Paul is a Microsoft MVP for Office Servers and Services. He works as a consultant, writer, and trainer specializing in Office 365 and Exchange Server. Paul is a co-author of Office 365 for IT Pros and several other books, and is also a Pluralsight author.
Category: Exchange Server


  1. T says:

    This is interesting! I had a situation with a customer that required Exchange schema to be re-installed simply to amend an Exchange attribute (mailNickName). This was the only approach that Microsoft Support said was possible.

    Will be interesting to see what others do in this scenario.

  2. Victor Camacho says:

    Hi Paul,
    Thanks for the great article.
    Lucky for me, I purchased this great book titled “Office 365 for IT Pros”.
    It made me aware that there was a proper procedure to remove Exchange from a system.
    Check out this book and keep up the great work.

  3. M says:

    Hi Paul,
    There is 4 scenario: I use directory synchronization and I want cleanup my on-premise AD, where I actually have couple of version Exchange servers: Exchange 2007, 2010 and hybrid config with Exchange 2013. Some time ago we rebuild part of Exchange infrastructure (such as ipm public folder tree and OAB) from forest domain to child domain, where still exists mailboxes (ex2007).
    I want to be sure that my on-premise AD is clean and after that I still want on-premise Exchange 2016 management role and directory synchronization. Can I use your scenario to decommission all version of Exchange servers and install last fresh version 2016 without change in AAD Connect?

Leave a Reply

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