Replace, refactor, wrap or leave alone: deciding what to do with legacy software
There are four routes, not two: rebuild, refactor in place, front it with an interface and move capabilities out one by one, or leave the code alone and fix the conditions around it. What decides is how often it changes, whether its rules are documented, whether the data model survives, and what the business can absorb during the work.
Submit a project See the modernization serviceReviewed by David Nguyen (CEO) · Updated 14 Oct 2026 · 9 min read
OutsourcingVN is operated by Netbase JSC, and we are paid to build software, so read this with that interest in mind. This page is the decision chapter of the legacy system modernization guide; the commercial route for any of the four answers, including the one that involves almost no building, is legacy application modernization.
What are the four routes, defined properly?
Replace. A new system is built or bought, the old one is retired, and the data moves. The attraction is a clean model; the exposure is that every undocumented rule in the old system has to be rediscovered before it disappears.
Refactor in place. The existing codebase is restructured, the runtime and libraries are upgraded, tests are added, and the system keeps its identity. Users see little. The roadmap unblocks because change becomes predictable again.
Wrap and migrate behind a seam. A documented interface is placed in front of the old system so callers stop reaching into it directly. Capabilities then move out one at a time behind that interface, while the old system keeps serving everything not yet moved. The mechanics are on incremental modernization without a rewrite.
Leave it alone. The code is not touched structurally. Monitoring, backups, access control, dependency patching and the release path are improved, the knowledge is written down, and the money goes somewhere it changes an outcome.
What actually decides
Seven questions settle this in most organisations, and none of them is about the language the system is written in.
- How often does it really change? Count merged changes over the last year, not the feeling. A system nobody has changed in eighteen months is not blocking a roadmap, whatever its reputation.
- Are the domain rules knowable, and written down anywhere? If the rules exist only as code and habit, replacement means rediscovering them under deadline. Refactoring and wrapping let you extract them while the system still runs and can be asked.
- Can the data model survive? If the current model is coherent and only the code around it is bad, refactor or wrap. If the model itself is the problem — entities that mean two things, fields reused for a second purpose — the migration is the project, and legacy data migration planning is where to start.
- How large is the integration surface? Every system that reads the database directly is a caller you did not know you had. A wide surface makes replacement slow and makes a seam valuable.
- What are the compliance and audit obligations? Where an auditor can ask you to reproduce a decision from three years ago, retention, traceability and the ability to run the old logic constrain the route more than any engineering preference.
- Who still understands it? If one person holds the knowledge, the first work is extracting it, whichever route follows. If nobody holds it, replacement without characterization is a guess.
- What happens to the business during the work? A route the operation cannot absorb is not a route. This is what usually rules out a single cutover on a fixed date.
The four routes compared
Scores are relative and assume the criteria above have actually been checked.
| Route | Risk | Evidence available | Business disruption | Cost of being wrong | What it needs from you |
|---|---|---|---|---|---|
| Leave alone | Low now, rising slowly | High: the system already behaves as it does | None | Low, and recoverable next year | An honest count of how often it changes, and an owner for the annual review |
| Refactor in place | Moderate, and spread over time | High: tests can be added before behaviour is changed | Low, mostly release windows | Moderate: effort spent, roadmap unblocked less than hoped | Code access, and patience with work that shows no new features |
| Wrap and migrate behind a seam | Moderate, and visible per slice | High: old and new run together and can be compared | Low per slice, spread over months | Low per slice: one slice can be reversed | Willingness to run two paths, and a named owner for the record |
| Replace | High, and concentrated at one date | Low until the new system is live | High around the cutover | High: the old system is gone and the rule was not carried across | A written definition of current behaviour, and a date the business can survive |
Read the "cost of being wrong" column before the risk column. Most of the difference between these routes is not how likely they are to go wrong, but how much of the business is standing underneath when they do.
(opens the full-size diagram in a new tab)
Why "leave it alone" is under-proposed
A supplier paid to build has no commercial reason to recommend not building, and buyers rarely ask for it explicitly. It is nonetheless the right answer often enough to be the first option on the list.
It is right when the system is stable, when changes are rare, when the real complaints are about reporting or manual process rather than the code, and when the risk is operational — no restore test, an unpatched dependency, admin access that outlived a leaver — rather than architectural. Those are fixable in weeks without touching the domain logic, and fixing them frequently removes the urgency that made a rebuild look necessary.
The condition is that the decision is written down with a date on it. "Leave it alone" is a decision with an owner and a review; "nobody got round to it" is the same code with none of the protection. If you want that judgement made as bounded paid work rather than settled by whoever argues hardest, a technical audit sprint produces the evidence and stops there.
How do you run the decision?
-
Establish the constraint before the route
Confirm the system is what blocks the roadmap. Assessing legacy system risk is the prior question, and answering it out of order is the most common way to spend a year rebuilding the wrong thing.
-
Count the changes and name the owners
A year of change history, the systems that integrate, and the people who can still reason about the code.
-
Test whether the rules can be extracted
Take one non-trivial rule and try to state it precisely from the code and the people. How hard that is predicts everything that follows.
-
Profile the data
A week of profiling tells you whether the model survives, and that answer alone eliminates at least one route.
-
Score the four routes openly
Use the table above with your own weights. Record the reasoning, because the decision will be challenged when the work gets dull.
-
Fix the scope for the chosen route
Most Netbase projects are agreed as fixed-scope contracts agreed after discovery, and milestone-based arrangements are also available; engagement models explains how that choice is made.
Netbase's delivery lifecycle runs discovery and strategic alignment, team assembly and architecture planning, agile execution with outcome-based milestones, modular components, training and rollout, then ongoing support. Project teams draw on business analysis, project management, solution architecture, development, QA and UI/UX roles, delivered remote-first from Hanoi in Agile increments with weekly reviews, using AI-assisted engineering under human review. Netbase stays accountable whether the work is done by Netbase staff, approved specialists or disclosed partners.
What we can show, and what we cannot
The operating workflow behind most of these decisions is the back office, and ERP and back-office operations sets out which parts of it a bounded project should take on.
A related published record is long-running platform delivery. Since 2020 Netbase has worked as offshore development and managing partner on a multi-tenant cloud ERP SaaS platform for a client that is not named; its first phase, from 2020 to 2023, covered CRM, real-time messaging, HR, a knowledge base, custom fields and workflows, work and project management and API integrations. A later retail phase was planned work when that profile was written and is not presented as delivered. That record carries no measured modernization outcome, and the replace-or-refactor judgement for your system is made on its own evidence. For custom development the client owns the IP created for it, while Netbase productized modules and products are licensed rather than transferred.
Plan the next step for your project
Common questions
Yes, when the domain itself has changed, when the rules are knowable and documented, and when the business can survive the cutover date. What makes rewrites fail is rarely ambition; it is starting one without a written definition of current behaviour.
Give it an exit condition and measure it. "A routine change reaches production in under a week" is a finish line; "the code is cleaner" is not.
Often yes, if it exposes a database, a file drop or a user interface that can be driven. The seam moves outward rather than into the code, and the trade-off is that you own more integration.
That any date offered before the code has been read is a guess. The assessment is the bounded piece of work that turns the question into a plan, and you can stop after it.
How this page is sourced
Every statement about Netbase here maps to a registered claim backed by attested company facts, listed under Sources below, and company claims are published only in the wording the register approves. The criteria and the scoring reflect how our own teams reach this decision before quoting; nothing here is drawn from a benchmark, a survey or a third-party study, and the table is a judgement aid rather than a measurement. For how we source and review claims, see our methodology.
Decide the route before you write the brief
Write down how often the system changes, who still understands it, and what the business can absorb, then submit a project brief with that and the access you can grant. If the honest answer turns out to be "leave it alone", say so in the brief and ask for the assessment only. OutsourcingVN is operated by Netbase JSC and is Netbase's own outsourcing-services platform.
Work behind this guide
This record covers phase-one scope for agency SMEs; the client and product are not named, and no usage or business result is claimed.
Keep ReadingRelated services and solutions
Legacy application modernization, one bounded capability at a time
The code is assessed first, then one bounded capability moves at a time, with a way back.
Learn More