Exchange 2016 to
Microsoft 365 Migration

What "end of support" actually means for Exchange 2016

Since October 2025, Microsoft no longer issues security patches, bug fixes, or technical support for Exchange Server 2016 under normal terms. Microsoft ran an Extended Security Update (ESU) program to bridge the gap — an initial period through mid-April 2026, followed by a second ESU period running from May through the end of October 2026. Once that window closes, there is no further safety net: any vulnerability discovered in Exchange 2016 after that point has no fix coming, ever, on a system that typically holds every piece of email an organisation has ever sent or received.

That's the real driver behind most Exchange 2016 migration projects right now — not a feature wishlist, but a hard security deadline that's already closer than it looks.

Why some organisations are still on Exchange 2016

It's rarely negligence. Common reasons we see:

• Unified Messaging dependency. Organisations using Exchange 2016's built-in UM for voicemail or telephony integration often delay migration because that functionality doesn't carry forward the same way — it needs its own plan, typically moving to Microsoft Teams Phone or a third-party voice platform.
• Custom integrations. Line-of-business applications wired directly into on-premises Exchange via EWS or other APIs sometimes need reconfiguration work that gets deprioritised until it becomes urgent.
• Uncertainty about hybrid vs. full cutover. Not knowing which migration approach fits the organisation's size and timeline is a common reason projects stall before they start — see our Exchange hybrid vs cutover guide for that decision.

What actually complicates an Exchange 2016 migration

Beyond the basic mailbox move, a few things are worth flagging early rather than discovering mid-project:

• Public folders. Legacy public folder structures, if still in use, need their own migration path into Microsoft 365's modern public folder model — this is a frequent source of underestimated project scope.
• Mail flow and connector configuration. Any custom transport rules, connectors, or third-party mail security/archiving integrations attached to the on-premises environment need to be re-established against Exchange Online, not just carried over automatically.
• Directory synchronisation health. If Azure AD Connect (or Entra Connect) has been running for years without maintenance, migration is often the point where old sync errors and duplicate object issues surface and need cleaning up first.

None of these are exotic — they're the normal accumulated state of an Exchange environment that's been in production for years, and they're exactly what a proper discovery phase is meant to catch before cutover, not during it.

What we look at during discovery

Environment audit. Full inventory of mailboxes, public folders, distribution groups, connectors, and any UM or telephony dependencies.

Migration path decision. Hybrid or cutover, based on mailbox count, timeline, and whether a coexistence period is needed during the transition.

Directory and mail flow health check. Sync status, DNS/MX readiness, and any custom transport configuration that needs to be replicated in Exchange Online.

Migration and cutover. Batched, scheduled around business hours, with validation before the legacy environment is decommissioned.