From Exchange 5.5 to Exchange Online: what three decades of messaging taught me

I started working with Exchange when it was version 5.5, running on Windows NT, with its own directory. I now work with Exchange Online, where the mailbox is a service and the directory is Microsoft Entra ID. Almost every implementation detail between those two points has been replaced.

The design questions have not. Looking back, the same four problems appear in every generation, wearing different clothes: where identity lives, how messages are routed, what happens to the data over time, and who can read someone else’s mail.

Identity: the problem that kept being re-solved

Exchange 5.5 had its own directory, separate from the Windows NT account database. Two directories, one organisation, and a constant reconciliation problem between them. The question “who is this person, and which mailbox is theirs” required joining two systems that did not agree.

Exchange 2000 moved the directory into Active Directory, which was correct and which created the dependency that still shapes everything. Exchange became an Active Directory application. Recipient objects became directory objects. The schema extension became one of the more consequential things an organisation could do to its forest.

Microsoft 365 moved the authoritative directory to the cloud — except where directory synchronisation is running, in which case Active Directory remains authoritative for mail-enabled objects and the cloud object is a projection. That is precisely why the last on-premises Exchange server is so hard to remove, as covered in Exchange hybrid, still running in 2026.

Thirty years, three directory architectures, and the same question each time: which system is authoritative for this attribute, and what happens when two systems disagree? I have never worked on a messaging problem where that question was not worth asking first.

Routing: from site connectors to connectors

Exchange 5.5 routed by site, with connectors between them and a topology you designed explicitly. Exchange 2000 and 2003 introduced routing groups. Exchange 2007 removed them in favour of Active Directory sites. Exchange Online routes through Exchange Online Protection and connectors you define for the paths that leave the service.

The mechanism changed entirely. The failure mode did not: a message goes somewhere unexpected, or nowhere, because a routing decision was made by a rule nobody remembered. The diagnostic instinct is identical across all of them — find the record of what the system actually did with this message, and read the sequence rather than the outcome. That is the whole basis of tracing a message through Exchange Online mail flow.

What genuinely improved is the evidence. Getting a definitive routing answer out of Exchange 5.5 meant message tracking logs on each server and a lot of correlation by hand. Exchange Online gives you the same answer in one query. The skill that transfers is knowing what question to ask.

Migration: the work that never stops

I have done Exchange migrations across several generations. In one role with a global manufacturing enterprise between 2008 and 2012, I migrated several thousand mailboxes from Exchange 2003 to Exchange 2007 and Exchange 2010, including cross-forest migration and consolidation.

What that taught me, and what every subsequent migration confirmed:

Coexistence is the project. Moving a mailbox is a solved problem with a supported tool. The difficulty is the period where both systems are live: free/busy across the boundary, mail routing during the transition, client autodiscovery finding the right endpoint, and delegate permissions that work differently on each side. The cutover is a day; coexistence is months.

The directory is the risk, not the mailbox. Cross-forest migration is an identity exercise. Object matching, attribute authority, and what happens to a mailbox whose account was recreated rather than moved. A mailbox that fails to move is an inconvenience; a duplicate identity is an incident.

The inventory is always incomplete. Every migration surfaces applications relaying through Exchange that nobody had recorded — devices, line-of-business systems, scripts written by someone who left. This is still true today and it is still the thing that blocks decommissioning.

Public folders and delegated permissions outlive their usefulness. Both carry business process that nobody documented, and both are discovered during migration rather than before.

None of this changed when the destination became a cloud service. The tooling improved considerably; the shape of the work did not.

Data: retention arrived late and changed everything

Early Exchange treated the mailbox as storage with a quota. The design question was how big the database could get before backup and restore times became unacceptable, and the answer shaped everything — storage groups, database sizing, the recovery time you could promise.

The shift to retention as a first-class concern — litigation hold, retention policies, and now the wider governance in Purview — changed the question from “how do we keep this small” to “what are we legally required to keep, and for how long, and who decides”. That is a better question, and it is not a messaging question. It belongs to legal, records management and compliance, with messaging as the implementation.

The engineering consequence is that deleting mail is now a governed act rather than a housekeeping one, and that an engineer who cannot say who authorised a retention setting has a problem that no amount of technical competence solves.

Access: the question that got harder

“Who can read someone else’s mail” was, in 5.5, a permissions question with a small number of answers. Delegate access, a service account for a backup agent, an administrator with sufficient rights.

It is now a much larger surface. Delegate and full-access permissions still exist, but so do applications with Graph permissions that can read every mailbox in the tenant, forwarding rules that quietly copy mail outside the organisation, consented OAuth grants that survive a password reset, and eDiscovery tooling that legitimately reads everything.

This is the area where the product genuinely got more dangerous, not less. An application permission granted once can read every mailbox indefinitely, and it does not appear in any mailbox’s permission list. The relevant discipline is in application consent in Microsoft Entra ID, and it is the part of messaging administration that changed most in thirty years.

What actually transferred

Looking at it honestly, the product knowledge did not transfer. Storage group design, routing group topology, the specifics of an Exchange 2003 cluster — none of it is useful now, and I would not claim otherwise.

Four habits did:

Ask what is authoritative. Almost every difficult messaging problem is two systems disagreeing about the same object.

Get the evidence before forming a theory. The tooling changed; the discipline of reading what the system recorded, in sequence, before deciding what happened, did not.

Assume the inventory is wrong. Whatever list you have been given of what depends on this system, something is missing from it, and you will find out during the change.

Treat coexistence as the real work. Any migration’s difficulty lives in the overlap, not in the move.

The generation after this one will replace the implementation again. Those four will still apply.

A note on what this article is

This is a reflective piece rather than a procedure, and the technical claims in it are about products whose current behaviour is documented elsewhere. Where I have described my own work, I have kept it to what I actually did: the mailbox migration figures and the cross-forest consolidation above are from my own experience, and I have not attached outcomes or metrics to them that I cannot evidence.

For current Exchange work, start with Exchange hybrid, still running in 2026 and the EWS retirement readiness plan, both of which describe the state of the platform now rather than the shape of its history.

References

• Exchange Server editions and versions
• Exchange Server Subscription Edition lifecycle
• Mail flow in Exchange Online
• Retention policies and retention labels