RBI-Solutions blog

Data migratie test en validatiestrategieën: hoe je zeker weet dat je data klopt na een migratie

Data migraties zijn voor veel organisaties een uitdaging: je stapt over van een oud systeem naar een nieuw, je moderniseert je datawarehouse of je integreert een nieuw platform na een fusie. Ondanks dat het technisch ‘slechts’ het verplaatsen van data lijkt, komt er meer bij kijken om een goede datamigratie uit te voeren. Hoe weet je zeker dat de data na migratie nog klopt? Dat er niets verloren is gegaan, of erger nog: dat je geen subtiele fouten hebt geïntroduceerd die maanden later pas boven water komen? In deze blog staan we stil bij test- en validatiestrategieën bij data migraties. We bespreken waarom het testen van een datamigratie fundamenteel anders is dan het testen van een standaard applicatie, welke technieken je kunt gebruiken om betrouwbaarheid te garanderen, en hoe je omgaat met de praktische uitdagingen die je onderweg tegenkomt.

Waarom data migratie testen zo kritisch (en lastig) is
Een datamigratie is in principe een grote kopieeractie. Maar anders dan een simpele copy-paste in je bestandsbeheer, zijn de datasets vaak groot, complex en dynamisch. Denk aan historische datasets van miljoenen rijen, relationele structuren over tientallen tabellen, of transformatielogica die tussen systemen verschilt. Voeg daaraan toe dat bronsystemen soms nog in productie zijn tijdens de migratie (en dus blijven veranderen), of dat datatypes niet één-op-één overeenkomen. De kans op fouten ligt op de loer.

En dan is er nog iets: de verwachte uitkomst van een migratie is meestal “geen verschil”. Maar dat maakt het testen niet makkelijker. Je moet dus aantonen dat niets veranderd is, of alleen dat wat expliciet gewenst was. Dat vraagt om een andere manier van denken dan bij het testen van nieuwe functionaliteit.

Validatiestrategieën: van row counts tot checksums
Laten we eens kijken naar de tools in de gereedschapskist van een data engineer. Hoe test je dat de gemigreerde data klopt? Er zijn verschillende lagen waarop je kunt valideren, en het loont om die gelaagd aan te pakken.

Een veelgebruikte eerste stap is het vergelijken van row counts per tabel. Het is simpel en snel te automatiseren, en geeft een goede eerste sanity check: als je bron 80 miljoen rijen heeft en je doel ook, dan is dat alvast geruststellend. Maar het zegt natuurlijk niets over de inhoud. Daarom komt daarna vaak kolom-voor-kolom vergelijking in beeld. Tools als dbt, Great Expectations, Deequ of custom Python scripts kunnen rijen uit de bron en het doel vergelijken. Checksums per rij zijn hier handig: je maakt bijvoorbeeld een SHA-256 hash van alle relevante kolomwaarden, en vergelijkt die tussen bron en doel. Als de hash verschilt, is er ergens iets mis.

Een stap verder is het uitvoeren van inhoudelijke validaties: business rules die in de data moeten gelden. Denk aan: ‘het totaal van kolom A moet gelijk zijn aan het totaal van kolom B, of ‘er mogen geen negatieve bedragen voorkomen in kolom C’. Zulke regels zijn essentieel om ook semantische fouten op te sporen, bijvoorbeeld wanneer een valutaconversie verkeerd is gegaan.

Tot slot kun je ook steekproeven inzetten. Soms is het simpelweg niet haalbaar om alles te vergelijken. In dat geval kan een representatieve sample veel inzicht geven. Dit soort checks worden vaak handmatig gedaan door data analisten of business users, bijvoorbeeld via dashboards of gebruikersanalyses.

Typische valkuilen en hoe je ze omzeilt
Een veelvoorkomende fout is dat men pas na de migratie begint met testen. Je kunt echter veel eerder beginnen met het opzetten van teststrategieën, idealiter al tijdens de analysefase. Inventariseer welke datavelden complex zijn, welke tabellen kritisch zijn, en waar historische issues hebben gespeeld. Zet pilots of proefmigraties op en laat daar je testlogica op los. Zo voorkom je verrassingen op het eind.

Een andere valkuil is het overschatten van tools. Een tool als Great Expectations is krachtig, maar lost het probleem niet voor je op. Je moet zelf nog steeds goed nadenken over wat je wilt testen, waarom, en wat de acceptatiecriteria zijn. Technologie ondersteunt, maar de teststrategie komt uit je hoofd (en uit overleg met de business).

Ook belangrijk: vergeet de context van je data niet. Een veelgemaakte fout is het vergelijken van bijvoorbeeld datums of bedragen zonder rekening te houden met timezoneconversies, precisieverschillen of defaultwaarden die per systeem verschillen. Data kan er op het eerste gezicht hetzelfde uitzien, maar onder de motorkap net anders worden geïnterpreteerd.

Trends en ontwikkelingen: automatisering en data contracts
Steeds meer organisaties zetten in op geautomatiseerde data tests als onderdeel van hun CI/CD pipelines. Bij elke nieuwe batch of release draait er automatisch een test-suite die validatiechecks uitvoert op gemigreerde of vernieuwde datasets. Tools als dbt zijn hierin leidend, zeker in combinatie met moderne data stacks rond Airflow, Fivetran en Snowflake.

Een opkomende trend is het gebruik van data contracts: expliciete afspraken tussen producers en consumers van data over structuur, semantiek en validaties. Dit maakt het makkelijker om vooraf al duidelijke testcriteria vast te leggen, en fouten vroeg te detecteren. Denk bijvoorbeeld aan een JSON-schema dat beschrijft wat een dataset moet bevatten, inclusief toegestane waarden en datatypes. Zo’n contract kan vervolgens automatisch gevalideerd worden tijdens de migratie.

Tot slot: testen is geen sluitpost, maar fundament
Een succesvolle datamigratie hangt niet alleen af van een goede technische uitvoering, maar van grondige, doordachte validatie. En dat vraagt om meer dan alleen een paar queries achteraf. Het vraagt om een strategie: een combinatie van kwantitatieve checks, inhoudelijke validaties, samenwerking met de business én slimme automatisering.

Door je teststrategie op te bouwen vanaf het begin van het migratietraject, voorkom je dure hersteloperaties achteraf. En misschien nog wel belangrijker: je bouwt vertrouwen op. In je data, in het nieuwe systeem, en in de mensen die ermee werken.

Data migreren is mensenwerk, maar testen maakt het betrouwbaar!

Lees verder over data en de diensten van RBI-Solutions in deze blog's:

AI Agents: meer dan een slimmere chatbot

AI Agents: meer dan een slimmere chatbot

De meeste mensen zien AI nog steeds als een soort papegaai die tekstjes en plaatjes maakt zodra je iets vraagt. Handig, maar ook best oppervlakkig. Sinds enige tijd is er echter ook iets nieuws in opkomst: ‘Agentic AI’. AI-agenten dus die autonoom te werk kunnen gaan.

In plaats van pure generatie, kunnen ze een probleem ontleden, stappen zetten richting een oplossing, hun eigen werk checken en zelf andere tools gebruiken. We stappen dus richting zelfstandig werkende oplossingen. Je kunt het bijna zien als een leger van volledig virtuele assistenten en stagiaires. Dit belooft veel maar, brengt zeker ook gevaren.

AutoML: Machine Learning op de automatische piloot?

AutoML: Machine Learning op de automatische piloot?

Geautomatiseerd Machine Learning ook wel ‘AutoML’ is het automatiseren van de tijdrovende, iteratieve taken bij het ontwikkelen van machine learning-modellen. Je laat als het ware het bouwen van de modellen aan de machines zelf over.

Voor een paar tientjes een model dat kan voorspellen welke klanten over een paar maanden gaan vertrekken. Klinkt een beetje te goed om waar te zijn. Dan heb je natuurlijk ook geen Data Scientists meer nodig, toch? Nou, er zitten uiteraard wel wat haken en ogen aan. De specialisten op het gebied van Machine Learning verdwijnen ook zeker niet zo maar. Even een stap terug dus.

Data mesh: principes en praktische implementatie

Data mesh: principes en praktische implementatie

Elk relatief groot bedrijf bestaat uit verschillende afdelingen, elk met zijn eigen vraagstukken. Op datagebied is dat niet anders: marketing wil weten hoe campagnes performen, operations wil de huidige voorraad kunnen inzien, finance bewaakt de cashflow en productontwikkeling volgt klantgedrag.

Datamigratie afgerond… en nu?

Datamigratie afgerond… en nu?

Binnen veel organisaties is een datamigratie een enorme mijlpaal. Maandenlang werk je toe naar dat ene moment waarop alle data succesvol is overgezet naar de nieuwe operationele applicatie. Tijdens dat migratietraject worden allerlei controles ingericht: validatieregels, datakwaliteits­checks en integriteitscontroles die ervoor zorgen dat iedere klant, transactie of productrecord correct wordt overgezet. In de praktijk zien we alleen dat die regels direct na de migratie verdwijnen uit beeld. Terwijl ze juist ook dan van grote waarde zijn.

Meggie over haar werk bij de klant

Meggie over haar werk bij de klant

Meggie van den Boom, data engineer bij RBI Solutions, werkt al anderhalf jaar als data consultant bij een financiële dienstverlener. Ze geeft ons vandaag een kijkje in hoe haar werkzaamheden binnen haar team bij de klant eruit zien.

Metadata: je geheime wapen voor observability & governance

Metadata: je geheime wapen voor observability & governance

Metadata voor observability en governance: verder dan information_schema
Een aantal weken geleden, wijdden we een blog aan het gebruik van metadata voor het slimmer ontwikkelen en onderhouden van dataplatforms. Metadata wordt helaas nog vaak gezien als het saaie bijproduct van data: een paar kolomnamen, datatypes en misschien een timestamp, maar in moderne dataplatformen is dat nog maar het topje van de ijsberg. Metadata kan, mits goed benut, een krachtig fundament vormen voor zowel observability als governance. Het kan helpen bij het opsporen van problemen, het begrijpen van datastromen, het garanderen van compliance en zelfs het optimaliseren van prestaties.

Waarom AI en automatisering niet werken zonder goede data engineering

Waarom AI en automatisering niet werken zonder goede data engineering

AI is hot. Iedereen wil er iets mee. Van slimme voorspellingen tot volledige automatisering van bedrijfsprocessen; organisaties investeren massaal in artificial intelligence. Maar wie verder kijkt dan de hype, ziet dat veel AI-projecten stranden nog voordat ze echt waarde opleveren. Niet vanwege de modellen of de tooling, maar vanwege iets veel fundamentelers: de onderliggende data en hoe je ermee omgaat. Of specifieker: de data engineering erachter. Want zonder robuuste data-infrastructuur is AI net zo betrouwbaar als een kompas in een magneetveld. 

Data-APK: inzicht en zekerheid voor jouw bedrijfsdata

Data-APK: inzicht en zekerheid voor jouw bedrijfsdata

In een tijd waarin beslissingen steeds meer op data leunen, is het essentieel om zeker te weten dat die data klopt. Net als een auto die regelmatig een APK nodig heeft om veilig te blijven rijden, vraagt ook jouw bedrijfsdata om een periodieke check. Bij RBI Solutions noemen we dat de Data-APK: een slimme, laagdrempelige manier om jouw data in kaart te brengen, problemen te signaleren en waardevolle inzichten te bieden die jouw organisatie helpen sneller en beter beslissingen te nemen.

de transitie met Microsoft Fabric

de transitie met Microsoft Fabric

In veel MKB-organisaties is het verzamelen en rapporteren van data nog steeds een tijdrovende en foutgevoelige klus. Excel-bestanden circuleren overal, gegevens worden handmatig gecorrigeerd in verschillende systemen en rapportages worden met de hand bijgewerkt. Het gevolg is dat managers en analisten vaak worstelen met verouderde inzichten, inconsistente cijfers en een gebrek aan overzicht. Hierdoor duurt het langer voordat er goede beslissingen genomen kunnen worden en het vertrouwen in de data neemt af.

Een bekend probleem is dat data uit verschillende systemen, zoals een boekhoudpakket, CRM of HR-software, niet automatisch met elkaar verbonden zijn. Dit leidt tot dubbel werk, handmatige controles en fouten bij het overzetten van data. Denk bijvoorbeeld aan het handmatig aanpassen van uitzonderingen in BTW-tarieven of het dubbel moeten invoeren van klantgegevens. Deze werkwijze kost veel tijd en brengt risico’s met zich mee.

Metagegevens als motor: hoe gebruik van information_schema je dataplatform slimmer kan maken

Metagegevens als motor: hoe gebruik van information_schema je dataplatform slimmer kan maken

Hopelijk weet iedereen die met databases werkt van het bestaan van standaard metagegevens waarmee er gemakkelijk inzicht verkregen kan worden over de structuur, data en opzet van de database. Ook voor dataplatforms zijn deze objecten enorm waardevol. Toch wordt het potentieel van metagegevens nog vaak onderschat, terwijl vrijwel elke (moderne) relationele database, van PostgreSQL tot Snowflake, een krachtig en vaak onderbenut startpunt biedt in de vorm van information_schema.

In deze blog duiken we dieper in hoe metagegevens via information_schema je dataplatform slimmer, transparanter en beheersbaarder maken. Voor zowel data engineers die pipelines bouwen, als analisten die vertrouwen op stabiele datasets, bieden deze metagegevens enorme voordelen. Van automatisch documenteren tot het voorkomen van incidenten: wie information_schema goed gebruikt, bouwt een robuuster platform.

Van tijd naar trigger: De weg naar een event-driven data architectuur

Van tijd naar trigger: De weg naar een event-driven data architectuur

Sinds het begin van het gebruik van Business Intelligence hebben organisaties vertrouwd op periodieke dataverwerking, de zogenaamde ’batch jobs’ die elke nacht draaien. Sindsdien is de behoefte aan snelheid, flexibiliteit en realtime inzichten enorm toegenomen. Die behoefte zorgt dan ook voor een fundamentele verschuiving in hoe we data-architecturen ontwerpen: weg van batch processen, op weg naar een event-driven benadering.

Maar wat betekent dat eigenlijk: ’event-driven’? En waarom zou je hier als data engineer, analist, data scientist of business gebruiker wakker van moeten liggen? In deze blog duiken we in de wereld van event-driven data-architecturen, hun voordelen, uitdagingen, en de tools die deze transitie mogelijk maken.

DataOps, DevOps en MLOps: Oude wijn in nieuwe zakken of écht anders?

DataOps, DevOps en MLOps: Oude wijn in nieuwe zakken of écht anders?

In een data gedreven organisatie vliegen de samenwerkingstermen je om de oren: DevOps, DataOps, MLOps. Deze drie termen, die inderdaad erg hetzelfde klinken (en door sommige organisaties ingevuld worden door een beheerder in een ontwikkelteam te zetten), verschillen in de praktijk aanzienlijk in toepassing, focus en doel. Voor wie dagelijks werkt met data of systemen die op data drijven, is het essentieel om deze termen niet alleen te kennen, maar ook te begrijpen wat ze betekenen en hoe ze zich tot elkaar verhouden. Daar nemen we jullie in deze blog dan ook in mee.