De aanname is hardnekkig: na een overname of bij een systeemwissel is datamigratie een IT-project. Je kiest een doelsysteem, een integrator bouwt de koppelingen, de data gaat van A naar B en de business krijgt op het einde een demo. Het klinkt logisch, en het verklaart waarom migraties zo vaak uitlopen.
Gartner becijferde ooit dat 83% van de datamigratieprojecten mislukt of het budget en de planning overschrijdt. Het cijfer wordt al jaren geciteerd en is intussen gedateerd (het onderzoek dateert van 2005), maar wie recente projecten van dichtbij volgt, herkent het patroon nog altijd. Bloor Research kwam in 2011 op 38% van de migraties die buiten tijd of budget landden, een verbetering, maar nog steeds meer dan één op drie.
Het opvallende is niet dat het misloopt, maar waar het misloopt. Zelden bij de technologie. Bijna altijd bij de vragen die niemand aan IT had gesteld: wat betekent 'omzet' in de ene organisatie en in de andere, wie is eigenaar van een klantrecord, welke van de twee productstructuren overleeft, en wie beslist dat? Niet het doelsysteem bepaalt het succes van een migratie, maar de definities en het eigenaarschap eromheen.
Waarom de IT-aanname faalt
Een integrator doet wat een integrator moet doen: velden mappen, transformaties bouwen, ladingen draaien. Dat werk is nodig en vaak uitstekend. Maar een integrator kan niet beslissen of een 'actief contract' in de overgenomen entiteit hetzelfde is als in de moedergroep. Die vraag is geen technische vraag, en ze komt pas boven wanneer de eerste reconciliatie niet klopt.
Dan begint het vertragen. Business en IT schuiven het probleem naar elkaar. De data-eigenaar blijkt niet benoemd, of het zijn er drie. Historiek wordt integraal meegenomen omdat niemand durft schrappen, waardoor de nieuwe omgeving start met dezelfde vervuiling als de oude. En omdat de deadline vastligt, wordt de kwaliteitscheck het eerste dat sneuvelt.
Het tweede probleem van de IT-aanname is de scope. Een overname raakt Finance, Sales en Operations tegelijk, en in elk domein leven andere definities. Wie de migratie per systeem organiseert in plaats van per beslissing, krijgt drie projecten die elk apart kloppen en samen niet.
Wat dan wel
Behandel de migratie als een beslissingstraject met een technische uitvoering, niet omgekeerd. Dat betekent concreet: begin met een definitieboek per domein, waarin je vastlegt wat de kernbegrippen betekenen na de migratie en wie daarover beslist. Benoem per datadomein één eigenaar uit de business, met mandaat. Bepaal welke historiek echt nodig is voor rapportering en compliance, en archiveer de rest buiten het doelsysteem.
Leg de reconciliatiecriteria vast vóór de eerste proeflading, niet erna. Als je op voorhand weet welke totalen aan beide kanten moeten kloppen, wordt elke testronde een meting in plaats van een discussie. En organiseer de regie over de domeinen heen: één plek waar Finance, Sales en Operations hun afhankelijkheden op tafel leggen, met een tempo dat door de business wordt gezet en door IT wordt uitgevoerd.
De rol van een onafhankelijk adviseur zit precies daar: niet in het bouwen van de koppelingen, maar in het bewaken dat de juiste vragen op tijd beantwoord worden en dat de uitvoering daaraan gebonden blijft. Advies zonder eigen software of implementatiebelang, zodat de keuze voor een doelsysteem een gevolg is van de definities en niet omgekeerd.
Plan daarnaast minstens drie proefladingen in plaats van één generale repetitie. De eerste toont waar definities botsen, de tweede of de correcties werken, de derde of de business ermee kan werken zonder handleiding. Tussen die rondes hoort een korte freeze op wijzigingen in de bronsystemen, anders vergelijk je elke keer een andere foto. Het kost weken op de planning en bespaart maanden na de livegang, omdat de fouten opduiken op het moment dat ze nog goedkoop zijn.
Zo verschuift de migratie van een technisch eindpunt naar een reeks beslissingen met een zichtbare eigenaar, en dat is precies wat een overname nodig heeft.
Praktijk
Een Belgische leasemaatschappij werd midden 2026 overgenomen door een internationale groep met eigen rapporteringsvereisten. De datamigraties in Finance, Sales en Operations moesten binnen enkele maanden landen, terwijl de dagelijkse werking gewoon doorliep. De grootste risico's zaten niet in de systemen, maar in de definities: twee betekenissen van omzet, twee productstructuren, twee manieren om een contract als actief te beschouwen.
De aanpak draaide daarom om regie en kwaliteitsbewaking over de drie domeinen heen: definities vastleggen, eigenaars benoemen, reconciliatiecriteria bepalen en de uitvoering door interne IT en leveranciers daaraan toetsen. Het project loopt nog, dus de eindbalans volgt later. Wat nu al zichtbaar is: de discussies gaan over cijfers die kloppen of niet kloppen, niet over wie waarvoor verantwoordelijk is.
Tot slot
Datamigratie is een verhaal van beslissingen die je vooraf neemt of achteraf betaalt. Wie het als IT-project bestempelt, koopt zich een demo op het einde en een reconciliatie die niet klopt. Niet het doelsysteem, maar de definities en het eigenaarschap eromheen maken het verschil.
Sta jij voor een migratie of integratie na een overname? Plan een diagnosegesprek met ideeds.
