The 2010s are nearly over, and we have spent effectively the whole decade moving things: 15,000-plus mailboxes into Office 365 across government and enterprise tenants, multi-forest Active Directory consolidations, SharePoint farms through two version jumps, 400-plus servers from physical tin onto Hyper-V, Lotus Notes estates that everyone swore were unmigratable, and lately Windows 7 fleets sprinting toward their January deadline. Different workloads, different decades of source technology, different clients — and, when a project went sideways, remarkably similar reasons.
So this post is our end-of-decade retrospective, written as the thing we actually keep: a list of rules. These are not aspirations. Each one is a scar. Each one has, at some point, been broken by someone — occasionally us, in the early years — and the resulting weekend is why the rule exists. We hand a version of this list to every new project team, and we have declined engagements where the client insisted on breaking rule one or rule six.
They are ordered roughly by when they bite: planning rules first, cutover rules last.
Rules one through three: what you don't know will schedule itself
Rule 1: The assessment is the project. Every migration disaster we have been called in to rescue skipped or rushed discovery. The 15,000-mailbox government program we ran spent its first six weeks producing nothing but an assessment deck — mailbox statistics, network egress math, ADFS dependency mapping, third-party integrations that authenticated against Exchange in ways nobody had documented since 2011. That deck felt slow at the time. It is the reason cutover weekends were boring. When a prospect tells us their environment is "pretty standard," we now mentally add 20 percent to the discovery estimate, because that phrase has a perfect correlation with undocumented SMTP relay sprawl.
Rule 2: Inventory is a contract, not a spreadsheet. The inventory you produce in discovery becomes the definition of done. Every mailbox, every content database, every server on the list either arrives at the destination, is verifiably retired, or has a signed exception. This is how we have kept a zero-data-loss record across hybrid Exchange and SharePoint programs: not heroics, but a reconciliation report at the end that matches the inventory at the start, row for row. If an item can't be found at cutover time, that is a finding, not a shrug.
Rule 3: Map identity before you touch data. Mail, files, and applications all hang off identity, and identity problems surface as data problems three weeks later. UPN suffixes that don't match SMTP addresses, duplicate proxyAddresses, SID history from a forest consolidation nobody finished in 2012 — we run the directory hygiene pass first, every time. On multi-forest consolidations this is most of the project; ADMT and the actual object moves are the short final act after months of GPO rationalization, naming standards, and trust design.
Rules four and five: pilots are for finding pain, not proving success
Rule 4: Pilot with hostile users, not friendly ones. The instinct is to pilot with IT and the project sponsors — people who tolerate breakage and know who to call. That pilot always succeeds and always lies. We build pilot cohorts deliberately: one executive assistant with delegate access to four calendars, one power user with a 40 GB mailbox and 200 Outlook rules, one field worker on a bad connection, one department that runs a line-of-business app bolted to the workload being moved. The Notes-to-Office 365 program taught us this: the friendly pilot passed clean, and the first real wave surfaced calendar fidelity issues that a properly hostile pilot would have caught a month earlier.
Rule 5: The pilot's exit criteria are written before the pilot starts. If you define success after the fact, everything is a success. We write measurable exit criteria — free/busy resolves cross-premises in both directions, profile load under a stated threshold, zero sev-1 tickets in the cohort for ten business days — and the pilot doesn't exit until they pass. Twice this decade a pilot has failed its criteria and forced a redesign. Both times the client was annoyed for a week and grateful for a year.
Rules six and seven: rollback and the honesty of timelines
Rule 6: No step without a tested way back. Not a theoretical way back — a tested one. Before we cut over mail flow on any hybrid program, we have already rehearsed pointing MX and autodiscover back and measured how long it takes. Before a content database attach, the source farm is read-only, not gone. The rule sounds obvious and is broken constantly in the wild, usually under schedule pressure, usually at the exact step where rollback matters most. A vSphere replication DR test we ran a couple of years ago found a single point of failure in DNS precisely because we insisted on actually executing the failback, not just diagramming it.
Rule 7: Velocity is measured, never assumed. Vendor tools quote throughput under lab conditions. Your throttling, your network egress, and your source-side disk tell the real story. We migrate a measured sample — a few hundred mailboxes, a few terabytes of content — then extrapolate the schedule from observed numbers with a contingency factor. On the big mailbox programs our observed steady-state velocity has occasionally been half the tool vendor's brochure figure, and knowing that in week two instead of week ten is the difference between adjusting wave plans and explaining a slipped go-live to a CIO.
Rules eight and nine: people find out from you, or they find out anyway
Rule 8: Communications have a cadence, and the cadence survives good news and bad. Users forgive disruption; they do not forgive surprise. Every program gets a comms calendar: what's changing, when, what the user does differently, who to call — sent on a rhythm that does not flinch when the news is a delay. On the government programs, where the user base includes people who have used the same mail client for fifteen years, the comms track had its own workstream lead. Worth every hour. The cheapest ticket is the one a user never opens because the email told them the new sign-in page was coming.
Rule 9: The help desk is a migration stakeholder, not a downstream victim. Ticket volume during a wave is a design input. We brief tier one before every wave with a one-page cheat sheet — the five expected symptoms and the fix or escalation path for each — and we watch ticket categories live during cutover as our early-warning telemetry. When "can't open shared calendar" tickets spiked during one Exchange wave, the help desk saw it forty minutes before our monitoring did. They are your best sensor if you treat them like part of the crew.
Rule ten: boring is the deliverable
Rule 10: A successful cutover is one where nothing interesting happens. We optimize for boredom. Cutover runbooks are written to the level of exact cmdlet invocations with expected output — Move-DatabasePath doesn't appear without the exact parameters next to it — timed against a rehearsal, with named owners and a go/no-go checkpoint that someone is genuinely empowered to fail. The best cutover of our decade was a multi-thousand-mailbox final wave where the war-room bridge went silent for two hours because there was nothing to say. That silence was purchased by every rule above.
There is an eleventh rule we almost included: never migrate and upgrade in the same motion unless the platform forces you. It got cut from the canonical ten only because it is really rule one wearing a trench coat — the assessments that miss this are the assessments that were never done. SharePoint 2010 to 2013 database-attach programs taught us that combining a farm redesign with a version jump doubles the variables and squares the debugging time.
A decade from now the workloads will be different — less Exchange on-prem to move, presumably; more tenant-to-tenant and cloud-to-cloud. We would bet the rules survive unchanged, because none of them are about technology. They are about the fact that migrations are risk-transfer engines run by tired people under deadline, and the rules exist to keep both the risk and the people intact.
If you're facing this
If you have a migration on the 2020 calendar — Exchange 2010's October deadline, a directory consolidation, a farm move, a Windows 10 sprint — we are happy to pressure-test your plan against this list. It takes an hour, it is occasionally uncomfortable, and it is much cheaper than learning any of these rules the way we did. Get in touch.