ERP-datamigratie: hoe u uw data klaar maakt voor een succesvolle implementatie
In bijna elk ERP-project staat ERP-datamigratie op één regel in het projectplan: “Data migreren naar nieuw systeem.” In de praktijk vraagt die regel meer tijd dan alle technische configuratie bij elkaar. Wie dat vooraf weet, plant anders. Wie dat niet weet, merkt het drie maanden vóór go-live.
Dit artikel beschrijft wat erp datamigratie in de praktijk inhoudt, welke fouten de meeste vertragingen veroorzaken, en hoe sector-specifieke datachallenges uw aanpak bepalen. Het richt zich op IT-managers en projectleiders die verantwoordelijk zijn voor de technische kant van een ERP-traject.
Waarom datamigratie meer is dan data verplaatsen
De naam suggereert een transportprobleem: data staat in systeem A en moet naar systeem B. Technisch klopt dat. Maar het echte vraagstuk is niet het transport; het is de kwaliteit van wat u verplaatst.
Elk ERP-systeem legt data op zijn eigen manier vast. Klantgegevens in het ene systeem hebben een andere structuur dan in het andere. Artikelcodes die in uw bestaande omgeving uniek waren, botsen in het nieuwe systeem met bestaande records. Valutasymbolen, datumnotaties, decimale scheidingstekens: in vijftien jaar schijnbaar stabiele data komen inconsistenties naar boven die niemand meer kende.
ERP-datamigratie maakt zichtbaar hoe coherent uw processen daadwerkelijk zijn. Wat in de operatie als losse uitzonderingen bestond, komt bij migratie als patroon op tafel.
Behandel dit als diagnose. Organisaties die twintig jaar met hetzelfde ERP werken, hebben in die tijd data opgebouwd die de groei weerspiegelt: overnames, herstructureringen, afdelingen die zijn opgeheven of samengevoegd. Al die veranderingen hebben sporen in de data achtergelaten, en die moet u opsporen voordat u migreert.
ERP Company begeleidt als onafhankelijke consultancy organisaties bij ERP-trajecten. Met 260+ specialisten actief in productie, groothandel en dienstverlening, zien wij dat dataproblemen bijna altijd eerder zichtbaar zijn dan de go-live, maar pas serieus worden genomen als de datum nadert. Dat is de verkeerde volgorde.
Sector-specifieke datachallenges: wat u kunt verwachten
Datamigratie-uitdagingen zijn niet overal gelijk. Uw sector bepaalt grotendeels welke datakwaliteitsproblemen u tegenkomt en hoeveel tijd de voorbereiding vraagt.
Productie & Manufacturing
In een productieomgeving liggen de datakwaliteitsproblemen vaak in de artikelstamdata: stuklijsten, routeringen en productie-orders. Artikelcodes zijn in de loop der jaren inconsistent opgebouwd, soms handmatig bijgehouden in Excel naast het ERP, of gesplitst over meerdere locaties met hun eigen nummering.
De historische voorraaddata is een aandachtspunt. Productieorganisaties willen vaak jaren aan voorraadmutaties meenemen voor analyse. De vraag is welke van die gegevens betrouwbaar zijn om te migreren, en welke meer ruis introduceren dan waarde toevoegen.
In onze ervaring bij een productiebedrijf met meerdere productielocaties bleek bij de inventarisatie dat circa een vijfde van de actieve artikelcodes feitelijk inactief was: producten die jaren niet meer waren besteld. Schoonmaak vóór de migratie scheelde meer dan een maand testwerk.
Voor IT-managers in de maakbranche: controleer welke stuklijsten actief zijn versus archief. Inactieve stuklijsten blijven jarenlang staan. Wie ze allemaal meeneemt, vergroot de complexiteit zonder voordeel voor de business. Voor een gestructureerde aanpak helpt onze data management & migratie dienstverlening.
Groothandel & Distributie
Groothandelsbedrijven hebben doorgaans een groot artikelbestand en complexe relaties met leveranciers en klanten. De uitdaging zit in de datakwaliteit van klant- en leveranciersgegevens: dubbele records, verouderde adressen, klanten die jaren inactief zijn.
Een veelvoorkomend probleem is de klantpricing-structuur. Kortingsafspraken en prijslijsten zijn soms deels in het ERP vastgelegd en deels buiten het systeem gehouden, in Excel of in mondelinge verkoopafspraken. Bij een erp datamigratie moet u beslissen welke van die afspraken doorgaan naar het nieuwe systeem, en hoe de validatie plaatsvindt.
In onze ervaring bij een distributiebedrijf bleek bij de eerste cleansing-ronde dat tussen de 12 en 15 procent van de klantrecords dubbel of inactief was, vaak door fusies en overgenomen klantgroepen die nooit waren opgeschoond. Pas na het samenvoegen werd de pricing-structuur in het nieuwe systeem hanteerbaar.
Logistieke data zoals locaties, routes en batches vragen extra aandacht. Als uw nieuwe ERP een andere locatiestructuur hanteert, is de mapping geen triviaal klusje.
Dienstverlening & Maintenance
Bij dienstverlening en maintenance-organisaties ligt de uitdaging minder in het artikelbestand en meer in de projecthistorie en contractdata. Langlopende servicecontracten, sla-afspraken per klant, facturatieafspraken: gegevens die in bestaande systemen zelden uniform zijn vastgelegd.
U moet vroeg beslissen welke historische projectdata meegaan. Projecten die vijf jaar geleden zijn afgesloten zijn operationeel niet relevant meer, maar wel voor trend-analyses of klantreferenties. Die afweging bepaalt de omvang van de migratie en daarmee de doorlooptijd.
Voor onderhoudsorganisaties: machinekaarten en onderhoudshistorie zijn bedrijfskritisch en vaak de meest vervuilde data in het systeem. In onze ervaring bij een maintenance-organisatie bleek dat circa een derde van de machinekaarten incomplete onderhoudshistorie had, omdat veldmonteurs jarenlang notities op papier hadden bijgehouden. Het in kaart brengen van die gap vóór de migratie maakte het verschil tussen een werkbare service-operatie op dag één en wekenlang reparatiewerk.
Stamdata of transactiedata: welke gaat eerst?
Een belangrijk onderscheid bij erp datamigratie is het verschil tussen stamdata en transactiedata. Beide gaan mee naar het nieuwe systeem, maar de aanpak verschilt wezenlijk.
Stamdata zijn de structurele gegevens van uw organisatie (klanten, leveranciers, artikelen, grootboekrekeningen) die niet veranderen met transacties. Een fout in een klantrecord werkt door in elke factuur die u daarna maakt. Als die basis niet klopt, klopt niets daarna.
Transactiedata zijn de historische gebeurtenissen in uw ERP: orders, facturen, voorraadmutaties, betalingen. Die zijn op dag één na go-live minder kritisch voor de operatie, maar waardevol voor analyse en klantvragen over oude bestellingen.
Stamdata migreert u vroeg in het project, zodat ze tijdens de testfase beschikbaar zijn. Transactiedata migreert u vlak voor de go-live, zo actueel mogelijk. Stamdata valideert u bij elke testmigratie opnieuw; transactiedata valideert u eenmalig op volume en steekproef, niet regel voor regel.
Een veelvoorkomend probleem: stamdata is later klaar dan gepland, waardoor de testfase wordt uitgesteld. En als de testfase verschuift, verschuift de go-live mee. De richtlijn: stamdata eerst, transactiedata later, validatie continu.
De vier fasen van een succesvolle ERP-datamigratie
Een erp datamigratie die op tijd klaar is en met schone data werkt, heeft altijd een gestructureerde aanpak gevolgd. Die aanpak bestaat uit vier fasen die achtereenvolgens worden doorlopen.
Fase 1: inventarisatie
Breng in kaart welke data in uw huidige systeem zit, welke bronnen er zijn, en welke data relevant zijn voor het nieuwe systeem. Stel per databron: is deze data actueel? Is ze historisch gegroeid zonder duidelijke eigenaar? Welke afdeling is verantwoordelijk voor de kwaliteit?
In deze fase belegt u data-eigenaarschap formeel, zodat de schoonmaakwerkzaamheden in fase 2 niet vastlopen op afdelingsdiscussies. De data management & migratie aanpak van ERP Company begint altijd met deze inventarisatie.
Output van fase 1: een gedocumenteerd overzicht van alle databronnen, de aantallen records per entiteit en een eerste inschatting van de datakwaliteitsproblemen per bron. Dit overzicht is de basis voor de tijdplanning van de migratie.
Fase 2: datakwaliteit meten en verbeteren
Voer een datakwaliteitsanalyse uit: hoeveel records zijn leeg, dubbel of inconsistent? Hoe verhoudt de bestaande datastructuur zich tot die van het nieuwe systeem?
Op basis van de analyse bepaalt u welke data gereinigd worden vóór migratie, en welke niet meegaan. Datareiniging is tijdrovend werk dat niet onderschat moet worden. Lees ook hoe data cleansing bij ERP-migraties werkt. Wie te weinig tijd uittrekt, migreert zijn problemen mee naar het nieuwe systeem.
Fase 3: transformatie en laden
In deze fase worden de gereinigde data omgezet naar het formaat van het nieuwe ERP en geladen in de testomgeving. Bijna altijd zijn er mapping-vraagstukken: hoe verhoudt het oude datamodel zich tot het nieuwe? Welke velden zijn verplicht in het nieuwe systeem maar optioneel in het huidige?
Testmigraties voert u meerdere keren uit. Elke ronde levert bevindingen op die u oplost voor de volgende. Plan minimaal twee of drie testmigraties, en zeker een afrondende run vlak voor de go-live.
Fase 4: validatie na go-live
Na de go-live begint de validatiefase. Voer een steekproef uit op klantgegevens, leveranciersdata en openstaande posities. Controleer of transactiehistorie correct is geland. Stel een protocol in voor meldingen vanuit de business over dataproblemen die de eerste weken naar boven komen.
Dataproblemen die pas na go-live worden ontdekt, zijn duurder op te lossen dan problemen die vóór go-live zijn gevonden. Elke fout in productie vraagt correctie in het systeem én herstel van processen die al op die fout zijn gelopen. Plan daarom een tweede validatie-ronde na vier weken, wanneer de eerste maandafsluiting de minder zichtbare fouten aan het licht brengt.
Hoeveel tijd kost elke fase?
De doorlooptijd van data cleansing is in onze ervaring 2 tot 3 keer de tijd die teams er bij projectstart voor uittrekken. De technische migratie zelf is meestal het kleinere deel van het werk; de voorbereiding en validatie zijn het zwaartepunt. Onderstaande verdeling is richtinggevend; afhankelijk van organisatieomvang en datakwaliteit schuiven de verhoudingen.
| Fase | Indicatieve tijdsbesteding |
|---|---|
| 1. Inventarisatie | ~10% |
| 2. Datakwaliteitsanalyse en cleansing | ~40-50% |
| 3. Transformatie en testmigraties | ~25-30% |
| 4. Validatie na go-live | ~10-15% |
Wie het cleansingbudget halveert om “ruimte” te maken voor configuratie, vindt die ruimte vlak voor go-live alsnog terug, op het slechtste moment.
Wie is verantwoordelijk voor welke data?
Onduidelijk data-eigenaarschap is in onze ervaring een terugkerende oorzaak van vertraging. Wie pas in fase 2 ontdekt dat niemand de artikelstamdata bezit, verliest weken aan afstemming. Een compacte RACI-matrix in fase 1 voorkomt dat.
| Data-entiteit | Verantwoordelijk (R) | Eindverantwoordelijk (A) | Geraadpleegd (C) | Geïnformeerd (I) |
|---|---|---|---|---|
| Klantgegevens | Sales-ops | CFO | IT, Marketing | Operations |
| Artikelstamdata | Product manager | COO | Inkoop, Productie | Sales, Finance |
| Leveranciersgegevens | Inkoop | CFO | Finance, Quality | Operations |
| Grootboekrekeningen | Finance-controller | CFO | IT, Audit | Management |
| Voorraad-/transactiehistorie | Operations | COO | IT, Finance | Sales |
Deze tabel is een startpunt, geen voorschrift. De rolverdeling per organisatie varieert; de discipline om de matrix vóór de inventarisatie te ondertekenen is wat de tijdwinst oplevert.
Vijf fouten die ERP-datamigraties vertragen
De meeste vertragingen zijn terug te voeren op een beperkt aantal fouten. Wie ze kent, kan ze voorkomen.
Data-eigenaarschap niet vastleggen. Wie is verantwoordelijk voor de kwaliteit van de artikelstamdata? Wie beslist welke klantgegevens worden opgeschoond? Zonder vastlegging wordt datakwaliteitswerk een afdelingsdiscussie in plaats van een gestructureerde taak.
Datareiniging te laat starten. Data cleansing is tijdrovend. Wie er in de laatste twee maanden vóór go-live mee begint, heeft te weinig tijd om bevindingen te verwerken. Bij trajecten van twaalf maanden start de analyse idealiter in de eerste drie maanden, parallel aan de systeeminrichting.
Te weinig testmigraties uitvoeren. Eén testmigratie geeft een eerste beeld, maar lost de problemen niet op. Na elke ronde komen nieuwe bevindingen. Plan meerdere rondes en reserveer tijd voor verwerking.
De business niet betrekken bij de validatie. IT kan controleren of data technisch correct zijn geladen; of ze inhoudelijk kloppen, weet de business. Betrek afdelingshoofden en key users; zij herkennen fouten die op de datalaag niet zichtbaar zijn.
Te veel historische data meenemen. Meer data betekent niet meer waarde. Verouderde records, inactieve klanten en afgeschreven artikelen vergroten de complexiteit en de opstarttijd zonder voordeel. Bepaal vooraf welke historische data operationeel relevant zijn.
Hoeveel tijd kost een ERP-datamigratie bij een twaalf-maands traject?
Bij een implementatie van twaalf maanden start de datakwaliteitsanalyse in de eerste drie maanden, parallel aan de inrichting. De technische migratie zelf vindt in de laatste maanden plaats, maar het voorwerk loopt door het hele traject. Bij kortere of langere implementaties verschuiven de blokken proportioneel.
| Periode | Hoofdactiviteit datamigratie |
|---|---|
| Maand 1-2 | Inventarisatie, data-eigenaarschap formeel belegd |
| Maand 3-6 | Datakwaliteitsanalyse en cleansing, parallel aan systeeminrichting |
| Maand 7-9 | Eerste testmigraties, mapping-bevindingen verwerkt |
| Maand 10-11 | Tweede en derde testmigratie, finetuning |
| Maand 12 | Definitieve transactiemigratie en validatie na go-live |
In onze ervaring bij 260+ specialisten besteedt een organisatie de meeste tijd aan datawerkzaamheden, niet aan de technische migratie. Wie vroeg start, voorkomt een vastlopende go-live.
Intern of uitbesteden: wat past bij uw organisatie?
IT-managers staan bij datamigraties voor de keuze tussen interne organisatie of externe expertise. Die keuze maakt u op basis van feitelijke capaciteit en kennis, niet op basis van principes.
Intern aanpakken werkt goed als u een team heeft dat het huidige systeem door en door kent, voldoende capaciteit heeft naast het lopende projectwerk, en ervaring heeft met datamigraties.
Externe ondersteuning is zinvol als de migratie specifieke kennis vraagt van het nieuwe platform, als de tijddruk groot is, of als de datakwaliteitsproblemen omvangrijker zijn dan vooraf ingeschat.
ERP Company biedt onafhankelijke ondersteuning bij data management en ERP-migraties, van inventarisatie tot go-live validatie. Als platform-onafhankelijke partij werkt ERP Company met de meeste gangbare ERP-platformen, zonder belang bij een specifieke tooling.
Wilt u weten wat er bij uw migratietraject komt kijken? Neem contact op voor een oriënterend gesprek.
De verbinding met ERP-implementatie en change management
Datamigratie is geen zelfstandig traject naast de implementatie: het is een kritisch pad binnen het project. De beschikbaarheid van schone data op het juiste moment bepaalt of uw testfase kan starten, of trainingen met realistische data kunnen plaatsvinden, en of uw go-live op de geplande datum haalbaar is.
Het is ook een menselijk vraagstuk. Medewerkers die in de testfase werken met onjuiste testdata, ontwikkelen een vertekend beeld van het nieuwe systeem. Dat vertekende beeld heeft gevolgen voor de adoptie na go-live. Lees hoe ERP-change management samenhangt met de technische migratie, en hoe u voorkomt dat dataproblemen uitgroeien tot adoptievraagstukken.
Voor organisaties die ook een cloudmigratie overwegen, is de data-voorbereiding nog complexer. Kritische succesfactoren bij een ERP-cloudmigratie geeft inzicht in de aanvullende stappen bij een cloud-traject.
Veelgestelde vragen over ERP-datamigratie
Hoeveel tijd kost een ERP-datamigratie?
Een ERP-datamigratie kost typisch tussen 30 en 50 procent van de totale implementatietijd, afhankelijk van datavolume en de kwaliteit van de uitgangssituatie.
In onze ervaring vergt de datakwaliteitsanalyse en cleansing meer tijd dan de technische migratie zelf. Bij een implementatie van twaalf maanden start de analyse in de eerste drie maanden, parallel aan de inrichting van het systeem. Wie later start, neemt het risico dat de testfase wordt uitgesteld en de go-live doorschuift.
Moet alle historische data mee naar het nieuwe ERP?
Nee. Alleen historische data die operationeel relevant of analytisch waardevol is gaat mee; de rest archiveert u of laat u staan.
Stamdata gaan altijd mee. Transactiedata maakt u per categorie een bewuste keuze: openstaande orders en posten zijn kritisch, terwijl orders van vijf jaar terug vaak prima in een archief kunnen blijven. Meer data betekent meer migratie-complexiteit zonder evenredig voordeel.
Wat is het grootste risico bij een ERP-datamigratie?
Het grootste risico is dat dataproblemen pas na de go-live zichtbaar worden, op het moment dat processen al op de fout zijn gelopen.
Correctie in een live systeem is in onze ervaring een veelvoud van wat preventie vóór de go-live kost. Meerdere testmigraties met business-validatie, gecombineerd met heldere data-eigenaarschap, zijn het meest effectieve middel om dat risico te beperken.
Hoe betrek ik de business bij de datakwaliteitsverbetering?
Beleg per data-entiteit een inhoudelijke eigenaar binnen de business en koppel die rol aan de validatie van iedere testmigratie.
IT bewaakt het technische proces; de business bepaalt of de data inhoudelijk klopt. Gebruik een RACI-matrix om de rollen vast te leggen vóór fase 2. Eigenaren die pas in fase 3 worden aangewezen, lopen achter de feiten aan.
ERP-datamigratie is geen werk dat u achteraf kunt inhalen. De kwaliteit van uw data op de go-live-dag bepaalt voor een belangrijk deel hoe uw start verloopt: soepel, of met reparatiewerk.
Begin vroeg, beleg eigenaarschap duidelijk, en behandel datareiniging als vakwerk. Organisaties die dat doen, starten met een fundament dat klopt. Dat fundament bepaalt hoeveel waarde het systeem over de komende jaren oplevert.
Wilt u weten wat een goede datamigratie-aanpak bij uw traject betekent? Neem contact op met ERP Company voor een oriënterend gesprek.
Verder lezen: Het volledige traject, van kickoff tot livegang, leest u in onze aanpak van een ERP-implementatie.