In short
Migrating a legacy system without losing data takes three things in order: a field-by-field mapping document with the conversion rules written down, rehearsal loads repeated until they stop producing surprises, and reconciliation that proves record by record that nothing vanished. The cutover is the short part; what decides the outcome is everything before it.
Projects do not fail at the cutover
Every migration has one document nobody wants to write and which decides whether the project succeeds. It has no glamorous name: it is the field mapping — a table saying, field by field, where each piece of information comes from in the old system and where it lands in the new one.
Projects that skip it do not discover the problem in the mapping. They discover it after the cutover, with the operation running on the new system and the old one already switched off.
The expensive part is not writing the obvious rows. It is finding the missing ones: a source field with no destination is data that disappears at cutover; a destination field with no source is a screen that opens empty on Monday morning.
How we do it
Read the real types, not the documented ones
In legacy systems, a date field stored as free text is more common than anyone expects. The mapping records what the data actually is, which is frequently not what the schema claims.
Rehearsal loads, repeatedly
The first load always surprises someone. So does the second. We repeat until a load produces no surprises at all — that repetition is what turns cutover weekend from an event into a formality.
Reconciliation, not confidence
After each load, the two sides are compared: counts, totals, and spot checks by record. Proving nothing was lost is a different activity from believing it, and only the first one survives a question from finance.
A cutover with a way back
The plan includes the rollback and the point of no return, both written down and agreed before the weekend starts. A cutover without a defined way back is a bet, not a plan.
Frequently asked
The old system has no documentation. Is that a blocker?
No — it is the normal case. The schema, the data itself, and the people who operate the system are three sources that together reconstruct most of the rules. What genuinely slows things down is not missing documentation but missing access to a production-like copy of the data.
Can we run both systems in parallel?
For a period, usually yes, and it de-risks the cutover considerably. The cost is that writes have to go to one side only or be reconciled continuously — running both as sources of truth creates a divergence problem worse than the migration itself.
How long does a migration take?
It depends far more on the number of source systems and the state of the data than on record count. A single well-structured database moves in weeks; a decade of accumulated tables with inconsistent keys is a project measured in months, and the mapping is where that becomes clear.
Also from us
Read this in Portuguese
The Portuguese version of this page goes into more depth: /servicos/migracao-de-sistema-legado.