Sommige systemen doen jarenlang stilletjes hun werk. Niemand heeft er echt een mening over, zolang alles het maar doet. Totdat je ineens hoort: “Die serverversie mag straks niet meer in het netwerk.”
Dat was precies wat er bij een klant speelde. In een oud programma stonden alle meetgegevens. Veel data, vaak nodig. En volgens afspraak moesten ze die informatie nog drie jaar kunnen terugvinden. Alleen draaide het geheel op een oude Windows Server die op korte termijn niet meer mee mocht draaien.
En dan krijg je die ene vraag die iedereen herkent:
"Wat als dit ding ermee ophoudt… en we kunnen nergens meer bij?" Om risico’s te beperken werd de server losgekoppeld. Beheerders konden er nog via RDP in, maar voor de rest van de organisatie werd het gedoe. De data was er nog wel, maar praktisch gezien zat het achter glas.
“Dan zetten we het toch gewoon over?”
Dat was ook de eerste gedachte. De klant stapte over op een modern pakket, maar de oude data kon daar niet netjes in. Geen import. Geen koppeling. De database was zó oud dat “even verbinden” geen realistische route was.
Wat wel kon: exporteren naar tekstbestanden (CSV). Alleen… wie ooit met dit soort exports heeft gewerkt, weet dat het zelden een keurige tabel is. Datums die in drie smaken komen. Velden die soms leeg zijn, soms half gevuld. Extra tekens die je niet kunt verklaren (“Waarom staat hier ineens een raar karakter?”). Dingen die pas opvallen als iemand er echt op gaat zoeken.
Eerst zorgen dat mensen weer verder kunnen
We hebben vrij snel afgesproken waar het om moest draaien: niet om een perfecte datamigratie, maar om iets heel praktisch.
Mensen moesten weer:
- meetgegevens kunnen terugvinden zonder omwegen
- veilig kunnen werken (met rechten die kloppen)
- en niet eindigen met een archief dat duur of lastig te beheren is
En ja: het moest ook gewoon op tijd af.
Niet gokken wat belangrijk is
Wij kennen de betekenis van die meetvelden niet zoals de klant dat doet. En precies daar gaat het vaak mis bij automatisering: er wordt gebouwd op aannames.
Dus we hebben het archief stap voor stap gemaakt. Niet “alles in één keer”, maar per scherm/onderdeel. En na elke stap even kort afstemmen:
Zoeken jullie hierop? Mis je iets? Is dit te veel? Is dit precies genoeg?
Dat waren geen zware overleggen. Meer: samen even kijken of het klopt. Het effect daarvan was groot. Je voorkomt dat je weken netjes zit te bouwen aan iets wat in de praktijk net niet werkt.
En die rommelige CSV’s?
Voor het opschonen hebben we Microsoft Fabric gebruikt. Dat ving veel af. Maar eerlijk is eerlijk: niet alles. Er bleven een paar hardnekkige fouten over die óf zoekresultaten onbetrouwbaar maakten, of risico’s gaven op verlies van data.
Op dat punt hebben we een paar dingen handmatig rechtgetrokken, omdat het de snelste route was naar: dit werkt, en we kunnen erop vertrouwen.
Wat dit soort trajecten meestal lastig maakt
Als ik er één ding uit moet halen: een nieuw systeem kiezen is vaak het makkelijke deel. Het lastige deel is het netjes achterlaten van het oude systeem, zónder dat je werk stilvalt.
En bijna altijd geldt:
- oude data is zelden netjes
- “export” betekent vaak: eerst opruimen
- afstemmen met gebruikers bespaart je uiteindelijk tijd (en frustratie)
- en een archief moet vooral geen nieuwe hobby van IT worden
Waar het op uitkwam
Aan het eind stond er een archief waar de klant de komende jaren mee vooruit kan:
gegevens zijn terug te vinden en het geheel hangt niet meer aan een oude server in een hoekje.
