📖 Business
Biz - Migrations Over Rewrites
Larson's argument that the only sustainable approach to technical debt at scale is incremental migration, not heroic rewrites. Rewrites are exciting — they get executive buy-in, energize engineers, and promise a clean slate. They also fail at a remarkably high rate. Migrations are boring, incremental, and reversible. They also actually work. The distinction is not about ambition but about compounding: migrations teach the organization how to change, while rewrites are one-off heroics that leave no institutional muscle.
2
Minutes
2
Concepts
+45
XP
1
How It Works
Why rewrites fail:
- The old system keeps getting patched while the new system is being built, so the target keeps moving.
- The rewrite team underestimates the accumulated edge cases embedded in the old system.
- Organizational patience runs out before the rewrite is complete, and you end up running both systems indefinitely — the worst outcome.
Migration design principles:
- Write the migration guide — document exactly how to move from system A to system B. If you can't write the guide, you don't understand the migration well enough.
- Embed the migration into existing workflow — it should not be a separate project with a separate team. Engineers migrate their own services as part of normal sprint work.
- Track progress with a dashboard — percentage of services migrated, visualized and shared publicly. Social pressure and visibility drive completion.
- Set a cleanup date — a hard deadline after which the old system is turned off. Without this, the long tail of migrations never finishes.
The compounding effect: each successful migration builds organizational confidence and tooling that makes the next migration cheaper and faster. Rewrites build nothing reusable.