Data migrations

A data migration without data loss and without surprises: we move your data from old to new with dry runs and validation - and the old system stays in place until the proof is on the table.

Open about our stack

PostgreSQL Python Azure REST & GraphQL

You are moving to a new package or platform, but years of customer records, orders and history live in the old system. The export button exists - the fields just don’t match, the formats differ, and nobody dares to press “migrate for real”. So the old system keeps running next to the new one, with double work as the result.

We treat a migration as an engineering problem, not a removal job. No manual copy work, but repeatable scripts that we rehearse as often as it takes until every run demonstrably checks out. Data migrations are a fixed part of our work on data & integrations.

Migration plan with field mapping and risks per data type
Repeatable migration scripts instead of manual work
Dry runs on a copy of your production data, with a validation report per run
Cleaning and deduplicating polluted data along the way
Controlled go-live with a fallback to the old system

A data migration without data loss: what that looks like

The shape differs per situation: from a dated package to a new platform, dozens of spreadsheets into one database, merging two systems after an acquisition, or moving the content of several websites into a single environment. The approach is always the same. First we map each source: which data lives there, where it needs to go, and what has to be translated along the way - field names, formats, relationships between records. That mapping immediately exposes where the data is polluted: duplicate customers, empty fields, history that no longer points anywhere.

Then comes the most important principle: we never migrate for real in one go. The migration first runs as a dry run on a copy of your actual data - as often as needed. Every run produces a validation report: do the counts match, do the totals match, do the spot checks your own people perform hold up? Only when the outcome is repeatably correct do we plan the actual switch. And even then, the old system remains available until everyone has established that nothing is missing.

A migration rarely stands on its own. Often it is the first step towards a landscape where systems update each other automatically through API integrations, or it belongs to an internal tool that replaces spreadsheets. So we think beyond the move itself: the target model has to hold up five years from now too.

Our approach: prove first, then migrate

up front

Analysis & mapping

We take stock of sources, field mapping and data quality, and record the risk per data type. This results in a migration plan with a concrete schedule.

rehearsal

Dry runs & validation

The migration runs repeatedly on a copy of your production data. Every run is validated - counts, totals and spot checks by your own people - until the outcome is repeatably correct.

go-live

Controlled switch

By then the actual switch is a short, predictable moment - scheduled when it affects your organisation the least, with a fallback scenario agreed in advance.

after

Aftercare & sign-off

The old system stays available until you establish that nothing is missing. It is only switched off after your sign-off - that decision is yours, not ours.

Migrating is part of our everyday work. For Metics we moved the contents of dozens of spreadsheets into one reliable planning platform - traceable and without manual formulas. For Stichting DOEN we are bringing four foundation websites together on a single platform, existing content included.

Frequently asked questions

What you want to know before you start.

How do you prevent data loss?

By never relying on a single attempt. The migration first runs as a dry run on a copy of your actual data, and every run is validated: counts, totals and spot checks performed by your own people. Nothing is thrown away along the way, and the old system stays intact until the numbers demonstrably match.

How much downtime should we expect?

Usually very little. Because the migration has been rehearsed several times, the actual switch is a short and predictable moment that we schedule when it affects you the least - often outside working hours. Where needed, old and new run side by side for a while, so work simply continues.

Can we go back if something goes wrong?

Yes. The fallback scenario is a fixed part of the migration plan, not an afterthought. The old system remains available after the switch, so falling back is possible without losing data. Only when you establish that the new system is complete and correct does the old one go offline - that decision is yours.

Our data is polluted. Is that a problem?

No - it is the rule rather than the exception. The mapping exposes where duplicate records, empty fields and inconsistencies live. Cleaning and deduplication are built into the migration scripts, based on decision rules we agree together. Whatever cannot be repaired automatically comes back to you as a clear list.

How long does a data migration take?

That depends on the number of sources and the quality of the data. After the analysis - the first step - you get a concrete schedule. Good to know: the lead time sits mostly in rehearsing and validating, not in the switch itself. That part is short, precisely because all the proof is already there.

What does a data migration cost?

It differs per situation, so we start with scope: which sources, how much data, how clean. After a first conversation you get a substantiated estimate, and we work in small, budget-controlled steps - you decide per step whether we continue. The integration scan, with a fixed one-week timeline, is a logical starting point.

Not sure your data can move safely? Jasper Kums, partner at eenvoud, is happy to think along about what your migration involves - no strings attached. Or start with an integration scan and get a clear view of your data flows in one week.

Book a call →