January 14, 2020. That is the date Exchange 2010 end of support becomes real — no more security updates, no more time-zone fixes, no more support cases. As of this week you have twelve months, minus change freezes, minus budget cycles, minus the six weeks your procurement team will spend on the licensing quote. If you are still running Exchange 2010 in production, this post is your migration planning memo.
We have moved more than 15,000 mailboxes off Exchange 2010 estates over the past three years, most of them into Office 365, a few onto newer on-prem versions for clients with genuine data-sovereignty constraints. The pattern we keep seeing: organizations underestimate the runway not because the mailbox moves are slow, but because everything around the mailboxes — directory hygiene, ADFS decisions, public folders, relay dependencies — eats the calendar first.
So here is the triage matrix we walk clients through in January 2019, with honest timelines attached. If you take one thing from this post: twelve months is enough, but only if the first ninety days are spent on assessment and directory work, not on arguing about which migration tool to buy.
First, accept that "do nothing" is a decision
Every Exchange 2010 conversation starts with someone suggesting the estate can coast past the deadline. It can — the servers will not stop working on January 15, 2020. What stops is the patch stream. Exchange has had a steady drip of security fixes over its life, and an unpatched, internet-facing mail system is exactly the kind of target that turns into an incident report. Ask anyone who ran unpatched SMBv1 through May 2017.
There is also a quieter cost: Outlook client support, TLS requirements from partners, and compliance auditors who ask pointed questions about unsupported software in scope. For our government clients the auditor question alone settles it. Unsupported Exchange in a CJIS or HIPAA environment is not a risk register line item; it is a finding.
The honest framing for leadership: the deadline is not "Exchange breaks in January 2020." The deadline is "after January 2020, every Exchange vulnerability disclosed anywhere becomes your permanent, unpatchable problem."
The triage matrix: three exits, one wrong answer
Every Exchange 2010 estate leaves by one of three doors.
| Exit | Best for | Typical timeline | Watch out for |
|---|---|---|---|
| Hybrid to Office 365 | Most estates, 500–50,000 seats | 4–9 months | Directory cleanup, network egress |
| Exchange 2016 on-prem | Sovereignty or connectivity constraints | 3–6 months | You will do this again in 2025 |
| Decommission / absorb | M&A leftovers, app-relay-only servers | 1–3 months | Hidden SMTP relay dependencies |
The wrong answer is Exchange 2019. Not because 2019 is bad — because Exchange 2010 and Exchange 2019 cannot coexist in the same organization. There is no direct path. If you want 2019 on-prem, you migrate to 2016 first, decommission 2010, then introduce 2019. That is two migrations for an estate that, in most cases, should be doing zero on-prem migrations. If someone on your team is quoting a 2010-to-2019 project, ask them to draw the coexistence topology on a whiteboard and watch what happens.
For roughly 80 percent of the estates we assess, hybrid to Office 365 is the right door. Exchange 2010 SP3 with a current update rollup supports hybrid via the Hybrid Configuration Wizard, mailbox moves are native MRS moves with no third-party licensing, and users keep their offline cache — a cutover they mostly do not notice. The 2016 on-prem exit is legitimate for clients with real constraints: one of our public-sector clients runs facilities with no reliable WAN, and mail that stops when the circuit drops is not acceptable. That is a reason. "We prefer our own servers" is a preference, and preferences should get priced — see the 35 percent infrastructure cost delta we have measured across estates that made the jump.
The 90-day assessment: what actually eats the runway
Before a single mailbox moves, we spend the first quarter on four workstreams. Every one of these has blown a timeline for someone who skipped it.
Directory hygiene. Azure AD Connect will happily sync your directory, and it will just as happily surface every sin committed in it since 2003. Run IdFix early. Duplicate proxy addresses, invalid UPN characters, users with non-routable UPN suffixes like .local — each one is a sync error, and at 6,000 users, a 2 percent error rate is 120 tickets. On our largest government engagement, UPN suffix remediation alone was a six-week project because it touched smart-card logon behavior.
Identity model. In 2019, the default answer is password hash sync with seamless SSO, not ADFS. If you already run an ADFS 3.0 farm you love, fine — but do not build a new federation farm for this project. Pass-through authentication covers the "no password hashes leave the building" requirement with two lightweight agents instead of four servers and a certificate rollover ritual.
Mailbox statistics and network math. Get-MailboxStatistics across the estate, sum it, then be honest about your internet egress. A 6,000-mailbox estate averaging 2.5 GB per mailbox is roughly 15 TB. On a 200 Mbps circuit that you can only saturate at night, MRS will move maybe 400–600 GB per night in practice — call it six to eight weeks of steady-state migration, longer once you account for throttling and rescheduled batches. This math, not the tooling, sets your cutover calendar.
The dependency map. Public folders (legacy public folder access from Exchange Online works, but plan the migration or the decommission explicitly), application relay through your Hub Transport servers, journaling, third-party archive stubs. Archive shortcuts from legacy stubbing products are the single worst surprise in Exchange 2010 migrations — rehydration can double your data volume and your timeline.
Sequencing the twelve months
Here is the shape of a hybrid program that finishes comfortably before January 2020, based on estates in the 3,000–15,000 seat range:
- Months 1–3: assessment, directory remediation, identity model decision, licensing procurement.
- Month 3: Azure AD Connect in staging mode, then live. Exchange 2010 SP3 patched to a hybrid-supported rollup.
- Month 4: Hybrid Configuration Wizard, mail flow validation, pilot batch of IT plus 50 friendly users.
- Months 5–8: velocity migration in weekly batches, sequenced by department, with a comms cadence users can predict.
- Months 9–10: stragglers, shared mailboxes, resource mailboxes, public folder migration or retirement.
- Months 11–12: decommission — and yes, you keep one Exchange server on-prem for recipient management if you sync from AD. Budget for that conversation with whoever expected "zero Exchange servers."
Note what is not in this plan: slack for a hardware refresh. If your Exchange 2010 boxes are on hardware from the same era, resist the urge to migrate the VMs somewhere newer "temporarily." Every temporary Exchange server we have ever met had a longer tenure than the consultant who built it.
# The one-liner that starts every assessment we run
Get-Mailbox -ResultSize Unlimited |
Get-MailboxStatistics |
Select-Object DisplayName, ItemCount, TotalItemSize, LastLogonTime |
Export-Csv .\mailbox-stats.csv -NoTypeInformation
That LastLogonTime column matters more than it looks: on a recent 8,000-mailbox assessment, 19 percent of mailboxes had no logon in twelve months. Every one of those you decommission instead of migrating is bandwidth, licensing, and batch-window you get back.
What we tell the estates that will not make it
Some of you are reading this in January 2019 knowing the budget will not unlock until July. Realism helps more than optimism. If you have six months instead of twelve, the plan changes: skip the elegant department-by-department sequencing and run velocity batches sorted purely by mailbox size; defer public folder migration and use legacy on-prem access from Exchange Online as the bridge; push shared mailbox rationalization to after cutover. It is uglier and the ticket volume is higher, but it beats running unsupported.
And if you genuinely cannot start until Q4 2019 — start the directory work now anyway. Azure AD Connect, UPN cleanup, and IdFix remediation cost almost nothing, require no Exchange changes, and remove the slowest, most political part of the project from your critical path. A clean directory in October is the difference between a compressed-but-orderly migration and a death march.
One more thing we say in every kickoff: the migration tool is the least interesting decision in this program. Native MRS moves handle hybrid beautifully. Third-party tools earn their keep in cutover scenarios, G Suite migrations, and tenant-to-tenant work — for a straightforward Exchange 2010 hybrid, spend the tooling budget on communications and floor-walkers for cutover week instead.
If you're facing this
We have run this exact program at every scale from a 400-seat nonprofit to multi-agency government estates, and we have seen where each month of the runway actually goes. If your Exchange 2010 environment does not have a signed-off exit plan yet, get in touch — a two-week assessment now is cheaper than a compressed migration in November.