Rewrite, refactor or upgrade?

How to decide what to do with an old PHP application, before someone sells you the most expensive option.

If you've been told your application "needs a rewrite", you're facing one of the biggest spending decisions your software will ever involve. A rewrite is sometimes right. It is rarely the first thing to try, and it should never be decided without evidence.

This guide explains the options in plain English, when each one fits, and the questions that settle it.

Book a free conversation Legacy System Assessment, from £2,500

The short answer

Upgrade when the application still does its job but runs on unsupported software. It's usually the cheapest and lowest-risk move.
Refactor when the application works but is hard and expensive to change. You improve the code in stages, without changing what it does.
Rewrite when the application no longer fits the business, or the code is beyond saving. It's the most expensive and risky option, and it throws away embedded knowledge.
Replace (with off-the-shelf or SaaS software) when your needs are no longer special. Many old bespoke systems were built before good alternatives existed.
Leave it alone when it's stable, low-risk and rarely changes. Not everything old needs work.

Most legacy applications need some mix of upgrade and refactor, in stages. The right mix is a decision for evidence, not instinct.

The options

Option	What it means	You keep	Typical risk
Upgrade	Move to supported PHP, framework, database and server, fixing what breaks	The application and its behaviour	Low to medium, if tests exist or are built first
Refactor	Improve the structure of the code in small steps, without changing behaviour	The application and its business rules	Low per step, if each step is tested
Rewrite	Build a new application from scratch to do the same job	Only what you can rediscover and rebuild	High: cost, time and lost business logic
Replace	Move to a packaged product or service	Your data, and whatever you can configure	Medium: migration and fit
Leave alone	Keep it running, with monitoring and backups	Everything, including the risk	Grows over time if unsupported

PHP upgrade service

Why rewrites are risky

A 20-year-old application isn't just old code. It's 20 years of decisions: the odd discount for one customer, the report only finance understands, the exception somebody asked for in 2011. Nobody wrote them down. They live in the code.

A rewrite has to rediscover all of it. The usual problems:

Hidden business rules get lost, and surface only when a customer notices.
You pay twice. The old system must keep running while the new one is built.
Scope grows. "While we're at it" turns a rewrite into a new product.
Feature work stalls, because the team is busy building the thing that replaces the thing.
Data migration is harder than it looks. Twenty years of data rarely fits a clean new design.
Timescales slip, and the business can end up carrying the old system's risks for longer than planned.

None of this makes a rewrite impossible. It means the case for one should be strong, and based on what's actually in your system.

When a rewrite is the right answer

A rewrite or replacement makes sense when:

The business has changed and the application no longer fits how you work, and changing it costs more than rebuilding
The technology can't be rescued. For example, it depends on a platform that no longer exists and can't be moved
The code is genuinely unmaintainable, and investigation shows the logic can't be safely extracted or tested
A good packaged product now does the job, and your needs are no longer special
You need a fundamentally different architecture, such as a multi-tenant product from a single-customer system
The cost of keeping it alive exceeds the cost of replacing it, shown by evidence and not by feeling

If most of those are true, say so and plan it properly. A rewrite you've chosen with your eyes open is a very different thing from one you've been pushed into.

The middle path: replace it piece by piece

You don't have to choose between "keep everything" and "start again". A common approach is incremental replacement: build new parts alongside the old system and move functions across one at a time, until little of the original is left.

Each step is small and reversible.
The business keeps running throughout.
You learn what the old system really does as you go.
You can stop at any point, and still have something better than before.

It's slower to describe than "rewrite" and often much safer in practice.

Questions that settle it

Work through these. They're the questions I'd ask in an assessment.

Does it still do the job? If yes, the case for a rewrite is weak.
What exactly is wrong? Is it unsupported software (upgrade), hard-to-change code (refactor), or a fundamental mismatch (rewrite or replace)?
What does the business get from a rewrite that it can't get otherwise? If the answer is "modern technology", that isn't a business reason.
Where does the knowledge live? If it's only in the code, a rewrite is riskier.
Are there tests? If not, the first job is to build them, in any scenario.
What does it cost to keep going? Include support, fixes, risk and lost opportunity, not only hosting.
How would we run both systems during a transition?
What's the worst case if it takes twice as long?
Who benefits from the recommendation? A supplier who sells rebuilds will tend to recommend one.

Red flags in a rewrite quote

No assessment first. A quote for rebuilding a system nobody has investigated is a guess.
"It's too old to fix" with no evidence of what was examined.
No plan for the business rules hidden in the old code.
No plan for running the old and new systems side by side.
A fixed price for an unclear scope.
No mention of tests, data migration or rollback.
Pressure to decide quickly, or a claim that the old system could fail tomorrow, without detail.

A good supplier will tell you what they found, show you, and be willing to say "don't rewrite".

How AI changes the equation

Much of the cost of keeping a legacy system was investigation: understanding unfamiliar code, tracing bugs, writing the documentation nobody wrote. AI-assisted analysis cuts that cost dramatically, which makes staged modernisation more affordable than it used to be. It also makes the decision better informed, because the system can be understood in days, not months.

AI doesn't remove the risks of a rewrite. It can't tell you why a strange rule exists, and it still takes people to decide what the business needs. How I use AI

How to get the evidence

A Legacy System Assessment investigates the application and its environment, and gives you a prioritised plan: what to upgrade now, what to refactor, what to leave, and, if the evidence supports it, what to replace. It's yours to use with me, with another supplier, or with your own team. Legacy System Assessment, from £2,500

If you already have a rewrite quote, I'm happy to look at it with you.

Frequently asked questions

Is it cheaper to rewrite than to maintain an old system?

Sometimes, but not as often as it feels. A rewrite has a large upfront cost, a long period of paying for both systems, and a real chance of overrun. Maintenance and staged improvement are often cheaper over the same period. Evidence beats instinct.

Our developers say it's unmaintainable. Is that true?

Sometimes. Often it means "unfamiliar", "undocumented" or "untested", which are all fixable. An independent assessment will tell you which.

We've been quoted a full rewrite. What should we do first?

Get an independent assessment before signing anything. It's a small fraction of the cost of a rewrite, and it will either support the quote or save you from it.

Can we do part of it?

Yes, and that's often the best approach. Replace the parts that hurt most, and leave the stable parts alone.

What does "refactoring" mean, in plain English?

Tidying the inside of the code, without changing what it does, so it's easier and cheaper to change safely. Done in small tested steps, it's low-risk.

What if the business is about to change direction?

Then it matters even more to avoid committing to a big rebuild of something you're about to rethink. Stabilise it, document it, and decide once the direction is clear.

Tell me what you've inherited.

If you've been told you need a rewrite, a conversation could save you a great deal of money, or confirm that you were right.

Book a free conversation Legacy System Assessment, from £2,500