Short answer: most legacy system modernization projects should start with incremental refactoring, not a rewrite from scratch. A rewrite makes sense in three cases: the stack is no longer supported, the business has changed so much that the system solves a problem you no longer have, or every change to a module costs more than rebuilding it. If you can’t say which of those three applies to you, you’re not ready to rewrite.
It usually starts the same way. A feature scoped for two weeks is in its second month. Engineering says the codebase is beyond saving and wants to start over. The business can’t afford to freeze for a year to build a system that, on launch day, will do exactly what the current one does.
Both sides have a point. This guide is about making the call with data instead of frustration.
What makes a system “legacy” (hint: it’s not age)
A legacy system is software that still runs the business but that your team can no longer change with confidence. Age has little to do with it. A three-year-old product with no tests, whose one developer who understood it has left, is more legacy than a well-documented Java system from 2012.
You probably have one if:
- Everyone knows which parts of the codebase not to touch.
- A small change in one module breaks something in another that seemed unrelated.
- New engineers take months before they can ship on their own.
- Estimates are always wrong, and always in the same direction.
- Deploys happen late at night, with someone on call, fingers crossed.
Put a number on your technical debt first
Technical debt is everything that was built fast at some point and now charges interest: every new feature pays a little of it back. Before arguing about what to do, measure what it’s costing you.
You don’t need fancy tooling. Look at the last three months and answer four questions:
- How much of each sprint goes to bugs and incidents? If a five-person team spends 40% of its time firefighting, you’re paying two full salaries just to keep the system up.
- How long does a small change take to reach production? If changing a line of copy takes a week, that tells you a lot.
- How many features slipped because of “technical complexity”? And how many of those were promised to a customer?
- How long did your last hire take to become productive?
Those numbers change the conversation. It stops being “the code is ugly” and becomes “we lose X hours a month and the roadmap is Y weeks behind.” That’s something you can weigh against the cost of fixing it.
When to refactor
Refactoring means changing the internal structure of the code without changing what it does. It happens in small steps, on the system that’s already in production, and every step can be rolled back.
It’s the right call when:
- The system works and the business trusts it. The problem is how slow it is to change, not what it does.
- The stack is still supported. Your language, framework and database get security updates, and you can hire people who know them.
- The pain is concentrated. Debt is rarely spread evenly. Two or three modules usually cause most of the trouble.
- You can’t pause the roadmap. If customers are waiting on dated features, refactoring lets you keep shipping while you improve the system.
The habit that works best: refactor the code you’re about to touch for the next feature. Skip the standalone “cleanup quarter” that competes with the roadmap and loses. The improvement ships with something the business actually asked for.
When to rewrite
A rewrite means building a new system to replace the current one. It’s the most expensive and riskiest option, but sometimes it’s the only reasonable one:
- The stack has reached end of life. No security patches, no talent on the market, abandoned dependencies.
- The business changed at its core. The system was built to sell to consumers and you now sell to enterprises, or it was built for one country and you now operate in five. If the data model no longer reflects your business, refactoring means patching a broken foundation.
- Changing a module costs more than rebuilding it. If every attempt to modify it turns into weeks of bug fixing, again and again, the math is already done.
- Nobody understands the system anymore. If everyone who built it is gone and there are no docs or tests, rebuilding it with clear rules can be cheaper than archaeology.
One risk almost never makes it into the estimate: while the rewrite is underway, the old system stays in production and keeps needing changes. For months, your team maintains two products. And the old code holds business rules nobody documented, which only surface when the new system fails with a real customer.
The textbook case is Netscape in the late nineties. It decided to rewrite its browser from scratch, went years without shipping a new version, and lost the market in the meantime. Joel Spolsky called it the single worst strategic mistake a software company can make. Exaggerated or not, the lesson holds: while you rewrite, your competitors keep shipping.
Refactor vs rewrite at a glance
| Refactor | Rewrite from scratch | |
|---|---|---|
| Time to value | Weeks, with each improvement | Only when the new system replaces the old one |
| Roadmap impact | Low: you keep shipping | High: much of the team stops building features |
| Risk | Low, spread across small steps | High, concentrated on cutover day |
| Business knowledge | Preserved, because the code stays | Has to be rediscovered, and something always gets missed |
| Cost | Spread over time | Large and hard to estimate |
| Best when | The system works but is slow to change | The stack is unsupported or the business changed at its core |
The third option: modernize one piece at a time
Between “fix what’s there” and “throw it all away” there’s a middle path, and it’s the one most teams with a product in production end up taking. Martin Fowler named it the strangler fig pattern, after a fig that grows around a host tree until it replaces it. The new system grows around the old one and takes over one module at a time.
In practice:
- Lock in today’s behavior. Before touching anything, write tests that record how the system behaves now, bugs included.
- Pick the first module. The one that hurts most and has the fewest dependencies. Billing, permissions and reporting are common first candidates.
- Put a front door on it. Isolate the module behind an API so the rest of the system doesn’t know whether the old or new code is answering.
- Replace and measure. Build the new version, route part of the traffic to it and compare results against the old one.
- Retire the old code. Once the new version performs as well or better, delete what it replaced. Then move to the next module.
The advantage is that you never bet everything on a single launch. If something goes wrong, the blast radius is one module, not the whole product.
Modernizing doesn’t mean moving to microservices, either. For a small team, a well-structured monolith is often the best architecture available. Pick the architecture for the team you have, not the one in the conference talk.
How to decide without guessing
Before committing budget, sit down with your team and answer:
- Will our current stack get security support for the next three years?
- Are the problems everywhere, or in two or three modules?
- What does technical debt cost us per month, in hours and in delayed features?
- Can we stop shipping new features for six months or more?
- Is there anyone left who understands the business rules buried in the code?
If most answers point to “it works, it’s just slow to change,” refactor or modernize incrementally. If they point to “the foundation no longer fits,” plan a rewrite, and even then, do it module by module.
The most expensive mistake is deciding without a diagnosis. That’s why at HitOcean we don’t start by estimating a full rewrite. Every custom software development engagement starts with a discovery: we review the code, the architecture and your business priorities, and you walk away with the scope, a work plan and an investment range before you commit to development. Often the conclusion is that you don’t need more developers. You need to fix the architecture before you scale.
If the diagnosis shows you’re short on capacity, we can add a dedicated software team from Latin America that works on your product, with hours that overlap with yours, without freezing your roadmap. If you’re weighing that option, our guide on hiring a software development team in LATAM covers how it works. You can also see how we’ve done it for other companies in our case studies.