Migrating from On-Prem Exchange to Microsoft 365: A Practical Field Guide

TL;DR

Moving on-prem Exchange to Microsoft 365 is still routine work in 2026. The right path depends on mailbox count, server version and what else lives on the old box. Cutover for under 150 mailboxes, hybrid for large or regulated estates, IMAP for the awkward middle. Plan around the .ost cache, the printer-to-SMTP relay, and the hybrid server you forget to decommission. Done well, end users see one icon change.

Why are organisations still doing this in 2026?

Plenty of reasons, none of them flattering to the previous IT regime.

Small Business Server 2011 is still answering ping in more offices than anyone admits. Exchange 2010 went out of extended support in 2020. Exchange 2013 followed in 2023. Exchange 2016 hit end of extended support in October 2025. Exchange 2019 is the last on-prem version on the modern admin centre, and Microsoft has made clear that Exchange Server Subscription Edition is the future.

Four patterns repeat on the discovery call. The company that simply never moved, until a disk filled at 2am on a 14-year-old chassis. The cyber-insurance prompt: underwriters now ask about supported software, and running Exchange 2010 or 2013 makes the policy more expensive or uninsurable. The acquisition, where the parent runs M365 and the new CFO wants one estate. The slow drift, where Teams, OneDrive and Defender already live in the cloud and mail is the last on-prem service costing more in admin time than the licences would.

The shape of the problem has not changed in five years. The tools have improved. The failure modes have not.

What are the migration paths?

Microsoft offers four supported routes. Each fits a specific shape of source environment. Picking the wrong one is the most expensive mistake on this kind of project, and it is usually made on the first call.

Cutover migration. All mailboxes move in a single batch. Source has to be Exchange 2003 through 2019. Practical limit is 150 mailboxes (Microsoft’s official limit is 2,000, but anyone who has actually run a 1,500-mailbox cutover will tell you not to). Fit: small business, single Exchange server, no public folders worth keeping, no need for coexistence.

Staged migration. Waves over several weekends. Only supported from Exchange 2003 and 2007, mostly a historical option in 2026. We still find the occasional 2007 box on a discovery, usually in a manufacturing site nobody wanted to touch.

Hybrid migration (Exchange Hybrid). A hybrid Exchange server sits between on-prem and M365, federating directories, sharing free/busy calendar data, routing mail bidirectionally, and moving mailboxes one at a time with no end-user disruption. Source must be Exchange 2010 SP3 or later; Exchange 2013, 2016 and 2019 are the standard candidates. Fit: 150+ mailboxes, large mailboxes, public folders, regulated environments where coexistence has to be invisible.

IMAP migration. Mail content only, from any IMAP-capable source. No calendar, no contacts, no rules, no shared mailbox structure. Fit: non-Exchange sources (Zimbra, IceWarp, an old hosted Linux mail server), or Exchange where credentials and admin access have been lost and IMAP is the only way in.

A fifth route is not an official migration “type” but matters in practice: third-party tools. BitTitan MigrationWiz is the most common; Quadrotech and SkyKick also turn up. They sit on top of EWS or the Graph API, do delta syncs, handle public folders and archives, and run in the cloud. We use them on projects where the source is messy or the budget won’t stretch to a hybrid build.

Hybrid migration: when it’s worth the complexity

Hybrid is the right answer more often than the small-business consultant wants it to be. It costs more upfront. It pays off in invisibility.

Reach for hybrid when any of these are true.

Mailbox sizes are large. A 50GB mailbox over a domestic-grade business connection takes a real fraction of a day to move once, never mind twice. Hybrid handles the move in the background with delta passes; the user keeps working in Outlook throughout.

Public folders matter. Exchange public folders are the calendar of the engineering team since 2008 and the shared inbox for accounts. They migrate, but the path is fiddly and hybrid is the supported route. Cutover leaves public folders behind; you script an export-import and hope.

You need coexistence. Some mailboxes stay on-prem for weeks or months while others move. The CEO on Friday, legal in three weeks, the warehouse in two months. Hybrid keeps free/busy working across the estate so meeting bookings don’t break.

You want a single namespace. Users keep firstname@company.co.za regardless of where their mailbox sits. The transport layer routes by recipient, transparently.

The complexity tax is real. A hybrid build needs a dedicated Exchange Server (2016, 2019 or SE edition), a public certificate covering the hybrid endpoints, the Hybrid Configuration Wizard run cleanly, Entra Connect for directory sync, and the M365 tenant prepared with the right accepted domains, connectors and remote routing addresses. Plan a working week of engineering before a single mailbox moves. The Exchange Admin Center migration endpoint, configured against the hybrid server, is what moves mailboxes once the foundation is in. Microsoft’s Migration Manager in the M365 admin centre wraps the same endpoints with a friendlier UI and is fine for routine moves.

Cutover migration: when it’s the right answer

Cutover is the small-business special. Done well, it is one weekend.

Use it when all of these are true. Under 150 mailboxes (we’d push to under 100). No on-prem dependencies have to keep running after the cutover: no LOB app sending NDRs through Exchange, no SharePoint workflow tied to a service account, no document scanner emailing an internal alias. The business tolerates a 24- to 48-hour Outlook profile rebuild window across the weekend. Public folders are absent or expendable.

Shape of the work: stand up the M365 tenant, verify the domain via TXT, prepare licences, create a migration endpoint pointing at the on-prem EWS URL with a service account that has impersonation rights, kick off the migration batch Friday evening, swap the MX once the initial pass completes, run delta syncs over the weekend, complete the batch Sunday night, rebuild Outlook profiles Monday morning. Disable on-prem Exchange a week later.

Where cutover bites is the assumption “we are too small for hybrid.” A 90-mailbox firm with three 80GB founder mailboxes is not a cutover candidate. The size of the largest mailbox matters more than the count.

What you actually do step-by-step

This is the field sequence we run. Hybrid version; cutover collapses some of the steps but the order is the same.

1. Assessment. Inventory of mailboxes by size, last-logon and type (user, shared, room, equipment, distribution group). Inventory of public folders. Inventory of mail-enabled service accounts and the apps they serve. Inventory of every device, printer, scanner and LOB app talking SMTP to the Exchange box. Notes on Exchange version, CU level, certificate state and third-party add-ins (Mimecast, Barracuda, an old anti-spam relay). The discovery is half the project.

2. Target tenant prep. Create the M365 tenant if it doesn’t exist. Verify the primary domain via DNS TXT. Buy and assign licences (Business Premium for most SMEs, E3 for larger or regulated estates). Build user accounts via Entra Connect sync or scripted PowerShell against the on-prem AD.

3. Identity sync if hybrid. Install or extend Entra Connect, sync users, groups and contacts to Entra ID. Choose password hash sync, pass-through auth or federation; PHS is the modern default for almost every SMB. Verify ImmutableID matching against the on-prem objectGUID so cutover doesn’t orphan accounts.

4. Hybrid Configuration Wizard or migration endpoint. Hybrid: install the dedicated hybrid Exchange server, install a public cert covering mail.domain and autodiscover.domain, run the HCW from the M365 side, validate free/busy bidirectionally. Cutover: skip the HCW, configure the migration endpoint with EWS plus credentials, test connectivity from the M365 admin portal.

5. Mail flow connectors. Set up inbound and outbound connectors that match the chosen topology, with TLS-enforced send and receive connectors. Cutover only needs a temporary connector during the migration weekend.

6. Public folder strategy. Decide: migrate, replace with shared mailboxes, or replace with Teams channels. Public folder migration to M365 modern public folders is supported; we have done it many times and we don’t enjoy it. Teams or SharePoint suit shared calendars and files better than the public folder ever did.

7. Migration batches. Move mailboxes by wave. First batch is the IT team, on themselves, so engineers feel the pain before the users do. Second batch is a small pilot of 10 to 20 friendly users. Third batch onwards is staged by the calendar of the business, not the calendar of IT. Each batch runs an initial sync, settles for a few days, then the user is “completed” with a final delta and the Outlook profile points at M365. Hybrid keeps the source mailbox in place as a RemoteMailbox; the user doesn’t notice.

8. Cut over MX. Once the last batch is in M365, the MX records swap to point at *.mail.protection.outlook.com. Lower the TTL 24 to 48 hours ahead. Schedule the change for a quiet window (Friday evening for South African businesses). Update SPF to include spf.protection.outlook.com, enable DKIM on selector1 and selector2, set the DMARC policy to monitoring during cutover and ramp it up afterwards. The TamingDNS M365 DNS audit verifies the public-facing posture before, during and after.

9. Decommission. Section below.

DNS and mail flow on cut-over day

The day everything either goes well or goes loud. The work is choreography, not engineering.

The DNS records that change: MX (to M365), Autodiscover (CNAME to autodiscover.outlook.com), SPF (rewrite the TXT to reference Outlook), DKIM (two CNAMEs at selector1._domainkey and selector2._domainkey), DMARC (TXT at _dmarc), and any _msdcs or _sip records that were pointing at on-prem Exchange or Lync.

The records you do not change yet: anything that an on-prem application is still using. The printer that scans to a shared folder via SMB is fine, but the printer that emails scans through relay.company.local is not. That printer is talking to the on-prem Exchange receive connector. If you turn that connector off on cutover Sunday, the receptionist’s Monday morning starts with “the scanner is broken.”

The DMARC ramp-up matters. Before cutover, the policy is at whatever it was, often p=none. Cut over with p=none, watch the aggregate reports for a fortnight, fix the alignment for any sender you missed, then graduate to p=quarantine pct=10 and onwards. The full sequence is on the /dmarc/ page; the TamingDNS DMARC analyser gives you the public-facing view at every stage. Do not jump straight to p=reject on cutover day. You will quarantine your own helpdesk-ticketing system’s notifications and find out about it via a phone call.

Autodiscover behaviour during cutover is the source of half the support tickets. Outlook caches Autodiscover endpoints, and SCP records in Active Directory persist long after the source server is shut down. The TamingDNS Autodiscover diagnostic is what we run when an Outlook profile refuses to set up cleanly. Half the time the answer is a stale SCP record in AD that nobody removed.

What goes wrong, and how OSH plans around it

The patterns repeat. We have seen all of these more than once.

The .ost cache on user laptops. Outlook’s offline cache file lives in %LOCALAPPDATA%\Microsoft\Outlook\ and is bound to the original mailbox profile. After migration, Outlook either rebuilds the .ost from scratch (slow on a 30GB mailbox over a 4G connection) or needs to be re-pointed cleanly. We script the profile rebuild via Intune or a logon script. On a 50-mailbox migration this saves about 30 helpdesk tickets.

Outlook profile re-creation. Roaming profiles, Citrix and remote desktop hosts add a layer. The .ost lives on a network share, the share fills when 40 users rebuild simultaneously, the file server alarms at 11pm. Mitigation: stage profile rebuilds across two business days and monitor the disk.

Calendar resource accounts. The boardroom mailbox, the projector mailbox, the company car. These are room or equipment mailboxes in Exchange. They migrate, but booking permissions often don’t. Test every resource booking after the move. The PA who books the boardroom for the MD will find every gap before lunch on Monday.

On-prem app integrations. The CRM emailing through Exchange via authenticated SMTP. The ticketing system polling a shared mailbox via IMAP. The HR system sending payslips through an SMTP relay. Each needs its own conversation. M365 retired Basic Authentication for SMTP AUTH, IMAP and POP. Modern apps use OAuth or a high-volume email service like a dedicated SMTP relay. Old apps need a workaround: Exchange Online direct send for internal-only senders on the corporate network, an authenticated SMTP service account for external senders, or a relay service if neither fits.

The printer that emails scans to a deprecated SMTP relay. This happens on almost every project. The Konica or Ricoh in the corner has been emailing scans through relay.local since 2014. Nobody knows the credentials. The IT contact who set it up left in 2019. On cutover, the relay is gone, the scanner’s outbox fills with retries, and the receptionist files a “the scanner is broken” ticket. We catch these in discovery by running a packet capture on the Exchange receive connector for 24 hours and seeing what is actually talking to it. Skip that step and expect surprises.

The shared mailbox that was a distribution list that was a mailbox. Identity re-purposed three times. Permissions are a mess. Half the team can see it after migration and half cannot. Clean up SendAs, FullAccess and AutoMap permissions before cutover, not after.

The hybrid server kept “for management.” See below.

Decommissioning on-prem Exchange

The often-forgotten bit. Most “completed” migrations we audit have at least one Exchange server still running, usually as the hybrid management server. The reason given is “we cannot remove it because Microsoft says you have to manage attributes from on-prem Exchange.” That hasn’t been true for years.

The proper sequence.

Confirm all mailboxes are in M365. No remaining mailboxes, archives, public folders or shared mailboxes on-prem. Run Get-Mailbox and Get-PublicFolder -Recurse to be sure.

Switch directory management. Install the Exchange Hybrid Modern Management tools (or the cloud-based Exchange Management tooling, available since 2022) so Exchange-related attributes can be managed from M365 without on-prem Exchange. This removes the “we have to keep one Exchange server” argument entirely.

Remove send and receive connectors. Anything routing mail through on-prem Exchange. Update Entra Connect to stop syncing the Exchange-specific attributes you no longer need.

Clear the SCP. Set the on-prem Exchange Service Connection Point so domain-joined Outlook clients stop using it for Autodiscover: Set-ClientAccessService -AutoDiscoverServiceInternalUri $null on each CAS, ideally weeks before the box goes off.

Uninstall Exchange properly. Setup.exe /Mode:Uninstall from the install media, in the right order if multiple servers exist (mailbox servers last). Do not just shut the VM down. The Exchange organisation in AD will hold its breath forever and the next admin will find a half-uninstalled mess in five years.

Clean up DNS. Remove the _autodiscover._tcp SRV records, internal Autodiscover CNAMEs, and any legacy mail.domain A records pointing at the old box.

Decommission certificates and the host. Revoke the public certificate covering the hybrid endpoints. Power off the VM. Keep backups for the retention period compliance requires.

The whole decommission is two engineering days when planned. We have walked into too many client estates where it was never done, the Exchange 2013 box is still in the rack, and a dormant attack surface is sitting on the LAN.

The honest framing

A migration done well is invisible. A migration done badly produces six months of small lingering issues: an Outlook profile prompting for credentials weekly, a calendar resource double-booking, a scanner that doesn’t, an archive that “must be there somewhere” but can’t be found.

Pay for it once and do it properly. The engineering hours cost less than a year of small annoyances.

The full migration playbook lives on /blog/exchange-to-m365-migration/. Email authentication work that runs in parallel is on /dmarc/. /services/ is where the engagement starts.

Get a managed Exchange-to-M365 migration

Next step is small. Send us your current Exchange version, mailbox count and the rough age of the box. We’ll tell you which of the four paths fits and what a realistic timeline looks like. Free, written, no obligation. If we then run the project we plan it, communicate it, execute it across the cutover weekend, and handle the long tail of small fixes for 30 days afterwards. No surprises, no missed scanners, no hybrid server left behind.

Email support@osh.co.za or use the form below.