"Never rewrite" is good advice most of the time. Rewrites run late, lose features and stall the roadmap — Joel Spolsky's essay on the one thing you should never do is still required reading. But there is a point where a legacy platform costs more to keep than to replace, and founders usually recognise it a year too late.
These are the five signals we look for in a technical audit, followed by how to decide between refactoring and rebuilding, and a migration plan that keeps revenue flowing while the new system takes over.
1. Feature velocity is falling every quarter
Plot how long a typical feature takes to ship, quarter over quarter. If the line only goes up — and headcount has not gone down — the codebase is fighting you. Engineers are spending their time on the parts that already exist, not the parts you need.
The DORA metrics — deployment frequency, lead time for changes, change failure rate and time to restore service — are a good, research-backed way to make this visible. If lead time keeps growing and deploys keep shrinking, the platform is the bottleneck.
2. Only one person can deploy
If a release depends on a specific human being awake, you do not have a platform; you have a hostage situation. Deployment should be a button, documented, tested and boring. When the knowledge of how the system runs lives in one head, every holiday is a risk and every resignation is an emergency.
3. Dependencies are years out of date
An unsupported framework version is a security incident waiting for a date. Outdated, unpatched components are a recurring theme in the OWASP Top 10 of web application risks. When upgrading is "too risky", the honest translation is that nobody understands the code well enough to change it safely. That is the rebuild signal, not a reason to wait.
There is a hiring cost too. Good engineers are reluctant to join a team maintaining a stack that stopped receiving updates years ago, and the ones who stay spend their time on archaeology rather than product.
Watch for the quieter version of this signal as well: security patches that are applied by hand, a build that only works on one old laptop, or a hosting provider that has announced end of support for your runtime. Each is survivable on its own. Together, they mean the platform is running on borrowed time.
4. The data model no longer matches the business
You sell subscriptions, but the database only knows one-off orders. You have teams, but every user is an island. You expanded to a second country, but currency and tax are hard-coded. When every new feature needs a workaround in the schema, the schema is the product's ceiling.
Data model problems are the hardest to patch because every layer above depends on them. They are also the strongest argument for a rebuild: a new model designed around how the business works today unblocks years of roadmap.
5. Maintaining the legacy platform costs more than a rebuild would
Add up engineering hours spent on bugs and firefighting, infrastructure spend on an architecture you would never choose today, and revenue lost to features you cannot ship. Compare that to a scoped rebuild with AI-assisted delivery — often weeks for a first slice now, not years. The maths is frequently not close.
| Cost of keeping it | Cost of rebuilding it |
|---|---|
| Engineering time lost to bugs, incidents and workarounds | A scoped build for the highest-pain module first |
| Infrastructure sized for an outdated architecture | Running two systems in parallel during migration |
| Features you cannot ship, and the revenue behind them | Data migration, testing and cutover planning |
| Security exposure from unsupported dependencies | A short period of reduced new-feature output |
| Hiring and retention drag | Documentation and handover to the in-house team |
Refactor or rebuild your legacy platform?
Not every old system needs replacing. Refactoring — improving the existing code in place — is the right call when the architecture and data model still fit the business and the problems are local. A rebuild is justified when the problems are structural.
| Situation | Better option |
|---|---|
| Slow in a few places, architecture still fits | Refactor the hot spots |
| Dependencies outdated but upgradeable with tests | Refactor and upgrade incrementally |
| Data model contradicts how the business works | Rebuild, starting with the data layer |
| No tests, no docs, nobody understands the core | Rebuild in slices behind the live product |
| Platform cannot scale to the next stage of growth | Rebuild the constrained module first |
How to rebuild a legacy platform safely
The safest pattern is Martin Fowler's strangler fig: build the new system around the edges of the old one and move functionality across piece by piece until the old system can be switched off. His longer write-up on patterns of legacy displacement is worth reading before you start.
- Audit first. Map modules, data flows, integrations and who depends on what. Decide what to keep, rebuild or retire.
- Rebuild in slices behind the existing product — never a big-bang cutover.
- Ship the highest-pain module first so the team and the business feel the win early.
- Run old and new side by side, routing a small share of real traffic to the new path and comparing results.
- Migrate data incrementally, with reconciliation checks, rather than in one weekend.
- Freeze nothing. The old system keeps running until the new one has proven itself on real traffic.
- Switch off deliberately. Retire each old module only when nothing depends on it.
Relaunching also puts your search traffic at risk. Map every old URL to its new home with permanent redirects before cutover — it is one of the SEO basics most often forgotten in a rebuild.
The expensive rewrite is the one you start eighteen months after you should have.
What to keep from the old system
A rebuild is not a licence to throw everything away. The old legacy platform encodes years of business rules, edge cases and customer expectations, many of them undocumented. Before replacing a module, capture its behaviour as automated tests against the existing system; those tests become the specification the new module must pass. Keep stable integrations, proven data and anything customers rely on, and change them only when there is a clear reason.
Where to start
Start with an honest technical audit: velocity trends, dependency health, deploy process, data model fit and the true cost of keeping things as they are. That audit tells you whether you need a refactor, a partial rebuild or a full replacement — and in which order.
That audit is where most of our technology consulting engagements begin, and rebuilds are delivered by our web, app and software development team with cloud and DevOps set up so that deploying becomes boring again. If your legacy platform is slowing you down, tell us about it — you will hear back from a senior engineer within one business day.
Frequently asked questions
What is a legacy platform?
A software system that still runs the business but is built on outdated technology, architecture or assumptions, making it slow, risky or expensive to change. Age alone does not make a platform legacy — difficulty of change does.
Is it better to rewrite or refactor legacy code?
Refactor when the architecture and data model still fit the business and problems are local. Rebuild when the problems are structural — the data model, the deploy process or the architecture itself — and do it in slices rather than all at once.
How long does it take to rebuild a legacy platform?
It depends on scope. With AI-assisted delivery and a slice-by-slice approach, the first module can usually go live in weeks; a full replacement of a large system runs over months while the old platform keeps serving customers.
What is the strangler fig pattern?
A migration approach where a new system is built around the old one and gradually takes over its functions, one piece at a time, until the old system can be retired. It avoids a risky big-bang cutover.
How do you migrate data from a legacy system safely?
Incrementally. Map the old and new data models, migrate in batches with automated reconciliation checks, run both systems in parallel for a period, and keep a rollback path until the new system has proven itself on real traffic.
