Rewrite or fix in place? How we decide with legacy PHP

Almost every legacy project we are called into starts with the same suggestion from someone in the room: the old system is a mess, so let’s rebuild it properly. It is an understandable instinct. It is also the decision we push back on most often.

Why rewrites go wrong

An old system is ugly partly because it has been fixed so many times. Each odd if statement is a rule someone learned the hard way: a district that reports differently, a fee waived for one category, a report format the finance department insists on. Nobody wrote these rules down. They live only in the code.

A rewrite throws all of that away and then spends months rediscovering it, usually after launch, usually from angry users. Meanwhile the old system still has to run, and still has to be kept secure, because the new one is not ready yet.

The questions we ask

• Does the system still do roughly what the organisation needs? If the business process has completely changed, that changes the answer.
• Is the data model sound, even if the code around it is not? A good database is the hardest part to replace and the easiest to build on.
• How much of the risk sits in a small part of the code? It is often login, uploads and a few search screens.
• Is there anyone left who understands the business rules? If not, the code is the only documentation you have.
• What happens if the new system is a year late? For a public service that cannot stop, that question usually settles it.

What we usually recommend

For most systems: secure it now, then modernise it in pieces. Close the serious vulnerabilities first. Get the code into version control and set up a staging copy. Upgrade PHP to a supported version. Then move one module at a time into a structured framework such as Laravel, with the old and new parts running side by side until the old part can be switched off.

It is less exciting than a rebuild, but the system is safer within weeks rather than years, and nobody has to pause a public service while waiting for version two.

When a rewrite really is right

Sometimes it is. If the data model is broken, if the process the system supports no longer exists, or if the code is so tangled that every change breaks two other things, starting again can be cheaper. We will say so when we see it. The point is to make that call on evidence from an audit, not on how the code looks at first glance.