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. It starts by assessing the code, data and dependencies, then migrates one bounded capability with evidence that the new path behaves like the old one, and a way back. No date is promised before the code is read.
Submit a project See how project delivery worksReviewed by David Nguyen (CEO) · Updated 6 Oct 2026
What can be modernized?
OutsourcingVN is operated by Netbase JSC, and this page describes Netbase's own service. It covers modernization work that can be bounded, checked and reversed:
-
Monolith assessment and decomposition
Mapping modules, data ownership and coupling, then choosing the first capability and its seam.
-
Framework and runtime upgrades
Moving off an unsupported runtime, framework or library set, with current behaviour recorded in tests first.
-
API enablement
Putting a documented interface in front of a capability that today is reachable only through the user interface or a direct database connection.
-
Database modernization
Schema changes, engine moves and change-data migration, reconciling old and new stores while both run.
-
Cloud migration and containerization
Moving a workload into containers and managed cloud, with build, configuration and secrets handling rebuilt rather than copied.
-
SaaS re-platforming
Moving a bespoke system onto a product platform where that is the better answer, with data migration and gaps written down first.
-
Technical-debt reduction
Targeted work on the parts of the codebase that block the roadmap, chosen from evidence rather than from opinion.
When the outcome is a new product rather than a migrated one, plan it as custom product engineering. When the point of the work is to automate a process, see AI workflow automation. All offers are on the services page.
Is your system ready for a staged migration?
Modernization is safe to scope when the current system can be inspected, its behaviour can be checked, and someone can say what "the same, but better" means.
Good fit
- Read access to the source code, the database and the deployment pipeline can be granted early
- A named owner can say which behaviour must be preserved exactly and which may change
- The system can be changed in stages, with the old and the new path running side by side
- The business can accept a short planned cutover window and a rehearsed rollback
Another route fits better
- A fixed scope is expected before anyone has read the code or the data
- Nobody can describe the current behaviour, and there is no test or record to check it against
- The only acceptable plan is a single cutover of everything on a date already announced
- Success depends mainly on results outside delivery control, such as adoption or a vendor roadmap
If the code cannot be inspected yet, the first step is the assessment on its own; its output is a decision, not a commitment to build. If the system is already failing in production, start with a bounded technical audit sprint and decide from its findings.
Compare repair in place, a product replacement, an internal migration and other suppliers by asking each to name the behaviour to preserve, the first capability and seam, parity checks, cutover evidence, rollback and decommission plan.
The assessment comes first
Every modernization engagement begins with an assessment, and you can stop after it. The legacy modernization buyer guide connects the decision sequence: assess the system, decide whether to replace, refactor, wrap or leave it alone, plan incremental modernization and data migration, then use the legacy risk assessment to define the first safe scope. A technical debt assessment ranks what to fix first; online stores add the e-commerce modernization checklist.
The assessment reads the codebase and dependency graph, maps data ownership and integrations, records current behaviour and finds where the system can safely be cut. It produces a sequence: which capability moves first, what must exist before it can move, what parity means for that capability, and what the rollback looks like. It also says where information is still missing instead of filling the gap with an estimate.
Only then is a migration scope fixed. Most Netbase projects are agreed as fixed-scope contracts after discovery, and milestone-based arrangements are also available; engagement models explains the choice.
Deliverables
The exact list is agreed in the proposal. A staged migration typically delivers:
- an assessment report: current architecture, dependencies, data ownership, risks and a recommended migration sequence;
- a characterization test suite that records how the current system behaves, so the new path can be compared against it;
- the migrated capability itself, running in your repositories and environments;
- parity evidence: the comparison between old and new behaviour for the cases agreed in advance;
- a cutover plan and a rehearsed rollback plan, each with the conditions that trigger it;
- a performance baseline measured before and after the move;
- observability for the migrated capability: logs, metrics and the alerts that show the new path failing;
- a decommission plan for the part of the old system the migration replaces;
- a handover pack: documentation, access transfer, open issues and known limitations.
For custom development, the intellectual property created for you belongs to you. Netbase's own productized modules, where a migration uses them, are licensed rather than transferred, and the proposal says so before you accept it.
How the work is done
-
Assess
Read the code, the data and the deployment path. Map dependencies and integrations. Produce the migration sequence and the risk list.
-
Characterize
Capture current behaviour in tests and recorded cases, so parity becomes something that can be checked rather than argued about.
-
Migrate one capability
Build the new path behind a seam, run it beside the old one, and compare results on real or replayed cases.
-
Cut over and verify
Switch traffic in a planned window, watch the agreed signals, and keep the rollback available until the exit criteria are met.
-
Decommission and hand over
Retire the replaced part, record the performance baseline, transfer documentation and access, then agree the next capability or stop.
Project teams draw on business analysis, project management, solution architecture, development, QA and UI/UX roles. One Netbase delivery lead owns the plan, with weekly reviews; project delivery describes the governance.
Migration patterns we use
The new capability is built beside the old system and traffic moves across a route at a time, so the old system shrinks instead of being switched off in one step.
Behaviour is recorded before it is changed. Undocumented behaviour that users depend on is found here rather than in production.
Where both stores must run for a while, changes are replicated and reconciled, and a mismatch is made visible rather than lost.
Sessions, roles and permissions are mapped explicitly; role-based access control and multi-factor authentication for admin dashboards are standard practice.
The signals that decide whether a cutover succeeded are agreed before the cutover, and the rollback is rehearsed rather than described.
How are cutover, rollback and decommission decided?
A cutover is a decision with criteria, not an event on a calendar. Before it, the plan states the window, who is on the call, the signals that mean success, the signals that trigger a rollback, and how long the rollback stays available. After it, the old path stays in place until the exit criteria hold, and only then does the decommission step remove it.
The decommission plan is a deliverable because a legacy path nobody removed is a cost you keep paying. It lists what is switched off, what data is retained and for how long, and who records that it can go.
Security, ownership and AI-assisted delivery
Handling of production data and credentials is agreed before access is granted. Netbase JSC holds ISO 27001 certification for information security management, and Netbase JSC holds a SOC 2 Type II attestation; both cover Netbase's own practice, not your system or hosting. Secure code review and version control, role-based access control, multi-factor authentication for admin dashboards and contributors under NDA are standard practice, and NDAs and data processing agreements are available on request.
Netbase engineers use AI tools to read unfamiliar code, draft characterization tests, review changes and write documentation. Every change that ships is reviewed and owned by a named engineer, and AI output is never treated as parity evidence on its own. If your project restricts AI tool use, that restriction is written into the project definition and followed. Delivery is remote-first from Hanoi; Netbase stays accountable for the work whether it is done by Netbase staff, approved specialists or disclosed partners.
Frequently asked questions
No. The assessment is the first milestone and the migration scope follows from it. A figure produced before anyone has read the code is a guess, not a commitment.
No. The unit of work is one bounded capability, and you can stop as soon as the roadmap is no longer blocked.
That is what parity evidence is for. Differences show up in comparison runs before cutover; the intended ones are recorded as decisions, and the rest are fixed or they block the cutover.
You do, for the custom development created for you. Any licensed Netbase component is identified in the proposal before you accept it.
Yes. Your engineers and system owners take named responsibilities inside each milestone; that is usually the fastest way to move knowledge about the old system.
You can run it yourselves from the runbook, or agree a separate assessment-led operations scope; handover does not depend on it.
What has Netbase already modernized?
For Netztech, Netbase delivered a Magento 1 to Magento 2 Commerce migration in 35 working days, including migrating 11 extensions with installation, configuration, customization and data transfer. The Netztech migration record publishes scope and duration only.
Working with a local Odoo implementation partner, Netbase has consulted on and customized Odoo in Vietnam for retail chains, manufacturers and distributors; the Odoo implementations record names no client. Netbase's ERP experience also includes a Vtiger CRM to ERP upgrade and Redmine to ERP development.
When the legacy system is an ERP, the ERP procurement and inventory guide, the manufacturing and field service page and ERP and back-office operations describe the target workflow; e-commerce and ERP integration covers the sync layer when a storefront sits in front of it, and Odoo versus a custom build frames the platform-or-build decision. Every record is on the Work page, and the methodology page explains the evidence rules.
What this record reports instead is a duration and a scope, both attested.
Keep Reading
No figure, no result and no partner name appears on this page.
Keep ReadingReady to scope a migration?
Submit a project brief with the system, the capability that blocks you and the access you can grant. If the open question is whether AI belongs in the target design, start with an AI workflow blueprint instead. OutsourcingVN is operated by Netbase JSC and is Netbase's own outsourcing-services platform.