Dave is a marketing expert with 15 years experience in the tech and SaaS world. He specializes in educating IT and channel audiences, with a focus on security, privacy, compliance, and marketing technology. With a talent for storytelling and a deep understanding of the industry, Dave transforms complex IT topics into clear, engaging, and impactful narratives.
How to migrate Microsoft Exchange to Microsoft 365 (Office 365)
TL;DR
Exchange Server 2016 and 2019 support ended October 14, 2025. Microsoft's Extended Security Update bridge is now in its second and final period, running through the end of October 2026. Microsoft has confirmed there will be no further extension after that. If you're still running either version without an ESU contract, you're migrating without a vendor security-update path, not just planning ahead.
Three migration methods exist: cutover (realistically under 150 mailboxes), staged (Exchange 2003 or 2007 sources only), and hybrid (the right answer for most Exchange 2010–2019 or Subscription Edition sources above 150 mailboxes, or anyone who wants near-zero downtime).
Email signatures applied through on-premises transport rules, Group Policy, or a PowerShell script don't move with the mailboxes. They need their own rebuild plan, separate from mail flow.
Migration duration is per mailbox, not a flat project estimate: Microsoft's own data puts a sub-10 GB mailbox at about a day, and a 50 to 100 GB mailbox at about four days typically. Skipping the pre-migration inventory is the single biggest cause of delay beyond that.
Budget post-migration time for DNS, security settings, data verification, and getting signatures and disclaimers working again before you decommission the old server.
Why migrate to Microsoft 365 now
Support for Exchange Server 2016 and Exchange Server 2019 ended on October 14, 2025. Microsoft stopped issuing security fixes, bug fixes, and time zone updates for both versions on that date. Organizations that needed more time could buy into Microsoft's Extended Security Update program: a first six-month period ran through April 14, 2026, and a second, separate purchase covers a final period through the end of October 2026.
Microsoft has been explicit that this second period will not be extended again. An organization without an active ESU contract today has no vendor security-update path at all, and even one with a Period 2 contract is working against a hard, published deadline, unless it upgrades in place to Exchange Server Subscription Edition (SE), the on-premises successor Microsoft now recommends for anyone who needs to keep some Exchange infrastructure on-site.
For everyone else, Microsoft's own guidance is direct: migrating to Microsoft 365 (the platform Microsoft renamed from Office 365 in 2021, though the "Office 365" name is still common in search and in plenty of internal documentation) is the simplest way to retire an Exchange Server deployment. According to Microsoft, migrating gets you larger, more resilient mailboxes; built-in anti-spam and anti-malware protection; compliance tools like Data Loss Prevention, retention policies, and eDiscovery; and direct integration with SharePoint, OneDrive, and Teams. You also stop maintaining server hardware, cooling, and patching on your own schedule.
None of that changes the work in front of you: deciding which migration method fits your mailbox count and Exchange version, building a realistic timeline, and working out what happens to every email signature, disclaimer, and banner that currently depends on your on-premises Exchange server. That last part is what general migration guides skip.
Preparing for the migration
Before you touch a migration wizard, get four things straight:
The reason you're moving. "Exchange 2016/2019 is out of support" is a perfectly good reason on its own. If cost, collaboration tools, or security posture are also driving the decision, write that down too, since it'll shape which features you configure first once you land in Microsoft 365.
The size and shape of your current environment. Mailbox count, distribution groups, public folders, and shared/resource mailboxes. This single step determines which migration method is even available to you (see the table below).
A realistic timeline. Microsoft's own migration-performance data gives a real anchor instead of a guess: a mailbox under 10 GB typically migrates in about a day, one in the 50 to 100 GB range typically takes about four days (up to 13 in slower cases), and mailboxes over 200 GB aren't supported for standard onboarding migration at all. That's per mailbox, not the whole project. Multiply it out across your batches, then add planning and pilot testing on top before you commit to a go-live date.
How your email signatures are currently applied: on-premises transport rule, Group Policy, a client-side script, or a third-party tool. Whatever it is, it's tied to infrastructure you're about to change or retire. Note it now; you'll need it later in this guide.
Your pre-migration checklist
Back up your data. Mailboxes, public folders, and archives. This is your rollback option if anything goes wrong mid-migration.
Check your network and bandwidth. Migration throughput is throttled by Microsoft's Mailbox Replication Service regardless of how much bandwidth you have available, so test actual throughput rather than assuming your connection is fast enough.
Confirm your Exchange environment meets Microsoft 365 prerequisites: supported server version, required server roles, and any pending updates.
Inventory every mailbox and its contents (calendars, contacts, tasks) so you can spot discrepancies after the move.
Set up Microsoft 365 accounts and licenses, including admin accounts with the permissions your migration team actually needs.
Document how signatures and disclaimers are currently deployed. You'll use this when you get to the signature section below.
Which migration method should you use: cutover, staged, or hybrid?
Your Exchange version and mailbox count decide most of this for you. Here's how Microsoft's own guidance breaks it down:
Method | Best for | Mailbox guidance | Source Exchange versions | Downtime | Complexity |
|---|---|---|---|---|---|
Cutover | Small organizations wanting one fast move | Technically supports up to 2,000, but Microsoft's own guidance recommends 150 or fewer for realistic performance | 2010, 2013, 2016, 2019, SE | All mailboxes move in one window, typically a weekend | Low |
Staged | Organizations still on very old Exchange versions | More than 150 mailboxes | 2003 or 2007 only | Per-batch, spread over one to a few weeks | Medium |
Hybrid | Most organizations above 150 mailboxes on a modern Exchange version, or anyone needing long coexistence | No hard mailbox ceiling | 2013, 2016, 2019, SE (2010 via a coexistence bridge server) | Near-zero; each mailbox sees a brief interruption when finalized | Medium–high |
A note most guides skip: staged migration isn't a general-purpose "medium-sized org" option. Microsoft scopes it specifically to Exchange 2003 and 2007 sources. If you're migrating off Exchange 2016 or 2019 (the versions that just lost support) and you have more than 150 mailboxes, hybrid is the method Microsoft's own decision guidance points to, not staged. Cutover also skips the ongoing directory sync that staged and hybrid both need, since it creates cloud recipients directly during the migration.
Worth flagging: The table lists 2010 and 2013 as normal source versions, but both passed their own end-of-support years ago: 2013 in April 2023, 2010 in October 2020. Either one means running unsupported infrastructure for years, not catching up to a recent deadline.
If you're staying on-premises entirely, Exchange Server SE is the supported path worth knowing even though this guide focuses on migration.
What happens to your email signatures during the move
This is the part most migration guides skip, and it's what generates support tickets for weeks after everyone assumes the project is finished.
If your signatures, disclaimers, or campaign banners run through an on-premises Exchange transport rule, a Group Policy Object, or a PowerShell script, none of that travels with the mailbox. It's tied to the server or script, not the mailbox data. Cut over mail flow or decommission the old server, and whatever it was doing stops. Employees start sending mail with no signature, or a generic Outlook default.
"Most home-grown signature setups don't survive a migration, and it's an architecture problem more than a planning one. The rule gets bound to the mail server or the script pushing it out, instead of to the directory. Microsoft Entra ID attributes move with the migration. A transport rule sitting on a mailbox server doesn't move anywhere, and that's the real blind spot: the data's fine, it's the mechanism enforcing it that's gone. Most teams don't find out until the first employee sends mail with no signature at all."
In Exclaimer's 2024 research into how IT departments spend their time, 59% of US IT leaders said their department spends most of its time supporting the rest of the organization, more than three times what goes to security work and data analysis. A migration deserves IT's full attention during the cutover window. It's also the one moment to fix how every disclaimer and directory field is governed going forward, instead of quietly recreating the old, ungoverned setup in the new tenant. The mailboxes are the part with a deadline. Signature governance is the part with the longer payoff.
How to plan your signature rebuild before you decommission the old server
The fix isn't complicated, but it does need to be planned rather than left until someone notices:
Decide how signatures will be applied in the new environment: Microsoft 365's built-in transport rules can handle a basic, uniform signature, but they don't offer per-department branding, rotating banners, or fields that pull live from your directory without a scripted workaround.
If you need anything beyond a single company-wide signature, plan for a dedicated email signature management setup now, rather than after employees start noticing missing signatures.
Test signature deployment in the same pilot batch you use for mailbox testing, not as an afterthought once mailboxes are confirmed working.
Make sure directory fields (job title, department, phone number) are populated correctly in Microsoft Entra ID before go-live if any signature depends on them.
Preparing your users for the migration
Two weeks out: Tell people the migration is happening, roughly when their batch moves, and what changes for them on day one, new sign-in, Teams and SharePoint access, the new Outlook if that's part of the move.
48 hours before their batch: Send a short reminder with the exact date, anything they should leave open or close beforehand, and who to contact if something looks wrong afterward.
The day their batch completes: Confirm it's done, give them the one thing they actually need to do (restart Outlook, sign in again), and tell them where to send problems instead of making them guess.
Throughout: Take "will I lose access to old email" and similar questions seriously rather than reassuring people in the abstract, and ask everyone to archive or delete old mail before their batch. A smaller mailbox migrates faster and with fewer surprises.
Executing your migration
Cutover migration
Cutover moves every mailbox in one operation, typically over a single weekend. It doesn't require ongoing directory synchronization, since Microsoft 365 creates your recipients directly during the migration.
Verify your domain in Microsoft 365 without changing MX records yet.
Reduce your MX and Autodiscover DNS TTL a few days ahead of cutover, so the eventual record change propagates quickly instead of taking hours.
Create a migration endpoint using Outlook Anywhere/EWS connectivity to your on-premises server, then create and start the migration batch.
Monitor the batch with
Get-MigrationBatchuntil every mailbox reaches a synced state, and test signature deployment on whichever mailboxes sync first rather than waiting until everyone's moved.Complete the batch, with
Complete-MigrationBatch -Identity ", then update MX, Autodiscover, and SPF records; assign Microsoft 365 licenses; and have users restart Outlook to reconnect automatically."
Staged migration
Staged migration applies specifically to Exchange 2003 or 2007 sources with more than 150 mailboxes that need to move in batches over several weeks rather than all at once.
Verify your domain in Microsoft 365.
Run a one-time directory synchronization with Microsoft Entra Connect to create your cloud recipients ahead of the batch moves.
Create and run migration batches, selecting which mailboxes move in each wave, and check signature and disclaimer behavior on the first wave before moving the rest.
Reissue credentials per batch: users whose mailboxes have moved need new sign-in details and a reconfigured Outlook profile.
Hybrid migration
Hybrid keeps your on-premises Exchange server and Microsoft 365 coexisting throughout the migration, which is why it's the default recommendation for modern Exchange versions above 150 mailboxes.
Install the Hybrid Configuration Wizard (HCW) from Microsoft and run it from your most current Exchange server.
Select your hybrid topology (full or minimal) based on how much coexistence (shared free/busy, a unified address book) you actually need.
Verify your domain and DNS records in Microsoft 365 if you haven't already.
Synchronize your directories using Microsoft Entra Connect, and confirm mailbox replication is enabled and healthy.
Move mailboxes in batches using Remote Move Migration, checking progress with
Get-MigrationBatchand confirming signatures apply correctly on the pilot batch before moving the rest.
Your post-migration checklist
Coordinate with users: Confirm the migration is complete, share access instructions, and open a clear feedback channel for issues.
Configure mail rules and settings: Verify forwarding rules migrated correctly, review retention and storage settings, and rebuild your email signatures and disclaimers using the plan from the section above (this is the step most teams underestimate), not the transport rule or script that no longer runs.
Review security settings: Enable multi-factor authentication, confirm security policies and data permissions, and configure anti-spam and anti-malware protection.
Verify data integrity: Check mail, attachments, calendars, and contacts against your pre-migration inventory, and restore anything missing from backup.
Optimize performance and usability: Monitor system performance, confirm mobile access works across devices, and roll out Outlook, Teams, and OneDrive with basic training.
Adjust for your organization: Run compliance and audit checks, and confirm your Microsoft 365 backup strategy is in place and tested.
Tip
Don't decommission your old Exchange servers until every mailbox, signature, and rule is confirmed working, not just migrated. Follow Microsoft's decommissioning guidance so no leftover configuration disrupts the new setup, and remember you may need to keep at least one Exchange server temporarily if you're still using it for on-premises recipient management.
Troubleshooting common issues
Mailbox corruption. Missing or incomplete emails, contacts, or calendar items. Run the Exchange Server Health Checker before migrating, confirm backups are complete, use
New-MailboxRepairRequest(Exchange) orScanPST.exe(Outlook) to repair, and re-migrate affected mailboxes in a new batch if needed.Synchronization issues. Delayed syncing or inconsistent data. Verify your Microsoft Entra Connect configuration, check Synchronization Service Manager, confirm port 443 is open, and force a sync with
Start-ADSyncSyncCycle -PolicyType Delta.Authentication problems. Failed logins or repeated password prompts. Confirm on-premises AD and Microsoft Entra ID match, enable modern authentication, and configure single sign-on if you haven't already.
Mail flow disruptions. Delayed or missing messages. Check MX, CNAME, and SPF records, test with Microsoft's Remote Connectivity Analyzer, verify hybrid connectors, and check for stuck items in mail queues.
Security and compliance gaps. Unauthorized access or compliance policies not applying. Audit mailbox permissions, confirm DLP and retention policies are active, and enable the security features (MFA, threat protection) you configured before go-live.
Email signatures missing or reverted to a default. The most common cause is a transport rule or script that no longer runs once the source server is decommissioned, or a client-side Outlook signature that was never recreated per device. Confirm which mechanism was in use before migration (see the checklist above), and rebuild it in the new environment rather than assuming it carried over. If you're seeing this specific issue in Outlook after the move, this troubleshooting guide walks through the common causes and fixes. For anything beyond a single uniform signature, centralized email signature management is generally simpler to maintain long-term than recreating scripts per device.
Making your migration successful
A Microsoft 365 migration succeeds or stalls on the parts that don't show up in a mailbox count: an honest timeline, the right migration method for your Exchange version, and a plan for everything that doesn't travel automatically with the mailbox data. Treat your email signatures as part of that plan, not a line item to handle once everyone assumes the project is finished.
If you're rebuilding your signatures as part of this move, Exclaimer's guide to Microsoft 365 email signatures covers the setup directly, and Exclaimer's cloud solution applies signatures server-side so they work the same way across every device from day one, without a transport rule or script to maintain going forward.
