Should you rewrite the legacy PHP app, or modernise it in place?

Why rewrites overrun

A working system encodes years of decisions that nobody wrote down — the VAT edge case for one customer, the export format a partner depends on, the reason that field is nullable. None of it is in the specification because there is no specification. It is in the code, and often only in the parts that look wrong.

A rewrite has to rediscover all of it, usually by shipping something that does not handle it and finding out from an angry customer. That is the real reason rewrites take two or three times the estimate: the estimate covered the features you know about.

The questions that actually decide it

• Does it still run on a supported PHP version, or can it be made to?
• Is there any test coverage at all, even a handful of integration tests?
• Is the data model sound, or is the schema itself the problem?
• How much of the code is genuinely used? Dead code inflates the apparent size.
• Is anyone still available who knows why it works the way it does?

If the data model is sound and the code merely dated, modernise. Schema problems are the strongest genuine argument for a rewrite, because you cannot refactor your way out of a structure that cannot represent what the business now does.

What modernising in place actually looks like

It is not a rewrite in slow motion. It is a sequence of changes each of which leaves the system working and shippable.

Get it onto a supported PHP version first — that alone closes security holes and usually brings a performance gain for free. Put it under version control properly if it is not already. Add integration tests around the parts that handle money, because those are the ones you cannot afford to break. Extract the worst-coupled logic behind a clear interface. Then, and only then, start replacing what sits behind that interface.

The advantage is that you can stop at any point and still have a working system that is better than it was. A half-finished rewrite has no such property.

The strangler pattern, in plain terms

Put the new system in front of the old one as a router. Every request checks whether the new code handles that route; if not, it passes through to the legacy application untouched.

You then move one route at a time. Both systems run together, usually against the same database, and traffic shifts gradually. When the last route moves, the old system is removed. It is slower than a clean rewrite in theory and much faster in practice, because you are never in a state where nothing works.

When a rewrite genuinely is the right call

The data model cannot represent what the business needs now. The language or framework is so far out of support that no upgrade path exists. The system is small enough that the entire behaviour genuinely fits in one person's head. Or it is being replaced by an off-the-shelf product anyway.

Those are real. The code is ugly is not, on its own, one of them. Ugly code that processes payments correctly is worth more than elegant code that does not yet.