Rewrites usually fail
A rewrite has to reach feature parity with a system that has absorbed years of business rules, edge cases and undocumented behaviour, while the original keeps changing.
The rewrite that takes eighteen months and is abandoned at eighty per cent complete is a genuinely common outcome, and it costs more than the problem it was meant to solve.
The order that works
- Get onto a supported PHP version — security first
- Get it into version control, if it is not already
- Add a staging environment, so changes can be tested
- Write tests around the parts that matter most
- Then improve incrementally, module by module
Version upgrade first
An application running an unsupported PHP version receives no security fixes. That is the most urgent problem in most legacy applications and it is frequently the easiest to address.
Compatibility checking tools identify what needs changing, and the work is usually smaller than expected for applications that were reasonably written.
Tests before changes
- Test the paths that carry money or customer data first
- Characterisation tests — capture what it currently does, not what it should
- Cover the reports and calculations people rely on
- Do not aim for complete coverage; aim for confidence in the important parts
Tests written around existing behaviour let you change code without discovering the consequences in production.
Strangle rather than replace
New functionality goes into a modern structure alongside the old code, and old functionality moves across piece by piece as it needs changing anyway.
Over a year or two the system modernises without ever being unavailable and without a single high-risk cutover.