Datamigratie naar een nieuw systeem

In een planning staat datamigratie meestal als één regel: bestaande gegevens overzetten. Technisch klopt dat ongeveer: lezen uit het ene systeem en schrijven in het andere is routinewerk. Het lastige zit elders: het oude systeem accepteerde jarenlang wat gebruikers erin typten, en het nieuwe doet dat niet.

Elk systeem heeft regels over verplichte velden, toegestane waarden en verwijzingen die moeten kloppen. Een systeem dat jaren draait heeft die regels opgerekt. Bij een migratie botsen beide sets in één keer op elkaar, en het foutenrapport dat daaruit rolt is geen technisch probleem: het is een inventarisatie van beslissingen die ooit onder tijdsdruk zijn genomen. Daarom lopen migraties uit. Elke afgekeurde regel vraagt om iemand die weet wat de bedoeling was.

Dubbelen die niemand als dubbel zag

"Jansen Transport", "Jansen Transport B.V." en "jansen transport bv" zijn voor een medewerker één klant en voor het systeem drie. Aan alle drie hangen facturen en openstaande posten. Samenvoegen is een inhoudelijke keuze, geen technische.

Verplichte velden die leeg zijn

Ooit typte iemand een spatie of "n.v.t." om het scherm te kunnen opslaan. Dat werd gewoonte. Het nieuwe systeem behandelt zo'n waarde als echt: het filtert erop of rekent ermee.

Vier notaties voor hetzelfde gegeven

Telefoonnummers met en zonder landcode, soms twee in één veld. Datums die als tekst zijn ingevoerd, waardoor 03-04 in het ene record maart is en in het andere april. Voor elke variant bepaalt iemand wat de juiste lezing is.

Velden die iets anders zijn gaan betekenen

Het opmerkingenveld waarin de ene afdeling leveringsafspraken zet en de andere interne notities. Er is geen nieuw veld dat beide betekenissen dekt, dus splitsen kan alleen op inhoud.

Records die volgens de nieuwe regels niet kunnen bestaan

Een order zonder klant, een factuur bij een verwijderde relatie, een medewerker op een opgeheven afdeling. Het oude systeem liet die wezen staan. Het nieuwe weigert ze, en daarmee valt er historie uit die wel in de omzetcijfers zit.

De reflex is om alles mee te nemen. Dat voelt veilig, maar het is de duurste route: alles wat meegaat moet vertaald, geladen en gecontroleerd worden, en daarna betaalt u ervoor in opslag en licentievormen die met volume werken. Bovendien verhuist de rommel mee naar een systeem dat er net zo veel last van heeft.

Een bruikbare driedeling is deze. Wat morgen gebruikt wordt gaat mee en moet kloppen: lopende relaties, open orders, actuele contracten, saldi. Fouten daarin komen meteen aan het licht in het dagelijkse werk, dus daar gaat het controlewerk naartoe. Historie hoeft zelden mee te draaien maar moet wel opvraagbaar blijven, als export in een leesbaar formaat, als omgeving die alleen te raadplegen is, of via een koppeling die de historie op verzoek ophaalt. De rest laat u los.

Die driedeling is inhoudelijk werk, geen technische afweging, en hoort vroeg thuis in het programma van eisen. Wie hem uitstelt tot vlak voor de overgang neemt hem niet meer: dan gaat alles mee, bij gebrek aan tijd om te kiezen.

Bij persoonsgegevens speelt nog iets anders: sommige gegevens moet u bewaren, andere mag u niet langer bewaren dan nodig is. In de AVG staat geen concrete bewaartermijn. Organisaties bepalen die zelf en moeten kunnen onderbouwen waarom. Concrete termijnen staan wel in andere wetten, bijvoorbeeld in belastingwetgeving en de Archiefwet. De Autoriteit Persoonsgegevens beschrijft die systematiek in haar uitleg over het bewaren van persoonsgegevens.

Een migratie is het natuurlijke moment om dit op te ruimen, want u loopt alle categorieën toch al langs. Het omgekeerde gebeurt vaker: alles gaat voor de zekerheid mee, naar een systeem waar niemand meer weet waar het vandaan komt.

Welke termijnen in uw situatie gelden hangt af van uw sector en het soort gegevens. Dit is algemene uitleg en geen juridisch advies: laat de keuzes toetsen door een jurist of uw functionaris gegevensbescherming.

1. Kijk wat er werkelijk in staat

   Niet wat de documentatie beweert, maar wat er feitelijk in staat: welke velden echt gevuld zijn en welke al jaren leeg.

2. Leg de vertaling per veld vast

   Waar komt een waarde vandaan, waar gaat hij heen, en wat gebeurt er als hij niet past. Dat laatste is het echte document.

3. Draai de eerste proefmigratie op een kopie

   De volledige set door de conversie in een testomgeving. Deze eerste ronde is vooral een inventarisatie van alles wat er niet doorheen komt.

4. Controleer met steekproeven én met totalen

   Steekproeven laten zien of individuele records kloppen, totalen of er niets is weggevallen of dubbel geland: aantallen per soort, openstaande saldi, sommen per periode. Kloppen de aantallen wel en de saldi niet, dan zit de fout in de bedragen; andersom zijn er records samengevoegd.

5. Repareer aan de bron

   Wat u alleen in de conversie wegpoetst, moet u elke ronde opnieuw wegpoetsen. Corrigeer in het oude systeem; de tweede proefronde meet dan of dat opschonen werkte.

6. Houd een generale repetitie in de echte volgorde

   Dezelfde scripts, dezelfde volgorde, dezelfde mensen, inclusief dichtzetten, exporteren, laden en vrijgeven. Nu meet u het draaiboek: past het in het venster dat u heeft, en wanneer besluit u terug te draaien.

Zolang het oude systeem in gebruik is, verandert de data terwijl u hem overzet. Elke order, adreswijziging en betaling die binnenkomt tussen het exporteren en het vrijgeven staat straks alleen in het oude systeem. Daar zijn drie antwoorden op.

Beide systemen bijhouden klinkt het netst en is in de praktijk het duurst: mensen vergeten het of doen het net iets anders, en achteraf kan niemand vaststellen welke versie de juiste is. Alleen de mutaties nalopen na de export werkt, mits het oude systeem betrouwbaar registreert wanneer een record gewijzigd is, en dat is lang niet altijd zo. Blijft over: een korte periode waarin niemand muteert en het oude systeem alleen te lezen is.

Die bevriezing voelt het meest ingrijpend en is meestal de goedkoopste. U betaalt een afgebakend ongemak in plaats van een nasleep waarvan de omvang pas later blijkt. Voorwaarde is dat iedereen weet wanneer het ingaat en wat er dan wel mag.

Een bouwende partij kan gegevens uitlezen, vertalen en inladen, en zien dat er technisch niets is weggevallen. Wat die partij niet kan, is beoordelen of "Jansen Transport" en "Jansen Transport B.V." dezelfde klant zijn, of een oud contract nog loopt, of het saldo van deze debiteur klopt. Dat weten alleen de mensen die dagelijks met die gegevens werken.

Dit is de meest onderschatte inspanning aan opdrachtgeverskant, en hij valt bij de mensen die het al druk hebben: de administratie, de planning, de accountmanagers. Wijs per gegevenssoort iemand aan die de knopen doorhakt en plan hun tijd in als de bouwuren. Reken erop dat de eerste periode na de overgang correctiewerk oplevert; leg vast bij wie dat hoort, in de afspraken over het beheer van de nieuwe software.

Nog iets dat zelden hardop wordt gezegd: datamigratie ontbreekt structureel in offertes, of staat er als losse post zonder inhoud. Dat is voor beide partijen comfortabel: de aanbieder houdt het bedrag laag, en u ziet geen post waarvan niemand de omvang kent. Daarmee is het een van de grootste bronnen van meerwerk. Vraag er expliciet naar: hoeveel proefrondes zitten erin, wie schrijft de vertaling per veld, wie doet de controle, en wat gebeurt er als de data slechter blijkt dan aangenomen. Een kleine proefconversie op echte gegevens verandert die aanname in een waarneming.

• Een programma van eisen schrijven
• Systemen koppelen met een API
• Software in beheer nemen
• Een oud systeem uitfaseren