<p>Your application works. It takes payments, it holds ten years of customer data and it's running on a PHP version that stopped getting security patches a while ago. Nobody wants to touch it, and everybody knows something has to happen.</p><p>So the question lands on your desk as a choice: upgrade what you have, or rewrite it. It gets presented as a technical decision. It isn't. It's a decision about how much risk you can carry while still shipping.</p>
Old doesn't mean broken
Legacy usually means undocumented, not bad. The code made sense when it was written, the person who wrote it left, and nobody since has had a reason to read it end to end. That's a knowledge problem more than an engineering one.
So before you decide anything, find out what you actually have. What PHP version is it on? Are there tests? Does it use a framework, a half migrated one, or none at all? Those answers change the recommendation completely.
A rewrite promises a clean slate: modern framework, tests from day one, none of the compromises inherited from 2014. On a slide it's the obvious choice, and every engineer on your team would rather build it than maintain what's there.
What it costs is two systems running at once, a feature freeze nobody agreed to and a launch date that moves. Meanwhile the old application keeps taking orders, and every bug has to be fixed twice.
The honest test is whether your current architecture can hold the next two years of roadmap. Not whether it's pretty. Whether it can carry what's coming.
If it can, upgrade. Move to a supported PHP version first, because that alone often fixes performance problems and closes security holes for a fraction of the cost of anything else. Add tests around the parts that handle money, customer data and login, since those are the parts you can't afford to break. Then replace modules one at a time behind the same URLs, letting new code and old code live side by side until there's nothing left of the old. Each step ships on its own, which means you can stop at any point and still be better off than when you started. That last property is the whole reason it's safe.
If it can't, and the architecture genuinely won't carry the roadmap, then rewrite. Just scope it as a product project with a business case attached, not as a technical cleanup running quietly in the background.
The version you're on is the first thing to fix
Judgment first, frameworks second
We look at those same answers before recommending anything, and we'll tell you when the boring upgrade beats the exciting rewrite. If you want the detail, here's the PHP stack we build on and how we place PHP engineers inside teams doing this work.
<p>Most legacy PHP doesn't need replacing. It needs a supported version, tests where the risk actually is and someone patient enough to retire the old code in pieces. That's less satisfying than a clean slate, and it keeps your business running while it happens.</p><p>If you're weighing this up now, start by writing down what you have rather than what you'd build instead. The decision usually makes itself once you can see it on paper. Our <a href="https://ecomia.com/technologies/php">PHP engineering team</a> does this work with companies who'd rather not find out the hard way.</p>