How do you lead a large migration safely?

Question

Accepted Answer

Large migrations, new database, new framework, new platform, are high-risk because they touch everything and deliver no user-visible value until done. The safe approach is **incremental and reversible**, never a big-bang cutover. You migrate in slices you can validate and roll back.

## A safe migration playbook

```text
1. Know WHY — a migration with no clear payoff isn't worth the risk.
2. Migrate INCREMENTALLY — never flip everything at once.
3. Run OLD and NEW in parallel — strangler-fig pattern.
4. Use feature flags / DUAL WRITES to shift traffic gradually.
5. VERIFY continuously — compare old vs. new outputs (shadow traffic).
6. Keep a ROLLBACK path at every step.
7. Clean up the old system only AFTER the new one is proven.
```

## The strangler-fig pattern

Wrap the old system and route slices of functionality to the new one piece by piece, until the old system is fully "strangled" and can be removed. At every point you have a working system and a way back. This is the single most important migration technique.

## A concrete example

Migrating databases: dual-write to both, backfill historical data, read from the new DB for a small % of traffic, compare results, ramp up, and only decommission the old DB once the new one has served 100% cleanly for a while.

## A pitfall

The "big rewrite" that runs for months in a branch and cuts over all at once. It's a classic disaster, you discover the problems all at the worst moment, with no way back.

## Why it matters

Migrations are where teams take on enormous hidden risk for invisible reward, and big-bang cutovers fail catastrophically.

Incremental, reversible migration turns a bet-the-company gamble into a series of small, safe, verifiable steps.