Legacy software moderniseren

Legacy software is software waar een organisatie op draait, maar die ze nauwelijks nog kan veranderen. De leeftijd is niet het criterium. Een applicatie van vijftien jaar oud met goede tests en documentatie is geen probleem; een spreadsheet van drie jaar oud met macro's die niemand begrijpt, wel.

De signalen zijn meestal herkenbaar voor wie ermee werkt.

• Het platform krijgt geen beveiligingsupdates meer, of de leverancier bestaat niet meer.
• De enige persoon die het systeem kende, is vertrokken of met pensioen.
• Elke kleine wijziging kost weken, omdat niemand weet wat er verder door wordt geraakt.
• Het systeem kan geen gegevens uitwisselen met nieuwere pakketten, dus medewerkers tikken over.
• Een auditor of de functionaris gegevensbescherming stelt vragen die u niet kunt beantwoorden, zoals wie toegang heeft tot welke gegevens.

Legacy is niet automatisch slecht. Het systeem werkt, en vaak bevat het jaren aan bedrijfsregels die nergens anders zijn opgeschreven. Juist daarom is weggooien en opnieuw beginnen riskant: die regels moeten eerst worden teruggevonden. Modernisering betekent dat u de waarde behoudt en het risico verkleint, niet dat u alles vervangt.

Of modernisering nodig is, of dat een standaardpakket de functie kan overnemen, is een aparte afweging. Die staat in de kennisbank onder maatwerk of standaard software.

Deze dienst is bedoeld voor organisaties die afhankelijk zijn van een systeem dat ze niet meer goed kunnen onderhouden, en die het risico van een grote vervanging in één keer willen vermijden.

• Wel bij een Access-database of Excel-bestand waar meerdere mensen tegelijk in werken en waar het werk van stilvalt als het bestand stuk gaat.
• Wel bij een maatwerkapplicatie op een verouderd platform waarvan de broncode beschikbaar is.
• Wel als het oude systeem eerst moet kunnen koppelen met nieuwe pakketten, voordat het wordt vervangen.
• Wel bij een gesloten GIS-omgeving die naar open source moet; daarvoor is er een aparte aanpak bij van ArcGIS naar open source.
• Niet als er een standaardpakket is dat het proces goed dekt. Dan is migreren naar dat pakket meestal verstandiger dan moderniseren.
• Niet als de broncode niet beschikbaar is en de leverancier geen exportmogelijkheid biedt. Dan begint het traject met het terugkrijgen van uw gegevens, niet met bouwen.

Weet u nog niet welke kant het opgaat, dan is een onafhankelijke verkenning een goede eerste stap. Dat valt onder technologie- en softwareadvies.

Alles in één keer vervangen faalt vaak, omdat het oude gedrag lastiger te achterhalen is dan het lijkt en gebruikers niet jaren op nieuwe functies kunnen wachten. Martin Fowler, die de metafoor van de wurgvijg (strangler fig) voor deze aanpak introduceerde, beschrijft het plan om een nieuw systeem te bouwen dat precies doet wat het oude deed, en concludeert:

But we've seen this simple-sounding plan go down in flames most of the time.

Bron: Martin Fowler, Strangler Fig, gelezen op 11 oktober 2026. Fowler noemt als redenen dat vervanging lang duurt, dat de details van bestaand gedrag moeilijk te achterhalen zijn, en dat veel van dat gedrag eigenlijk niet meer gewenst is, zodat het nabouwen ervan verspilling is.

Het alternatief is geleidelijke modernisering. Net als de wurgvijg, die rond een boom groeit tot de boom niet meer nodig is, begint het nieuwe systeem met kleine toevoegingen naast het oude. Stukje bij beetje verhuist gedrag van het oude naar het nieuwe systeem, tot er niets meer over is om uit te zetten.

Het voordeel is dat elke stap klein genoeg is om terug te draaien. Gaat er iets mis met de nieuwe module voor facturatie, dan gaat het verkeer terug naar het oude systeem terwijl de fout wordt opgelost. Bij een vervanging in één keer bestaat die terugweg na de overstapdatum niet meer. Het nadeel is dat u een tijd twee systemen naast elkaar hebt, met een koppeling ertussen. Dat kost beheer, en daarom hoort bij elke stap een datum waarop het oude deel echt uitgaat.

Er is niet één aanpak voor alle situaties. De keuze hangt af van hoe het oude systeem is opgebouwd en hoeveel risico u kunt dragen.

In de praktijk worden patronen gecombineerd. Een veelvoorkomende volgorde is eerst een API rond het oude systeem, dan per functie de strangler fig, en bij de rekenkern parallel draaien. Hoe zo'n API wordt ontworpen en bewaakt, staat bij API-koppelingen.

U faseert Access en Excel uit door eerst de gegevens naar een echte database te verhuizen en pas daarna de schermen en rapporten te vervangen. Zo blijft het werk doorgaan tijdens de overstap.

Er zijn harde redenen om niet te lang te wachten. Volgens de Microsoft-lifecyclepagina kregen Access 2016 en Access 2019, net als Excel 2016 en 2019, na 14 oktober 2025 geen ondersteuning meer. Daarnaast hebben beide programma's grenzen die bij groei gaan knellen. Een Access-database mag volgens Microsoft in totaal 2 gigabyte groot zijn, minus de ruimte voor systeemobjecten. Een Excel-werkblad heeft maximaal 1.048.576 rijen bij 16.384 kolommen.

Een werkbare volgorde ziet er zo uit.

1. Inventariseren. Welke tabellen, query's, formulieren, macro's en VBA-code zijn er, en welke worden nog gebruikt? Vaak blijkt een groot deel overbodig.
2. Gegevens naar PostgreSQL. De tabellen gaan naar een server-database, met sleutels en controles die in het oude bestand ontbraken.
3. Access als tijdelijke voorkant. Access kan tabellen in een externe database koppelen via ODBC; Microsoft beschrijft dat voor SQL Server, en voor PostgreSQL bestaat het officiële stuurprogramma psqlODBC. Gebruikers werken dan in hun vertrouwde formulieren, terwijl de gegevens al veilig op de server staan.
4. Schermen vervangen. Per proces komt er een webscherm, beginnend bij wat het meest wordt gebruikt.
5. Uitzetten. Als het laatste formulier is vervangen, gaat het Access-bestand op alleen-lezen en daarna in het archief.

Komen er na de overstap vooral rapportagevragen, dan is een data warehouse voor het mkb het logische vervolg.

U controleert dat door oud en nieuw een periode naast elkaar te laten draaien en de uitkomsten automatisch te vergelijken. Dat heet reconciliatie. De vergelijking hieronder is op 11 oktober 2026 getest op PostgreSQL 14.19, met een fictief voorbeeld van drie facturen per systeem. De export uit het oude systeem staat in schema oud, de uitkomst van het nieuwe in schema nieuw.

select coalesce(o.factuurnr, n.factuurnr) as factuurnr,
       o.bedrag as oud, n.bedrag as nieuw,
       case when o.factuurnr is null then 'alleen in nieuw'
            when n.factuurnr is null then 'alleen in oud'
            else 'bedrag wijkt af' end as verschil
from oud.facturen o
full outer join nieuw.facturen n using (factuurnr)
where o.bedrag is distinct from n.bedrag
order by 1;

Uitvoer:

 factuurnr |  oud   | nieuw  |    verschil
-----------+--------+--------+-----------------
 F-002     | 250.00 | 205.00 | bedrag wijkt af
 F-003     |  80.00 |        | alleen in oud
 F-004     |        |  60.00 | alleen in nieuw
(3 rows)

De full outer join laat ook records zien die in maar één systeem bestaan, en is distinct from behandelt een ontbrekend bedrag als verschil in plaats van het weg te filteren. Factuur F-001, die in beide systemen gelijk is, verschijnt niet.

Elk verschil krijgt een verklaring. Soms is het nieuwe systeem fout, soms blijkt het oude al jaren verkeerd te rekenen. Dat laatste is een beslissing voor de proceseigenaar, niet voor de ontwikkelaar. Pas als de lijst een afgesproken periode leeg blijft, gaat het oude deel uit.

Bij modernisering gaat het om meer dan code. U mag drie dingen niet verliezen, namelijk de gegevens, de bedrijfsregels en het bewijs van wat er in het verleden is gebeurd.

Gegevens. Alles wat het nieuwe systeem nodig heeft, wordt gemigreerd met een controle op aantallen en totalen. Wat het niet nodig heeft maar wel bewaard moet blijven, gaat naar een archief in een open formaat, zoals CSV of een database-dump, met een beschrijving van elk veld. Welke bewaartermijnen gelden, bepaalt u met uw archivaris of privacyfunctionaris; die regels verschillen per soort gegeven.

Bedrijfsregels. De logica in macro's, query's en oude code wordt opgeschreven in gewone taal en vastgelegd als geautomatiseerde test in het nieuwe systeem. Zo is de kennis niet langer afhankelijk van één persoon.

Toegang en logging. Leg vast wie in het oude systeem welke rechten had en zorg dat het nieuwe systeem die rechten bewust overneemt, niet automatisch. Een modernisering is een goed moment om rechten op te ruimen.

Zorg ook dat u niet opnieuw vast komt te zitten. Broncode in uw eigen repository, een gegevensexport in een open formaat en documentatie voor overdracht horen bij de oplevering. Meer daarover staat bij vendor lock-in en exitstrategie.

Een moderniseringstraject begint met begrijpen wat het oude systeem doet, niet met kiezen wat het nieuwe wordt.

1. Opname. Wie gebruikt het systeem, waarvoor, en welke koppelingen en exports bestaan er? We kijken in de code of het bestand en praten met de gebruikers die de uitzonderingen kennen.
2. Doelbeeld en volgorde. Welk patroon past per onderdeel, in welke volgorde, en wanneer gaat elk oud deel uit?
3. Eerste stap met terugweg. Het kleinste onderdeel dat echte waarde oplevert, met de mogelijkheid om terug te schakelen.
4. Parallel draaien en vergelijken. Reconciliatie tot de verschillen verklaard zijn.
5. Uitzetten en archiveren. Het oude deel gaat uit, de gegevens gaan naar het archief.
6. Herhalen. Per onderdeel, tot er niets meer over is.

Hoe lang dit duurt, hangt af van de omvang en van wat de opname oplevert. Daarom volgt een planning pas na die opname. De nieuwe onderdelen worden gebouwd als maatwerk software met tests en documentatie, of, waar dat beter past, als webapplicatie. Het werk wordt uitgevoerd door oprichter Tekin Uslu; eerder werk van de oprichter is geen referentie van TechinFlow B.V.