Scaling legacy systems without breaking everything

There's a special kind of courage required to refactor a system that's been running in production since before Docker was cool. It's the same courage you need to rewire a house while someone's watching telly inside — calm, methodical, and acutely aware that one wrong move ends the evening early.

Fig. 01 — From the rope bridge to the cable-stayed one. Same crossing, rebuilt span by span while the traffic kept moving.

The strangler fig pattern

Named after the tropical vine that gradually replaces its host tree, this approach lets you replace pieces of legacy code incrementally. No big bang. No weekend migration. No tears — well, fewer tears.

Traffic routed gradually from old to new.

Map the boundaries first

Find where your legacy system talks to the outside world. HTTP endpoints, message queues, cron jobs, that one FTP integration nobody wants to admit exists. These are your seams — the places where you can intercept traffic and redirect it.

You can't improve what you can't measure. Set up monitoring before you start cutting — request latency, error rates, database load. When something breaks, and something will break, you'll want data, not opinions.

When to actually rewrite

Sometimes the strangler fig dies. Sometimes the codebase is so tangled that incremental change costs more than starting fresh. The signs are usually obvious once you stop hoping they aren't:

The build takes longer than the meeting about the build.
Every dependency is two majors behind and one of them is abandoned.
The only person who understood the auth layer left in 2019.

Every change touches 15+ files

Coupling has won. A one-line behaviour change becomes an afternoon of archaeology.

Nobody understands deployment

The deploy process lives in one person’s head, and that person is on holiday.

Tests outlast the code

The suite takes longer to run than the feature took to write — so nobody runs it.

utils_final_FINAL_v2_BACKUP.php

If this file exists, you already know. I’m sorry.

If you see three or more of these, it might genuinely be time. But go in with eyes open — rewrites fail more often than they succeed, and a rescue that works is almost always cheaper than a rewrite that might.

Most ‘legacy’ systems aren't broken. They're just old. Respect that durability before you reach for the refactoring hammer.