Tenant and subscription migrations are where cloud programs go to get postponed. The blast radius is enormous, the rollback story is usually fiction, and everyone remembers the last migration that took a product down. This is the methodology our engineers used to move 72 production Azure subscriptions serving a global developer platform — with zero downtime and zero customer-impacting incidents.
The constraint that shaped everything
The requirement was not "minimal" downtime — it was zero, on a platform used by millions of developers, where an outage would be public within minutes. That constraint forced a design decision that turned out to be the whole methodology: no step could be taken unless it was verified safe beforehand, verified successful afterward, and reversible in between.
Wave planning: risk-sorted, not alphabetical
We sorted the 72 subscriptions into waves by blast radius, not by convenience: internal and low-traffic subscriptions first, revenue-critical last. Early waves are where your runbook finds its bugs — you want it to find them on the subscription that hosts the test environment, not the one that hosts checkout.
- Wave 1: internal tooling and non-production — runbook shakedown
- Middle waves: production, ascending traffic and dependency count
- Final waves: highest-traffic subscriptions, executed with the most rehearsed runbook
SLA guardrails as go/no-go gates
Every migration step had explicit, machine-checkable success criteria defined before execution: error rates, latency percentiles, authentication success rates, queue depths. KQL queries against live telemetry evaluated each gate. A gate failure froze the wave automatically — no judgment calls at 2 a.m., no "it’s probably fine." The gates decided; humans reviewed.
Rollbacks that were actually tested
Every step had a rollback, and every rollback was executed at least once in rehearsal — a rollback you have never run is a hypothesis, not a safety net. Rehearsals happened in a staging tenant sized to mimic production topology, and the runbook was automated with PowerShell and Azure DevOps pipelines so that rehearsal and production execution were the same code path.
The human system around the machine
A migration this size is an operations exercise as much as an engineering one: a single coordination channel, named roles per wave (executor, verifier, comms), and a standing rule that anyone could halt the wave without justification. Over the full program, the halt was used a handful of times — and every halt was cheaper than the incident it prevented.
What transfers to your migration
- 01Define machine-checkable success gates before touching anything — if you cannot query it, you cannot verify it.
- 02Sort waves by blast radius and let early waves debug your runbook.
- 03Automate the runbook; rehearsal and production must be the same code.
- 04Test every rollback at least once before you need it.
- 05Make halting free. The cultural permission to stop is a technical control.
The result: 72 subscriptions, zero downtime, zero customer-impacting incidents — and a verification framework the client reused for every platform change after. If you have a migration on the roadmap that keeps getting postponed, our free audit includes a migration risk assessment using exactly this framework.