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.
Submit a project See how project delivery worksReviewed by David (CEO) · Updated 23 Sep 2026
What is in scope
The service 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 to move and the seam it will move along.
-
Framework and runtime upgrades
Moving an application off an unsupported language runtime, framework version or library set, with the behaviour of the current system 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, with reconciliation between the old and the new store while both run.
-
Cloud migration and containerization
Moving a workload into containers and a managed cloud environment, with the build, the configuration and the secrets handling rebuilt rather than copied.
-
SaaS re-platforming
Moving a bespoke system onto a product platform where that is the better answer, with the data migration and the 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. The full offer list is on the services page.
Good fit and poor fit
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 honest 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.
The assessment comes first
Every modernization engagement begins with an assessment, and you can stop after it.
The assessment reads the codebase and its dependency graph, maps data ownership and integrations, records what the system does today, and identifies where it 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 plainly 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. Commercial terms belong in the proposal, not on this page; engagement models explains how the choice is made.
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.
Projects are staffed with the roles the scope needs, typically drawn from business analysis, project management, solution architecture, development, QA and UI/UX. One Netbase delivery lead owns the plan and reports against it, in Agile increments with weekly reviews. Project delivery describes the governance in detail.
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.
Workloads are packaged so the same artifact runs in every environment, which removes a common class of migration surprise.
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.
Cutover, rollback and decommission
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 part of the 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
Modernization touches production data and credentials, so the handling is agreed before access is granted. 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 speed up tasks such as reading unfamiliar code, drafting characterization tests, reviewing changes and writing 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. Many buyers move two or three and stop, because 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 using the runbook, or agree a separate assessment-led scope for maintenance and operations. Handover does not depend on buying that.
Related work
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. The anonymized record sits on the work page, and the rules that govern what a record may claim are on the methodology page.
That record shows long-running platform work, not a catalogue of migrations. Ask for any specific modernization claim in the first review; it is answered with evidence or not at all.
Ready 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.