The full rewrite is software's most seductive trap: two years of parallel spend, a feature freeze, and a launch day where the new system meets real data for the first time. There is a better way, and it's been quietly working for decades.
Strangle, don't demolish
Put a routing layer in front of the legacy app. Build each new or rewritten capability as a separate, modern component, and route just that traffic to it. The old system shrinks feature by feature - still running, still earning - until what remains is small enough to retire safely.
Stabilise before you renovate
- Get it in version control with one-command reproducible deploys
- Add characterisation tests around the behaviours you must not break
- Add error tracking - you cannot renovate what you cannot observe
These three steps are boring and worth more than any framework upgrade.
Upgrade the ground floor
Old language and framework versions block everything else - security patches, libraries, hiring. Increment versions step by step (PHP 5 to 7 to 8, Rails 4 to 5 to 6 to 7), running the test suite at each stop. Each step is dull; the compound effect is transformative.
Pick the first slice for signal
Choose a first extraction that's painful enough to matter and small enough to ship in weeks - authentication, search, reporting, a single API. A visible early win buys organisational patience for the rest of the journey.
Then automate what you modernised
Modern components are automation-ready: background jobs, webhooks, AI-assisted workflows. Modernisation isn't the goal - it's the foundation that makes the next decade of features cheap.