Rebuild or modernise? Deciding what to do with a legacy PHP site
Old jQuery and PHP applications still running the business are a common problem. Here is how to decide between a rewrite, an incremental migration, and leaving it alone.
A lot of businesses are running on something built between 2010 and 2018. It works, people rely on it daily, and everyone is slightly afraid of it. The developer who wrote it has moved on, changes take longer than they should, and somebody has started using the phrase “we should probably rebuild it”.
Maybe. Rewrites fail more often than people admit, and “it is old” is not on its own a reason to spend money.
First, work out what is actually wrong
The word “legacy” hides several different problems, and they have different fixes.
It is slow. Often this is a handful of unindexed database queries and some unoptimised images, not the architecture. This is the cheapest problem to have and it is worth ruling out before anything else.
It is insecure. An unsupported PHP version, a framework years behind on patches, dependencies nobody has updated. Real and urgent — but usually an upgrade, not a rebuild.
It is hard to change. New features take weeks, and every change breaks something elsewhere. This is the one that genuinely justifies structural work.
It cannot do what the business now needs. The company has outgrown the model the software was built around. This is the strongest case for starting over.
Be honest about which of these you have. “Hard to change” and “developers dislike it” feel similar from the inside and are not the same thing.
The three real options
Leave it alone, and secure it
Underrated. If the system is stable, the business is not blocked by it, and the risk is patching, then patch it. Upgrade PHP and dependencies, fix the security issues, add backups and monitoring, and spend the rest of the budget somewhere it generates revenue.
The test: is this software actively costing you opportunities, or is it just unfashionable?
Modernise in stages
Usually the right answer for a system the business depends on daily. You put the new application in front of the old one and move functionality across a piece at a time — new routes go to the new code, everything else falls through to the old.
It is slower in total, and for a while you maintain two things. But you are never more than a few weeks from working software, you can stop or reorder at any point, and you are not asking the business to freeze while you rebuild.
Rewrite
Justified when the data model itself is the problem, when the system is small enough to rebuild quickly, or when the old stack genuinely cannot support what you need next.
The risk is well documented: rewrites take longer than estimated, the old system keeps needing changes while you work, and eighteen years of accumulated edge cases live only in that code. Every strange conditional is usually a real business rule somebody discovered the hard way.
If you rewrite, do it with the old system running and a plan for switching over gradually.
Things people forget until it hurts
The data is worth more than the code. Ten years of orders, customers and history. Migration is often the largest and least glamorous part of the project, and it deserves proper planning rather than a week at the end.
SEO does not carry itself across. If the site brings in traffic, URL changes without correct redirects can cost you months of rankings. Map every URL before launch, not after.
Integrations are a hidden surface. The payment gateway, the accounting export, the thing somebody’s spreadsheet pulls from every Monday morning. Find them all first — there is always one nobody mentioned.
Undocumented behaviour is a specification. Before removing an odd-looking rule, find out who depends on it. Someone usually does.
How we would approach it
We start with an audit rather than a proposal: what the code and data look like, what the actual risks are, and what it would take to fix each of them. That usually produces a clearer picture than the assumption people walked in with.
Often the outcome is smaller than expected — a security and performance pass, plus one genuinely painful area rebuilt properly. We would rather tell you that than sell you a rewrite you did not need. A fair amount of our eighteen years was spent in exactly this kind of PHP codebase, which is mostly why we are relaxed about working in them.