Exchange 2010 left extended support one week ago, on October 13, 2020. The date had been public since forever, was extended once by a full year, and was preceded by more vendor and community warnings than any product retirement we can remember. And yet: we spent the last ninety days running compressed migrations for estates that had known about this deadline for at least four years, and we are, this week, still fielding first calls from organizations that missed it entirely.
This is not a lecture. We have moved more than 15,000 mailboxes to Office 365 over the years, most of them off Exchange 2010, and the estates that lagged were not run by fools. They were run by competent people inside organizations whose structures made lateness the rational outcome. That is worth a post-mortem, because the same structures are already producing the next round of lateness — Windows Server 2008 R2 was this exact story in January, and Exchange 2013's own end of support is out there on the horizon.
So while the last cutover weekend is fresh, here is what a decade-long goodbye actually looked like from the inside, and the patterns that separated the calm migrations from the frantic ones.
The lag was never about the mailboxes
Nobody stayed on Exchange 2010 because moving mail is hard. Native hybrid moves are a solved problem; the MRS has been quietly excellent for years. In every late estate we touched this year, the mailboxes were the easy 60 percent. The anchor was always one of three things:
Application dependencies. The 2,400-mailbox county government we moved in September had eleven line-of-business applications sending mail through the 2010 CAS array — permit systems, a court records app, two things written in classic ASP that nobody would claim ownership of. Three of them had the Exchange server name hard-coded. Not the namespace: the server name. Every one of those was a small project with a vendor, a change board, and a test window, and none of them appeared on any inventory until we pulled the message tracking logs.
Relay sprawl. Related but worse, because it is invisible. Receive connectors accepting anonymous relay from subnets, MFDs, backup appliances, UPS management cards, monitoring systems. On one 1,900-mailbox manufacturer we counted 340 distinct sending IPs in thirty days of tracking logs. The mail system was not a mail system; it was the organization's unofficial message bus, and decommissioning it meant finding every client of that bus.
Budget geometry. The most common non-technical anchor. A migration that costs real money and delivers "the same email, but somewhere else" loses the FY19 budget fight to anything with a visible business outcome. Then it loses FY20 to the pandemic. The deadline finally converts it from a discretionary project into an emergency, at emergency prices. Several of our fall engagements cost their organizations meaningfully more than the identical project would have in 2019 — compressed timelines burn senior hours.
What the message tracking logs always knew
If we could institutionalize one habit from this year, it is this: the discovery phase lives in the logs, not in interviews. People's mental model of their mail estate is years out of date. The tracking logs are not.
Get-MessageTrackingLog -EventId RECEIVE -Start (Get-Date).AddDays(-30) `
-ResultSize Unlimited |
Where-Object ConnectorId -like "*Relay*" |
Group-Object ClientIp | Sort-Object Count -Descending |
Select-Object Name, Count | Export-Csv .\relay-clients.csv -NoTypeInformation
Thirty days of RECEIVE events, grouped by client IP, is the true inventory of everything that will break when the server goes away. We run it in the first week of every engagement, and it has never once matched the client's documented list. The gap on this year's projects ranged from 3x to, on the county estate, roughly 10x. Every IP in that CSV either gets a migration path to a new relay, an authenticated submission endpoint, or a documented decision to let it die. The ones you skip are the ones that page you in November.
The same principle applied everywhere else: Get-CASMailbox told us who really used ActiveSync, IIS logs told us which OWA URLs mattered, and mailbox statistics told us the actual data volume — which, on average, was about 35 percent larger than the client's estimate, because archives and recoverable items are invisible to intuition.
Patterns from the ones that went well
Not every 2020 migration was a fire drill. The estates that moved calmly — including a multi-domain government program we completed with zero data loss and no unplanned outage — shared traits worth stealing:
- They treated the deadline as a program constraint from day one, not a stretch goal. The project plan counted backwards from October 13 with a four-week buffer, and the buffer was spent (it always is) on the application relay work, not the mailboxes.
- They ran a real pilot cohort. Fifty to a hundred mailboxes, deliberately including the ugly cases: delegates, shared mailbox webs, the executive with 90 GB and a 2009-era PST habit. The pilot exists to make the failure modes cheap.
- They separated data movement from ecosystem work. Mailboxes first, behind the deadline; public folders, relay rationalization, and archive re-platforming as funded, scheduled phase-two items. Coupling them is how you slip.
- They communicated on a cadence, not on events. A weekly one-pager to affected users beats a heroic all-staff email the night before cutover. Our helpdesk-ticket rates on well-communicated waves ran at roughly a third of the poorly-communicated ones — same tooling, same process, different inbox on Monday.
None of this is clever. It is the same playbook we published in our decade-of-migrations retrospective last December. The difference between reading a playbook and funding one is the whole story of this deadline.
The ones still running it
And then there is the population that did not make it: the estates running unsupported Exchange 2010 today. Some of them are ours — bucket-three clients from last month's triage, isolated, documented, with signed risk acceptances and committed exit quarters. That is a defensible, temporary posture.
The indefensible version is the estate that simply rolled past October 13 with internet-facing OWA and no plan. We will say this plainly, and without drama: an unpatchable, internet-exposed mail server is precisely the asset class that attackers industrialize against. It is not a question of whether Exchange CVEs will be published that 2010 never receives fixes for; the product's own history answers that. If this is you, the sequence is: get client access off the internet this week, get the risk accepted in writing by someone with authority, and get a migration on the calendar with a quarter attached. In that order. The first item takes an afternoon.
What we would tell 2016 us
Closing the loop, because we opened this notes series in July 2016 with the assessment phase of a 15,000-mailbox Exchange 2010 estate. Four years later, having watched the full distribution of outcomes:
- The assessment deck really did matter more than the migration tool. Still true; more true.
- We underweighted relay discovery in our early methodology. It is now week one, always.
- We overestimated how much end-of-support dates motivate organizations, and underestimated how much cyber-insurance questionnaires and audit findings do. The compliance artifact moves budgets; the calendar does not.
- Ten years is exactly long enough for the people who deployed a system to leave, taking the reasons for every configuration with them. Documentation debt compounds like the financial kind.
Exchange 2010 was the platform that made the DAG normal, made large cheap mailboxes normal, and trained a generation of us. It deserved a better ending than the one many estates gave it. The way to honor a workhorse is to retire it on purpose.
If you're facing this
If October 13 came and went with your Exchange 2010 still in production, the situation is recoverable but the posture work cannot wait for the migration project. We can assess an estate in days, contain the exposure immediately, and put a realistic exit plan in front of your leadership. Get in touch before an auditor — or someone worse — does the discovery for you.