Antwoord.

In de geschiedenis van de IT-ervaring wereldwijd zijn taken met gegevensmigratie vaak de bron geweest van onverwachte storingen: vervorming, verlies of duplicatie van informatie, vooral in grote, uiteenlopende informatiecontouren (bijvoorbeeld bij de overgang van monolithisch naar microservices of van legacy-platforms naar moderne oplossingen).

Het probleem ligt in het gebrek aan een gestandaardiseerde opvatting over migratie: opdrachtgevers of ontwikkelaars beschouwen deze taak vaak alleen als technisch, zonder de risico's voor bedrijfsprocessen te evalueren en scenario's voor randgevallen uit te werken (ongelijksoortige dataformaten, structuren, het verlies van eenmalige bedrijfsregels in het oude systeem).

De oplossing ligt in een systematische aanpak:

Volledige inventarisatie van datamodellen, inclusief niet-voor de hand liggende verbanden en bedrijfsregels.
Ontwikkeling van gedetailleerde migratiescenario's: wat er gebeurt met historische, niet-actuele, substantieve en gefragmenteerde gegevens.
Duidelijke opname van migratievereisten in de documentatie, inclusief de volgorde van laden, manieren van terugdraaien, en controles op volledigheid en juistheid van de overdracht.
Vastlegging van risicogebieden: wat niet wordt overgedragen, waarom, en hoe dit wordt gedocumenteerd.

Belangrijke kenmerken:

Noodzaak van nauwe communicatie tussen de businessanalist, architect en DBA.
Altijd een validatiefase voor migratie toevoegen (bijvoorbeeld selectieve replicatie en daaropvolgende audit).
Fasering (stap-voor-stap) documentatie: wat volledig wordt overgedragen, wat gedeeltelijk, en wat handmatige arbeid vereist.

Misleidende vragen.

Is het mogelijk om gegevensmigratie uit te voeren zonder de betrokkenheid van bedrijfsafdelingen als 'alles in de database staat'?

Nee, zonder de betrokkenheid van de business is het onmogelijkheid om de validiteit, kritiek en actualiteit van gegevens te bepalen. Oude bedrijfsregels, zelfs als ze niet formeel zijn beschreven, kunnen invloed hebben op de levenscyclus van informatie.

Is het noodzakelijk om alle velden uit het oude datamodel in het nieuwe systeem te behouden?

Niet altijd: sommige velden kunnen overbodig zijn of hun betekenis hebben verloren. Deze beslissing moet echter worden goedgekeurd en vastgelegd in de documentatie, anders ontstaat er een risico op inconsistentie in de bedrijfsprocessen.

Is het mogelijk om alleen 'verse' gegevens te migreren?

Dit hangt af van de zakelijke vereisten. Vaak zijn historische gegevens nodig voor rapportage, compliance of audit. Selectieve migratie zonder overeenstemming creëert risico's voor juridische of operationele informatie.

Typische fouten en anti-patronen

Ontbreken van specificatie voor gegevenstransformatie (welke velden worden omgezet en hoe).
Het overslaan van attributen die invloed hebben op downstream-processen.
Het negeren van de behoefte aan retests en audit-tracering van migraties.

Voorbeeld uit het leven

Negatieve case: Een bank schakelde over naar een nieuw CRM-systeem; analisten legden de verbanden tussen de woonplaats van de klant en regionale belastingvoordelen niet vast. Dit leidde tot fouten in de bonusberekeningen.

Voordelen:

Snelle implementatie van de oplossing.

Nadelen:

Tienduizenden compensatiebetalingen aan klanten.
Juridische risico's en verlies van klantvertrouwen.

Positieve case: Voor de migratie creëerden analisten een gedetailleerde kaart van attributen, voerden ze een pilotselectie en gegevensextractie uit, testten ze de nauwkeurigheid van elke transactie op willekeurige klanten, en stemden ze alle scenario's af met de business en de auditors.