Data migration

A migration is judged three months after the cutover.

It is judged the day somebody compares last year’s revenue in the new system with the figure they presented to the board. If the two do not match, the migration failed, even though every row went across.

Categories of variance, all traced: 3
Cutovers on an unexplained variance: 0
Business Central, Nav, SAP, Sage: 4 ERP
Expert consultants: 11

3
Categories of variance, each with its own treatment: 0
Cutovers on a variance nobody can explain: 2–3
Fiscal years usually enough in the new ERP: 100 %
Of history kept in the data platform

Where the value is

Moving the rows is the easy part

A data migration presents itself as a technical problem: extract, transform, load. That is the part tools handle well, and it is rarely where projects fail.

The real problem is semantic. In the old system the “category” field holds three values inherited from an organisation that stopped existing in 2018; the “customer code 2” field was repurposed to store a site code; a commercial discount is sometimes a negative invoice line and sometimes a header field. None of that is in a schema. It is in the memory of three people, two of whom have left.

Our work is to recover those conventions, write them down, have them validated, and then demonstrate by calculation that the translation is right. Moving the data comes last, and it is the shortest part.

If last year’s revenue does not match to the cent, we do not go live.
What we check before every cutover

Reconciliation

Three kinds of variance, three treatments

Documented, we move on

Explained and intended

The old system counted cancelled orders in revenue; the new one does not. The variance is real, it is intended, and it is written in the acceptance report with its amount. Nobody will rediscover it in six months.

We fix and replay

Explained and unintended

A mapping error: two tax codes merged by mistake, a posting date taken instead of an invoice date. We fix the rule and replay the whole import. Never a manual correction on loaded data.

The cutover waits

Unexplained

Eighty euros missing on a forty-million year. Statistically negligible, and yet: a variance you cannot explain is one whose cause, and therefore whose reach, you do not know. It blocks the cutover until it is found.

Ground knowledge

What we know about each system

Every system has its habits. Knowing them in advance saves weeks: these are the ones we meet most often.

What we anticipate on each source system
System	Its particularity	What we put in place
Business Central	FlowFields are not stored: they are calculated on the fly. A naive extract brings them back as zero, and customer balances look empty.	We rebuild them as explicit measures from the ledger entries, and reconcile against the ERP screen, line by line.
Business Central, several instances	Each company has its own chart of accounts, item codes and dimensions. The same code means two different things.	We add a reconciliation step before any consolidation, and use bc2adls for an incremental export that spares the API quotas.
Dynamics NAV	Analytical dimensions often changed meaning across versions, with nothing recording it.	We date each convention and apply the right one per period. A code is not translated the same way in 2014 and in 2024.
Sage 100 and Sage 1000	Analytics are often kept partially, with unallocated entries an aggregated report hides.	We isolate and quantify the unallocated rather than spreading it pro rata. A wrong figure spread neatly is still wrong.
SAP	Volume and depth of history make a full extract expensive, and the tables are many.	We narrow the scope to the domains actually used for steering, after the inventory, not before.
Service spreadsheets	They hold the real rules, and they are neither versioned nor consistent with one another.	We treat them as a source in their own right: reading, formalising the rules, validation by their author, then replacement.

Our position

Between three parties, serving only one

A migration brings three players together: the integrator of the old solution, the integrator of the new one, and your teams. Each holds part of the answer and none holds all of it.

The incumbent integrator

They know why the field was repurposed, which version introduced which convention, and which bespoke developments run before a record is saved. They are the most valuable source and the hardest to mobilise, because the project marks the end of their engagement.

The new solution’s integrator

They know what the target expects, which checks it applies on loading, and which data it will refuse. They know the arrival format, rarely the meaning of the data it comes from.

Your teams

They know which figures must match, and they are the ones who will approve or refuse the cutover. They are the final authority on meaning, even when they do not know the structure of the tables.

Our place

Between the three, with nothing to sell on the old system or the new one. We establish the mapping, document it, and demonstrate it through the reconciliation. It is the only position from which arbitration is credible.

The cutover

Parallel run, criteria, rollback

Cutover is a moment of risk, and risk is reduced by decisions taken in advance, not by vigilance on the day.

The parallel run keeps both systems running side by side for an agreed period, with automated reconciliation every day. It is not comfortable for your teams, who key everything twice; it is what lets us detect a variance on real data, before it becomes irreversible.

The cutover criteria are written beforehand, not decided on the day: which totals must match, to what tolerance, on which scopes. A criterion written after the fact always bends to the result obtained.

The rollback plan states what stays readable, for how long, and until what date the decision to cancel remains open. Without a deadline the question keeps coming back and nobody dares to settle it.

Inventory and mapping
What exists, what it means, and the correspondence table that translates it. Produced as a deliverable you can review.
Parallel run
Both systems run side by side for an agreed period, with automated reconciliation every day.
Written cutover criteria
Which totals must match, to what tolerance, on which scopes, decided before, not on the day.
Rollback plan
What stays readable, for how long, and until what date cancelling remains possible.

Systems

What we migrate from, most often

Business CentralSaaS and on-premise, single or multi-instance
Dynamics NAVIncluding versions with heavy customisation
SAPScoped to the domains used for steering
Sage 100 and Sage 1000Accounting, analytics, sales management
Service spreadsheetsTreated as a source in their own right
Custom softwareIn-house applications and legacy databases

Going further

What extends a successful migration

Frequently asked

What people ask us about migrations

How long does a data migration take?

It depends far less on volume than on the number of rules that have to be recovered. Moving three years of sales out of a single Business Central takes days. Moving the same history out of a 2013 Nav whose analytical dimensions changed meaning twice takes weeks: not to move the rows, but to establish what each code meant at each period.

What happens when the totals do not match?

That is the normal outcome of the first reconciliation, and precisely what it is for. Every variance is classified: explained and intended, explained and to be corrected, or unexplained. The first two are documented or fixed. The third blocks the switch: we never go live on a variance nobody can explain.

Do you work with our incumbent integrator?

Yes, and it is often the key. The incumbent knows why the “customer code 2” field was repurposed in 2016; the new solution's integrator knows what it expects. We sit between the two and establish the mapping. That position is uncomfortable and it is ours: we have nothing to sell on either side.

Do we have to migrate everything?

Almost never. Moving ten years of transactional history into a new ERP is expensive, slows the system down and rarely serves. The better answer is usually two or three fiscal years in the ERP for operational needs, and the full history in the data platform, where storage costs little and everything stays queryable. We systematically propose that split.

What if we need to roll back?

The rollback plan is part of the cutover plan, not an option. Concretely: the old system stays readable for an agreed period, imports are replayable identically, and the rollback decision has a written criterion and a deadline. A cutover with no rollback criterion is a cutover nobody dares cancel.

The cutover

One domain at a time

Each domain moves across one after the other while the existing platform keeps serving. The overlap lets your teams compare the two platforms on their own figures before deciding what comes next.

One domain at a time, never everything at once

The existing platform keeps serving while each domain moves across, which lets your teams compare on their own figures.

The overlap is the heart of the method: it is where your teams put the two platforms side by side on real data. The pace of what follows is decided on what they observe, not on a calendar fixed in advance.

Tell us where you are coming from, and where you are going.

Eleven expert consultantsSaint-Priest, near Lyon, France

Two hours with a consultant, free of charge. We look at the source system, the target system and the figures that will have to match, and we tell you what we would move, what we would leave, and where we expect variances.

Request a scoping workshop

Scoping workshop · 2 hours · free · near Lyon or remote