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 Huy Nguyen (David), CEO · Updated 2 Nov 2026 · 10 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, and the legacy PHP to Laravel migration guide applies them to one destination framework specifically.
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. The cloud ERP record sets out its scope. 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. 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.
Where does AI fit in a replace-or-refactor decision?
The clearest use sits in the second of the seven questions this guide asks first: whether the domain rules are knowable at all. Reading the existing code and its tests to draft a first-pass description of what a module actually does today — the rules it enforces, the states it tracks — gives a team a starting document to check against real behaviour, rather than a blank page under deadline. The same reading can flag candidate rules worth testing directly, for someone to confirm against live data before the route is chosen. None of that drafting decides whether the rules are complete, or which of the four routes fits; the people who still understand the system make that call, against the table above.
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.
Talk to Huy Nguyen (David), Founder and CEO of Netbase JSC: message him on WhatsApp at +84 937 869 689 or email project@netbasejsc.com. You can also send your brief through the project request form. Say which workflow or system the project concerns and what has to stay unchanged; the first step is a discovery conversation, and scope and milestones are agreed 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.
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