Planning a legacy data migration

OutsourcingVN is operated by Netbase JSC, which scopes and runs accountable project teams. This is the data chapter of the legacy system modernization guide, and the commercial route is legacy application modernization. One blunt thing first: data migration is where modernization projects usually overrun, and the overrun is almost always found in reconciliation rather than in the move itself.

The schema is not the data

The schema tells you what the old system was allowed to store, not what it stored. Between the two sits fifteen years of people getting work done with the fields they had: nullable columns where emptiness carries meaning, and several meanings at that — not applicable, not known yet, lost in an old import. The same customer under three spellings, two with a trailing space. A note field that became the home of a second process nobody would fund. Records nobody has touched since 2014 that are load-bearing for a year-end report.

None of that appears in a data dictionary. It appears in queries against real data, and it must appear before the target design is fixed, because each finding either changes the design or becomes a defect found in reconciliation at the worst moment. If nobody has examined the wider system yet, run the legacy system risk assessment first.

What to profile, and why each item changes the design

Profiling is queries, not interviews. Run them on a recent copy and record the numbers with their date.

Profiling copies production data, so handling is agreed before the copy exists. Netbase security practices include secure code review and version control, role-based access control, MFA for admin dashboards, contributors under NDA, and NDAs and DPAs on request, and where data may not leave your environment the work runs inside it.

See data security and compliance

What moves, what is archived, what is left behind

Three destinations, one decision per entity, one name against it.

Moves. Records the new system must operate on. They carry the full mapping, reconciliation and test burden, so keeping this set honest is the largest single lever on cost and duration.

Archived. Records you must read but not operate on. A read-only copy of the old database, an open-format export or a reporting store all qualify, and all cost far less because none needs mapping into a new model.

Left behind. Records that stop existing in any live sense. A real option, used far less than it should be, because nobody will sign for it.

Somebody must sign — not the supplier or the project manager, but the business owner of that data, who will be asked in eighteen months why a record cannot be found. If how much of the system to replace is still open, settle that in replace or refactor legacy software before drawing the cut list.

The mapping document is the real deliverable

For every field that moves, the mapping says where it comes from, what happens on the way, what the target field is, what happens when the source value is absent or invalid, and who decided. The migration is built from it, tested against it and argued over it, and it outlives the project.

It is written with the business, not by the supplier alone. A supplier can read a customer-type column and describe it accurately; only the people who use it can tell you that one of its values has meant "do not chase for collections" since a decision in 2017 that never reached the reference table. Every rule encoding a judgement gets a named business owner, and rows where the business disagrees with itself are findings, not something to settle quietly.

Keep exceptions beside the rules, and version the document: a mapping that changed unnoticed turns a rehearsal that passed into a cutover that fails. For back-office data the target model matters as much as the mapping, which ERP and back-office operations covers.

Reconciliation is the acceptance test

A migration is accepted on evidence produced by people who know the domain, not because the load script exited zero. A green log says rows were written, not that they are right.

Row counts, per entity, source against target, with every difference explained by a line in the cut list rather than by a shrug. An unexplained difference of one is the same class of problem as ten thousand.

Control totals, on values the business cares about: balances, quantities, open items, totals by period or category. Counts catch missing rows; totals catch rows carrying the wrong number, which is where encoding, rounding and unit errors surface.

Spot checks by domain people, on records they choose. They go straight to the account merged in 2019 and the contract with the odd renewal; a sample the supplier chose proves considerably less. Agree before the build which reconciliations must balance exactly, which may differ with a written explanation, and who signs each.

The freeze, and what rollback really means

A freeze is the period when the old system stops accepting changes and the new one has not opened. Its length follows from the rehearsals, not from what the business would prefer. Decide in advance what happens to work arriving during it — queued on paper, or replayed later from a holding area — because somebody needs that answer at hour two.

Then be precise about rollback. Before the new system accepts its first real transaction, rollback is genuine: the source is still authoritative, you unfreeze it and go home. Once real records exist on the far side there is no rollback, only a second migration in the other direction that nobody designed, mapped or rehearsed. Plan a defined point of no return, criteria evaluated before it, and forward fixes after it. Incremental modernization without a rewrite describes running old and new side by side, which moves that point but does not remove it.

History, retention and the records you may not drop

Financial and employment records, contracts, consent records and audit trails carry retention obligations from law and from your own agreements, and those apply to the archive exactly as to the live system. Retention therefore belongs in the plan: what is kept, in what form, for how long, who may read it, and what shows it is intact. Where history is kept by leaving the old database read-only, name who hosts and patches it for that period. Handover and exit covers the transfer.

AI in a migration, and what it may not decide

Netbase delivers remote-first from Hanoi in Agile increments with weekly reviews, using AI-assisted engineering under human review. On a migration that help is narrow: reading unfamiliar schemas, drafting profiling queries, summarising a stored procedure nobody has opened in a decade. It does not decide a mapping rule, adjudicate a duplicate or produce reconciliation evidence, because those are judgements about your business and carry a named human owner.

What record sits behind this page

This page publishes no durations, defect rates or volumes of ours; those depend entirely on the system in front of us. The nearest delivery record is long-running platform work, not a catalogue of migrations.

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 anonymised record is the cloud ERP platform page.

Netbase project teams draw on business analysis, project management, solution architecture, development, QA and UI/UX roles. Delivery is remote-first, with Netbase accountable whether the work is done by Netbase staff, approved specialists or disclosed partners, and for custom development the intellectual property created for you belongs to you, mapping and jobs included.

Bring the data, not just the system

The useful first conversation is about the data: how many entities, who owns each, and what must be retained. For how we source the claims on this page, see our methodology. When you are ready, submit a project. OutsourcingVN is operated by Netbase JSC and is Netbase's own outsourcing-services platform.

Related services and solutions