Your old data moved complete and correct into your new system.

You are switching. From the accounting package you have used for fifteen years to a new ERP, from an Access database nobody dares touch to a web application, or from three loose Excel files to one system. The software is chosen and the license is signed. Then comes the question everyone postponed until the last moment: how do we get the clients, articles, open invoices, and ten years of history from the old system into the new one, without losing anything on the way?

Why switching so often goes wrong on the data

The vendor of the new package supplies an import template. Someone on your team fills it in from an export of the old system. That works for the first hundred clients. By the thousandth, you find that the old package kept addresses in one field and the new one expects four. The articles turn out to use three different units for the same product. And the open invoices refuse to import because the VAT codes have changed names.

That is not carelessness. Two systems store the same reality differently, and an import template cannot make that translation. What you are left with is a new package missing half the history, an old package you dare not cancel, and an accountant who has to balance the opening figures by hand. We do that translation as programming work, not typing work.

Count first, then move

We do not start by moving anything. We start with an inventory. Which tables are in the old system, how many records do they hold, and who still uses them? Often part of the data is a leftover from an earlier switch, and it does not need to move. For everything that does move, we record the mapping field by field: this field in the old package becomes that field in the new one, with this conversion in between. The mapping is a document you can read yourself, and your accountant or application manager can rely on it.

Counting also exposes dirty data. Clients that appear twice with slightly different spellings, articles without a unit, addresses in the notes field. We remove small problems during the migration. If the problem is structural, it is a separate job that we do first under Master data management. Filling a new system with old junk is the most expensive way to keep junk.

A trial migration on a copy

The migration itself is a set of scripts that we write, run, and adjust until it is right. We run them on a copy of the old system into a test environment of the new one, then check the result: the same number of clients, the same number of open invoices, the same balance per ledger account. If a number is off, we find out why and change the script, not the data. We repeat this until the check comes back clean twice in a row. From the first trial run, you can look through your own data in the test environment, usually within ten business days.

Because the scripts can be repeated, the real switch at the end takes hours instead of weeks. We pick a quiet moment, set the old system to read-only, run the migration one last time on the final state, and do the same check as before. Only when it matches does your team start work in the new package on Monday morning. If the new system must keep exchanging data with other packages afterward, we handle that with Data pipelines or System integration, so the switch does not create new islands.

What happens to the old system

After the switch, you want to cancel the old package, but not move all the history with it. Ten-year-old quotes do not need to be in the new system, and sometimes they do not even fit. Still, you must be able to look them up when the Dutch Tax Administration has a question or a client asks about an old delivery. So we put what stays behind in a readable archive: a database of its own or an export you can search without the old license. If you want to keep reporting on that history alongside your new figures, the Data warehouse and lakehouse is the place for it.

The scripts, the mapping, and the check report are yours. Three years from now you still know exactly which field ended up where, and someone else can review it without us. We move personal data in line with the GDPR, everything stays within the EU, and we delete the copies we make along the way when we are done.