Refactor while the system can still be improved: its structure is sound and the people changing it know it well. Rebuild once every change starts with investigation, or one person holds all the knowledge. The same goes when the system blocks features you need, or costs more to keep than to replace. Past that point, refactoring only delays the rebuild.
Every business with an ageing system reaches this question sooner or later: improve what you have, or start again. Most advice on it is balanced in theory, and of little use when your system takes three days to make a two-hour change.
Usually the harder question is whether you’ve already crossed the line, and are putting off the answer.
The question you’re really asking
Most businesses asking this question already suspect something is wrong. Some want permission to do what they know needs doing. Others want reassurance that they can put it off a little longer.
Both instincts make sense. A rebuild is expensive, disruptive and uncertain. Refactoring feels safer, with steady progress and fewer unknowns.
Getting it wrong costs you either way. Rebuild too early and you throw away working code, what your developers know about it, and budget that could have gone elsewhere. Refactor for too long and you keep paying for a system that won’t fundamentally improve, while your users get frustrated, your developers tire and trust wears away.
The aim is to see where your system sits today, rather than where you’d like it to sit.
What refactoring actually means
Refactoring is the deliberate restructuring of existing code to make it easier to read, faster or easier to maintain, without changing what the system does. Bug fixes and new features are separate work.
Done well, it reduces technical debt a piece at a time. You improve the foundations while the building stays open, with no big switchover and no launch day to dread.
This works when:
- The underlying architecture is sound, even if it’s messy in places
- The codebase is modular enough to improve one part at a time
- Your developers understand the system well enough to change it safely
- The technical debt is awkward rather than structural
In those conditions, refactoring is the sensible choice: less risk, less cost, and the system keeps working while it improves.
But refactoring has a condition that’s often ignored: the system has to be improvable. If the foundations are compromised, renovation won’t make the building safe. It only hides the symptoms.
Refactoring can feel productive when it isn’t. Work goes out and tickets get closed, while the underlying problems stay where they were.
It works well on systems worth keeping. The trouble starts when it becomes a way of avoiding the ones that aren’t.
When refactoring becomes avoidance
I’ve been brought into projects whose core structure was a decade old before I arrived. The decisions that shaped those systems were made long before my involvement, often under very different constraints.
One was a content-heavy WordPress site. It had dozens of templates, includes nested inside includes, global state shared freely, and no clear line between logic and presentation.
Every change required archaeology. To find out why something displayed incorrectly, a developer had to trace through layers of templates written by people who had long since moved on. The admin bore little resemblance to what the site showed, and even simple content updates felt risky.
The site had been “improved” for years. Each phase of work treated symptoms rather than causes. New features were bolted on, temporary workarounds became permanent, and the complexity kept growing.
Well before I was involved, a rebuild would have been the sensible call: a modern templating approach, a clear separation of concerns, and a system designed to support change.
That moment passed. The next sprint was always more urgent, the budget went elsewhere, and the system still worked well enough to delay the decision.
In the end, the client rebuilt the site in-house and my work with them ended. Nobody failed on their own. The problem had been put off for too long.
This is what refactoring looks like once it has become avoidance. The work carries on and progress looks steady, while the real problem grows until the decision is made for you.
The tipping point
When does refactoring become denial?
- Modular architecture
- Team understands the code
- Manageable technical debt
- Changes require archaeology
- Only one person understands it
- Clients losing patience
- New features get rejected
- Maintenance exceeds rebuild cost
The scales have tipped.
Scroll to reveal the signs
Why rebuild decisions get deferred
A rebuild is an emotional decision as well as a technical one.
It means accepting that earlier decisions no longer serve the business. That can feel like failure, even when the business has simply outgrown the constraints those decisions were made under.
Sunk cost plays a part. Years of time and money sit in the existing system, and walking away feels wasteful even when carrying on costs more.
The risk is real, too. A rebuild needs two systems running side by side for a while, a data migration, retraining and a carefully managed switchover. The known problems start to feel safer than the unknown ones.
Optimism fills the gap: one more refactor, one more stabilisation phase, one more attempt to get it under control. The rebuild moves to a later date that never arrives.
None of this is irrational. But it can trap a business in a cycle where it spends more each year keeping a system running that does less for it.
The hybrid path most teams end up taking
Many successful modernisation projects land somewhere between refactoring and rebuilding.
The strangler pattern is common for a reason. Instead of rebuilding everything at once, you replace the system a part at a time. Old and new run side by side until the last of the legacy code is retired.
This works when:
- The system has clear boundaries
- Traffic or logic can be routed between the old version and the new one
- Your developers can support two systems for a while
- Everyone is committed to finishing the migration
The risk is treating it as a compromise you can stop halfway. A partial rebuild that stalls leaves your developers maintaining two systems indefinitely, with the benefits of neither.
Whichever path you take, know where it ends, and commit to getting there.
Five signs you’ve already crossed the line
Some systems are worth saving. Others passed that point years ago.
1. Every change starts with investigation
If a simple update means tracing undocumented behaviour across the codebase, the system has become a liability.
2. Critical knowledge sits with one person
A system that depends on what one person remembers is already fragile.
3. Client patience runs out faster than delivery improves
When expectations and reality keep drifting apart, promises slip and frustration builds. Eventually, the client solves it by finding someone else.
4. The system blocks features you need
If the answer is more and more often “the platform won’t handle that”, the system is holding the business back.
5. Maintenance costs more than a rebuild would
At some point, the monthly cost of keeping a failing system alive passes the cost of replacing it, spread over the years the new one will last. Many businesses reach that point well before they admit it.
Making the call
If you recognise your system in these patterns, start by being honest about it.
Count the cost of carrying on: the money, and also the morale, the client confidence and the opportunities turned down because the system can’t support them.
When you speak to a technical partner, ask questions that show how they think:
- Have you advised clients against a rebuild? What did you recommend instead?
- How do you scope a rebuild to avoid scope creep?
- What would you need to see before recommending we keep refactoring?
- How do you handle the transition period when both systems need to run?
A good partner won’t push for a rebuild by default. They’ll help you understand what you’re dealing with, and what each path costs.
If it’s a WordPress site or a Laravel application, I can look through it and tell you which side of the line I think it’s on. That’s part of my WordPress development and Laravel development work.
Further reading
- What technical debt is really costing your business: how hidden costs build up beneath the symptoms you can see.
- Why most digital projects fail before a line of code is written: the strategic misalignment that derails builds.
- Choosing the right technical partner: what to look for beyond hourly rates and feature promises.
Published , updated .
Part 6 of The Long Game.