Moving off a legacy system one piece at a time, while it keeps running
Incremental modernization means putting a routing layer in front of the old system, moving one capability at a time behind it, and proving each move with a comparison rather than an opinion. On paper it costs more total effort than a rewrite. It is usually chosen anyway, because it never asks the business to bet on a single date.
Submit a project See the modernization serviceReviewed by David (CEO) · Updated 24 Sep 2026 · 9 min read
OutsourcingVN is operated by Netbase JSC, and we sell legacy application modernization projects, so read this with that interest in mind. This page is the execution chapter of the legacy system modernization guide. Whether a slice-by-slice migration is the right route at all is the prior question, answered on replace or refactor legacy software.
The mechanic, in plain English
Callers — a web front end, a mobile app, a partner integration, a batch job — stop talking to the old system directly and start talking to a thin layer in front of it. At first that layer forwards everything, unchanged, and nothing about the system behaves differently. Then one capability is built anew, and the layer is told to route that capability's traffic to the new implementation while everything else still goes to the old one. Repeat, and the old system shrinks until nothing calls it and it can be switched off.
That layer is the seam. In the literature the approach is called the strangler fig pattern, after a plant that grows around a host tree until it can stand without it, but the horticulture matters less than the mechanic: one routing decision, made per capability, that can be changed back in minutes.
The reason this is worth the extra effort is not elegance. It is that every route change is reversible, so the worst outcome of any single step is a bad afternoon rather than a bad quarter.
Choosing the first capability
The first slice is a choice about risk, not about value. Pick the one that teaches the team the most for the least exposure. Four properties matter, and a candidate that fails two of them is a bad first slice however attractive it looks.
| Property | What good looks like | Why it matters | How to check it in a week |
|---|---|---|---|
| Low coupling | Few callers, few tables shared with the rest of the system | Coupling is what turns one slice into five | Count the callers and the tables the capability writes |
| Clear boundary | You can state in one sentence what goes in and what comes out | A boundary you cannot describe cannot be routed | Write the sentence; if it needs three clauses, keep looking |
| Measurable | A correct result can be recognised automatically, on real cases | Parity is the whole point, and it needs a comparison you can run | Find or build a set of real cases with private details removed |
| Reversible | Sending the traffic back to the old path restores the previous behaviour | This is what makes the step safe to take at all | Confirm the old path still has the data it would need |
Notice what is not on the list: business importance. The first slice should be real enough to matter and small enough that reversing it is boring. Importance is a reason to move a capability second.
Running old and new side by side
Once the new implementation exists, run both. Send the same input to each, keep the old system's answer as the one that counts, and record the difference. This is often called shadow running, and it is the only cheap way to find out what the old system actually does.
Three rules keep it honest.
- Compare on real traffic or replayed real cases. Synthetic examples confirm what the team already believed.
- Classify every difference. Each one is either an intended change, recorded as a decision, or a defect. A difference rate with no classification behind it is a number, not evidence.
- Agree the parity threshold before the comparison starts. Afterwards, the threshold negotiates itself downwards.
Parity evidence is what turns a cutover from a judgement call into a decision with criteria. It is also the deliverable a buyer should ask to see, and it is worth saying plainly: a demonstration is not parity evidence.
The data question that always appears
While both systems are live, one of them owns the record for each capability, and the answer has to be written down per slice rather than assumed. There are three workable shapes.
- Old system owns, new system reads. Safest, and the usual starting point. The new path must tolerate data it did not write.
- New system owns, old system receives a copy. Used once a slice has proven parity. The replication direction reverses, which is a real piece of work, not a configuration flag.
- Both write, reconciled continuously. Occasionally unavoidable across a reporting period. It is the most expensive option and needs a reconciliation report that a person reads, because silent divergence is the failure mode.
Retention, archiving and what happens to history are decided at the same time; legacy data migration planning covers that work in detail. Access to production data is agreed before the seam is built: secure code review and version control, role-based access control, MFA for admin dashboards and contributors under NDA are standard practice, and NDAs and DPAs are available on request.
Cutover, per slice
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. For a slice-by-slice migration, each slice is one pass through the following.
-
Agree the slice and its parity definition
What moves, what stays, and what counts as the same answer.
-
Build the seam, forwarding everything
Deploy it with no behaviour change and let it run. If this step causes an incident, you have learned something important early and cheaply.
-
Build the new path and shadow it
Compare on real cases until the differences are classified and the threshold holds.
-
Route a small share of traffic, then more
Watch the agreed signals. Routing back is the expected response to a surprise, not an escalation.
-
Rehearse the rollback before you need it
A rollback that has been executed once, on a date someone can name, is a plan; one that has only been written down is a hope.
-
Complete the slice and decommission its old path
A legacy path nobody removed is a cost you keep paying, and it quietly makes the next slice harder.
-
Decide the next slice, or stop
Stopping after two or three slices is a normal and legitimate outcome.
Most Netbase projects are agreed as fixed-scope contracts agreed after discovery, and milestone-based arrangements are also available; engagement models explains how the choice is made, and project delivery sets out milestones, change control and acceptance. 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.
Sequencing so each slice pays for itself
Order the slices by risk removed per unit of effort, not by enthusiasm. The first should teach the team the mechanics. The second should remove a named risk — an unsupported dependency, a capability only one person can change, a batch job that fails quietly. By the third, the team is estimating from experience rather than from hope.
Say plainly what this costs. Running two paths means two deployments, a comparison harness, reconciliation and a period where the architecture is uglier than either endpoint. Summed across a programme, that is more effort than a clean rebuild would have taken if the rebuild went well. What you buy with the difference is that no single step can take the operation down, and that you can stop at any slice with the value already delivered.
What we can show, and what we cannot
The workflow behind most of these migrations is the back office, and ERP and back-office operations maps it before any of this is scoped. Whether the system is the real constraint is settled first, on assessing legacy system risk.
Our delivery evidence is one record. 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, on a stack that includes React and Next.js, Laravel and Strapi, PostgreSQL, MySQL, MariaDB and MongoDB on AWS. A later retail phase was planned work when that profile was written and is not presented as delivered. That record is long-running platform work; we publish no measured migration outcome for another client, so nothing here is a benchmark.
Plan the next step for your project
Common questions
In total effort, usually yes. In time to the first useful change in production, usually no, because a slice ships while a rewrite is still being specified.
The seam can sit outside it — in front of the user interface, at a file drop, or in the integration layer. You own more plumbing, and the approach still works.
As many as the roadmap needs. Many buyers move two or three, find the blockage gone, and leave the rest alone deliberately.
A decommission step inside each slice, and a named owner for the remaining old system with a review date. Without both, the half-finished state is stable and nobody is accountable for 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 method described is how our own teams stage this work; nothing here is drawn from a benchmark, a survey or a third-party study, and no timing or effort figure is offered because we have not measured your system. For how we source and review claims, see our methodology.
Plan the first slice
Name the capability you would move first, the callers it has, and whether you can produce real cases to compare against, then submit a project brief with that and the access you can grant. 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
Legacy Application Modernization is for a team whose roadmap is blocked by a system that still runs the business. The project starts with an assessment of the code, the data and the dependencies, then migrates one bounded capability at a time, with evidence that the new path behaves like the old one and a way back if it does not. It is not a big-bang rewrite, and no date is promised before the code has been read.
Learn More