Atlas Academy · ERP · Datamigratie · Planning
Een ERP-implementatie strandt vaker op de data dan op de software. De meeste problemen zijn voorspelbaar — als je weet waar je op moet letten. Vijf concrete valkuilen, met de checks die je al in de offertefase uitvoert.
Een nieuw ERP-systeem is pas zo goed als de data die erin zit. De software kan een go-live overleven met een configuratiefout — een fout in de data pas niet. Als de openstaande debiteuren niet kloppen op dag 1, werkt je incassoproces niet. Als de artikelstammen fout zijn, gaat elke order mis. Als de historische voorraadmutaties ontbreken, kan de boekhouding niet afsluiten.
In onze ervaring is datamigratie verantwoordelijk voor 40–60% van de vertragingen bij ERP-trajecten. Niet omdat het technisch ingewikkeld is, maar omdat de kwaliteit van de brondata structureel slechter is dan verwacht — en omdat de meeste projectplannen te weinig tijd inruimen om dat te repareren.
De standaard-aanpak bij veel leveranciers: exporteer alle data uit het oude systeem, importeer het in het nieuwe. Alles gaat mee — inclusief dubbele klantrecords, verouderde artikelen, gecancelde orders die nooit zijn verwijderd, en leveranciers die al drie jaar niet meer actief zijn.
Het resultaat is een nieuw systeem vol met oud vuil. Gebruikers begrijpen niet waarom er 400 artikelen zijn die niemand herkent. Rapporten kloppen niet omdat de historische data structureel afwijkt. Support-tickets gaan over problemen die al in het oude systeem zaten — maar die nu zichtbaarder zijn.
De check: vraag de leverancier of er een data-audit in de offerte zit. Een goede partner exporteert de brondata als eerste stap en levert een kwaliteitsrapport voor de migratie begint. Wie dit overslaat, rekent op jouw data voor de volle 100% op orde.
Elk ERP-systeem heeft een eigen datamodel. Klantrecords, artikelstammen, historische facturen — de velden komen bijna nooit 1-op-1 overeen. Een handmatig veld in het oude systeem (bijv. «regio») bestaat misschien niet in het nieuwe, of heet anders, of is een lookup-tabel in plaats van een vrij tekstveld.
Mapping kost tijd. Voor een gemiddeld MKB-bedrijf met 5.000 artikelen, 2.000 klanten en twee jaar factuurhistorie rekenen we op 15–40 uur aan migratie-engineering — meer als de brondata rommelig is. Offertes die niet expliciet uren voor mapping bevatten, berekenen die uren later als meerwerk.
De check: vraag in de offerte hoeveel uur voor datamapping is ingecalculeerd, en wat de aanpak is voor velden die niet bestaan in het nieuwe systeem.
De meeste datamigratietrajecten kennen twee iteraties: een testmigratieronde en de definitieve migratie. De testronde vult het nieuwe systeem met productiedata, laat gebruikers controleren of alles klopt, en registreert afwijkingen die voor de definitieve migratie worden opgelost.
Om tijd en kosten te besparen slaan projecten deze stap regelmatig over. Het resultaat: de definitieve migratie is meteen ook de testronde — live, in productie, met klanten en facturen. Fouten worden ontdekt op dag 1 na go-live, wanneer ze het meest schaden.
De check: staat er in het projectplan expliciet een testmigratieronde voor go-live? En is er een formeel akkoord-moment waarbij gebruikers de testdata valideren?
Veel leveranciers migreren alleen de «actieve» data: huidige klanten, lopende orders, recente facturen. Historische data (twee jaar terug en verder) gaat naar een archief of wordt niet meegenomen.
Het probleem: «historisch» is minder dood dan gedacht. Belastingaangiften lopen drie tot vijf jaar terug. Garantietrajecten gebruik historische aankoopdata. Serienummer-tracking voor compliance gaat soms tien jaar terug. Als die data er niet in zit, ben je afhankelijk van het oude systeem — dat je dan ook niet kunt afsluiten.
De check: definieer vóór de implementatie hoever de historische data moet meegaan. Leg dit schriftelijk vast. En zorg dat het oude systeem in read-only staat bewaard blijft voor minimaal vijf jaar na de overstap.
De cutover is het moment waarop je definitief omschakelt van oud naar nieuw. Alles wat na dat moment gebeurt, staat in het nieuwe systeem. Alles wat voor dat moment stond, staat in het oude. Klinkt simpel — maar in de praktijk is er een grijs gebied: wat doe je met orders die op het cutoverbmoment half-open staan? Facturen die voor go-live zijn aangemaakt maar na go-live betaald worden? Creditnota's die teruglopen naar historische facturen?
Een slecht geplande cutover leidt tot dubbele boekingen, handmatige correcties, en een boekhouding die de eerste twee maanden niet sluit. Een goede cutover wordt tot op het uur gepland: welke transacties worden in het oude systeem afgesloten, welke worden opnieuw aangemaakt in het nieuwe, en wie voert dat handmatig in als er geen automatische mapping voor bestaat.
De check: vraag de leverancier naar zijn cutover-protocol. Er moet een schriftelijk document zijn. Als dat er niet is, is dit onderdeel van het project onvoldoende uitgewerkt.
Stuur deze lijst naar elke leverancier die je overweegt, en beoordeel de antwoorden:
1. Zit er een data-audit in de offerte, vóór de migratie begint?
2. Hoeveel uur is ingecalculeerd voor datamapping, en is dat voldoende voor de
omvang van mijn dataset?
3. Is er een testmigratieronde gepland vóór go-live, met een formeel
akkoord-moment?
4. Welke historische data migreert mee, en wat is de aanpak voor archief-data?
5. Is er een schriftelijk cutover-protocol, inclusief de aanpak voor transacties
die over de cutovertijdlijn vallen?
Een leverancier die op alle vijf een concreet antwoord geeft, heeft dit eerder gedaan. Een leverancier die véén of meer vragen afdoet met «dat regelen we onderweg», geeft je een voorproefje van hoe hij met onverwachte situaties omgaat — niet later, maar nu.
Plan een intake als je voor een ERP-switch staat en de datamigratieaanpak van een leverancier wilt laten beoordelen. We kijken onafhankelijk mee — ook als je al met een andere partner in gesprek bent.