Rewrite or Modernise? How to Decide for a Legacy PHP Application

Sooner or later, everyone who owns an old PHP application asks the same thing: wouldn't it be cleaner to just start again? It's a reasonable question. The old code is painful, the new tools are nicer, and a blank repository feels like relief.

Our honest answer is that most of the time it isn't the right call, and sometimes it clearly is. The skill is telling the two situations apart before you've spent the money.

Why rewrites go wrong

The classic warning comes from Joel Spolsky's 2000 essay "Things You Should Never Do, Part I", which looked at Netscape's decision to rewrite its browser from scratch. The argument still holds up. A few specific reasons rewrites struggle:

• The old code contains decisions nobody wrote down. That odd condition in the checkout, the workaround for one payment provider, the rounding rule an accountant asked for: each one looks like noise to someone reading it fresh, and each one exists because something once went wrong. A rewrite throws them out and then rediscovers them, one incident at a time.
• The business doesn't stop. While the new system is built, the old one still needs fixes and features. Either you keep paying for both, or you freeze the product for months, and freezes rarely survive contact with the sales team.
• You can't see progress. A rewrite usually produces nothing a customer can use until it's nearly finished. That makes it easy to lose confidence, budget and momentum halfway.
• The second system tends to bloat. With a clean slate, every wish gets added. The new system takes longer than planned, and by then the requirements have moved.

Why modernising in place usually wins

Incremental work delivers value in every step. You fix the dangerous part, ship it, and the system is better the same week. If priorities change, you stop and nothing is wasted, because every completed step already improved production. The old behaviour stays in place until you have a reason and a test to change it.

It's also easier to estimate. Each slice is small enough to size honestly, which is more than you can say for "build everything again".

When a rewrite is the right call

We do recommend rebuilding sometimes. Here are the situations where it tends to make sense:

• The platform has no path forward. If the product you're built on is end-of-life with no supported upgrade, the choice is between rebuilding on its successor and staying exposed. Magento 1 is the best-known example, and we cover the options in Magento 1 end of life.
• The application is small. If a developer can read all of it in a week, rebuilding it carries a modest risk, and may be quicker than working around it.
• The product has changed so much that the old code solves a different problem. If you'd keep only a small fraction of the existing behaviour, there isn't much to preserve.
• The security model is wrong at the root. Patching individual holes isn't enough when authentication or data access is flawed throughout the design.
• Nobody can work on it. If the technology is so obscure that you can't hire or contract anyone who can maintain it, the system is a liability whatever shape the code is in.

Notice that "the code is ugly" isn't on the list. Ugly code that works and is understood can be made good, one piece at a time.

Questions that settle it

When we help a team decide, these are the questions that matter most:

1. Does the application do its job today, even if it does it badly? If yes, there's a lot of embedded knowledge worth keeping.
2. Can it be run on a supported PHP version, with some effort? If yes, the runtime isn't forcing your hand.
3. Could you add tests around the important behaviour? If yes, you can change it safely in pieces.
4. Is there a supported upgrade path for the platform underneath? If no, you're closer to a rebuild.
5. How long can the business tolerate slow feature delivery? A rewrite costs you that time. Be realistic about the answer.
6. Do you know what the application does well enough to specify it? If nobody does, you'll be discovering requirements during the rewrite, and that's the expensive way.

Mostly "yes" answers point to modernising. Mostly "no" answers point to rebuilding, or at least to a much deeper investigation first.

You don't have to pick one

The useful middle route is replacing the system piece by piece. You choose one part that hurts, such as billing, reporting or the customer area, rebuild only that, and route traffic to the new version while the rest stays untouched. The old system shrinks until there's nothing left worth keeping. We explain the mechanics in running old and new PHP side by side.

Splitting a monolith into many services is a different and much heavier decision. It solves problems of scale and team size, not problems of age. We look at when it pays off in converting monoliths to microservices.

A test that costs very little

Before committing to anything big, take one small, low-risk feature and deliver it through the new approach, all the way into production, within a few weeks. If the team can't do that, they won't manage the whole system, and you've found out cheaply. If they can, you have a working pattern to repeat and the evidence to justify the next step.

Common questions

Isn't a rewrite cheaper in the long run?

Sometimes, but it's rarely cheaper in the short run, and the long-run saving depends on the rewrite finishing and matching the old behaviour. Plenty don't.

Our developers want to rewrite it. Should we listen?

Take the frustration seriously, since it points at real problems. Then ask which specific problems a rewrite would fix, and whether each could be fixed in place for less.

What if the original developers left and nobody understands the code?

That's an argument for investigating before deciding, not for rewriting. Our guide to documenting an undocumented codebase covers how, and the modernisation roadmap shows where it fits.