Rescuing a codebase without stopping the business
Inherited code is a constraint, not a death sentence — if you climb instead of leap.
Essays are kept in English.
Every stalled platform arrives with the same temptation: rewrite it. Start clean, do it right this time, flip the switch when it's ready. The rewrite is almost always the wrong call, because the thing you'd be rewriting is also the thing paying the bills while you rewrite it.
Freeze, then climb
The disciplined move is unglamorous. Freeze the legacy branches so nothing shifts under you. Stand up a parallel line with strict rules: new code lands beside old, nothing breaks the running product, and every step is written down before it's taken. Then climb the versions one rung at a time, with a green build at every rung. Eight major versions in one migration is not eight leaps; it's eight steps you can stop on.
Climbing is slower to look at and faster to finish, because you never spend a week debugging a fall. The build is always shippable, so the business never holds its breath.
Document the trail, not just the destination
A rescue's deliverable isn't only the modernized stack — it's the written record of how you got there. The migration spec is what turns a heroic save into a maintainable system, because the next person (possibly you, in a year) needs to know why the dependency you removed was load-bearing and the one you kept was a trap.
Done this way, a rescue ends with two things the rewrite never delivers: a current codebase, and a team that still trusts it. The platform that was the ceiling becomes the floor you build the next thing on.