Incremental migrations beat big-bang rewrites

Every few months a team tells us the same thing: the old system is holding them back, and they're ready to rewrite it from scratch. The instinct is understandable. The plan is usually a mistake.

The problem with rewrites

A full rewrite asks you to reproduce years of accumulated behavior — including the edge cases nobody remembers — before you can ship anything. During that time you're maintaining two systems, the business keeps asking for new features, and the rewrite slips. The longer it runs, the more pressure builds to cut corners.

The most dangerous phrase in software is "we'll fix it in the rewrite."

A better default: strangle the seams

Instead, we look for natural seams in the existing system and replace one at a time, keeping everything in production the whole way:

1. Put the legacy system behind a thin routing layer.
2. Identify a bounded piece of functionality with a clear interface.
3. Build the replacement, route traffic to it, and delete the old code.
4. Repeat.

Each step ships value, is independently reversible, and keeps risk small. You're never more than one increment away from a working system.

The first seam should be boring on purpose. Pick something visible enough to prove the migration path, but small enough that rollback is obvious. Good first candidates often have a narrow data model, a clear owner, and a workflow people can test end to end without coordinating the whole company.

When a rewrite is actually right

Rewrites aren't always wrong. They can make sense when the platform itself is end-of-life, the domain has fundamentally changed, or the system is small enough to replace in a single short effort. The point isn't "never rewrite" — it's default to incremental, and make the case for a rewrite explicitly.

If you're staring down a legacy system and weighing your options, we're happy to talk it through.