Migrating Azure Database

Our managed database offering was approaching end of support, forcing a migration of production databases — with strict downtime budgets and finance data where 'mostly migrated' is not a state that exists.

Tenants varied wildly in size. A window acceptable for the median tenant would be a multi-hour outage for the largest, so one-size-fits-all cutover plans were out.

We built a runbook engine: replication to the target, automated checksum verification per table, then a cutover step that flipped connection strings only after verification passed. Every step rehearsed against production-sized copies until timing was boring.

Large tenants got individually scheduled windows; small tenants were batched. The same tooling ran both.

Building tooling first cost two sprints before any tenant moved — a hard sell when 'just migrate it' feels faster. It paid for itself by the third tenant.

All tenants migrated with cutover downtime measured in minutes, zero data discrepancies, and no rollback ever exercised in production (though we rehearsed it every time).

A migration is a product with one user: the person running it at 2am. Design for them.

Verification isn't a nice-to-have step after the migration — it is the migration.