Je bedrijf draait op een systeem dat niemand meer durft aan te raken, en toch moet het ooit vervangen. In dit artikel lees je hoe je legacy software moderniseert zonder dat je bedrijf één dag stilligt: gefaseerd, met datamigratie in proefrondes en het oude systeem als vangnet.
Plan een kennismakingLegacy software is software die nog dagelijks gebruikt wordt, maar technisch is vastgelopen: de onderliggende techniek wordt niet meer ondersteund, de kennis is verdwenen en niemand durft er nog iets aan te veranderen.
De term klinkt abstract, maar je herkent het meteen: de Access-database die ooit "tijdelijk" was, het Delphi-programma uit de jaren 2000, het maatwerkpakket van een bouwer die niet meer reageert. Het werkt nog (nét), maar het houdt je bedrijf steeds vaker tegen.
Legacy software moderniseren betekent niet automatisch alles weggooien. Soms volstaat een koppeling of een nieuwe schil eromheen; vaak is gefaseerd vervangen de verstandigste route. In dit artikel lees je hoe dat werkt: welke risico's je nu loopt, waarom een big bang bijna altijd misgaat, en hoe de strangler-aanpak, datamigratie en parallel draaien je bedrijf in bedrijf houden.
Wil je direct weten hoe wij dit als bureau aanpakken? Bekijk dan de dienstpagina verouderde software vervangen.
De grootste risico's van oud maatwerk zijn afhankelijkheid van één persoon of machine, het ontbreken van beveiligingsupdates en een systeem dat elke verandering in je bedrijf blokkeert. Het sluipende risico is misschien wel het grootste: elk jaar uitstel maakt vervangen moeilijker en duurder.
Vaak kent maar één persoon het systeem écht: de oorspronkelijke bouwer, of die ene collega die er al twintig jaar mee werkt. Valt die weg, dan staat er niemand klaar. Hetzelfde geldt voor de techniek: draait de applicatie op één pc of server op kantoor, dan is dat ene apparaat je hele bedrijfsvoering.
Oude software draait op techniek die geen beveiligingsupdates meer krijgt, terwijl er wél klant- en personeelsgegevens in staan. Dat is lastig te verenigen met de AVG. Ook praktisch wringt het: updates van Windows of de server worden uitgesteld uit angst dat het systeem daarna niet meer start.
Koppelen met je boekhouding lukt niet, dus wordt er overgetypt, met fouten als gevolg. Thuiswerken of een tweede vestiging kan niet, want het systeem draait alleen op kantoor. Nieuwe diensten of werkprocessen passen er niet in, dus blijven ze liggen. Het systeem bepaalt wat je bedrijf kan, in plaats van andersom.
Een big bang (op vrijdag het oude systeem uit, op maandag het nieuwe aan) mislukt vaak omdat alle risico's op één moment samenkomen: de datamigratie, de nieuwe werkprocessen én een team dat nog moet wennen. Gaat er dan iets mis, dan is er geen weg terug en staat je bedrijf stil.
Het onderschatte probleem zit in verborgen werkprocessen. In elk oud systeem zijn jaren aan uitzonderingen, omwegen en gewoontes ingesleten die nergens beschreven staan. Bij een big bang moet het nieuwe systeem dat allemaal vanaf dag één foutloos overnemen, en ontdek je de gaten pas als klanten en facturen er last van hebben.
Daar komt de druk bij. Een big bang heeft één deadline waarop álles af moet zijn. Loopt de bouw uit, dan wordt er gesneden in testen en datacontrole: precies de onderdelen die het risico moesten afdekken. Een gefaseerde aanpak haalt die druk eraf, omdat het oude systeem blijft draaien tot het nieuwe zich bewezen heeft.
De strangler-aanpak betekent dat je het nieuwe systeem stuk voor stuk óm het oude heen bouwt. Elk afgerond deel neemt één taak van het oude systeem over, tot er uiteindelijk niets meer van over is. Het oude systeem blijft al die tijd gewoon draaien als vangnet.
De naam komt van de wurgvijg (strangler fig): een plant die om een boom heen groeit en hem langzaam overneemt. In gewone taal: je vervangt niet het hele systeem, maar telkens één proces. Eerst bijvoorbeeld de offertes, dan de voorraad, dan de facturatie, terwijl de rest in het oude systeem blijft staan.
Het grote voordeel: je begint bij het proces dat het meeste pijn doet, en elk afgerond deel levert direct werkende software op. Fouten vallen op in een klein, afgebakend stuk in plaats van in je hele bedrijfsvoering. En je spreidt de investering over het traject, in plaats van alles vooruit te betalen voor één grote oplevering ver weg.
Audit en datamodel: schermen, data, werkprocessen en koppelingen van het oude systeem in kaart brengen. Dat kan ook zonder broncode of documentatie: de database en de manier waarop je team werkt vertellen genoeg.
Eerste deel bouwen: het proces dat het meeste pijn doet of het grootste risico vormt. In sprints van 2 weken met wekelijkse demo's, zodat je team vanaf het begin meekijkt en bijstuurt.
Data migreren en parallel draaien: het nieuwe deel draait naast het oude. Je team vergelijkt de uitkomsten, met het oude systeem als vangnet.
Per onderdeel omschakelen: pas als een deel zich in de praktijk bewezen heeft, gaat het bijbehorende stuk van het oude systeem uit. Daarna volgt het volgende proces.
Oude systeem uitzetten: na een stabiele periode gaat de stekker er definitief uit. Vanaf dan wordt er gemonitord en doorontwikkeld: verouderen voorkom je door bij te blijven, niet door ooit klaar te zijn.
Datamigratie verloopt in drie stappen: de oude database uitlezen, de gegevens opschonen en de migratie in proefrondes draaien. Pas als een proefmigratie volledig klopt (gecontroleerd door je eigen team), zet je de data definitief over. Zo verlies je niets en weet je het zeker vóórdat je omschakelt.
Reken erop dat oude data vervuild is. Dubbele klanten, vrije-tekstvelden waar van alles in staat, statussen die niemand meer gebruikt: na jaren trouwe dienst zit dat in élk systeem. Opschonen hoort daarom bij de migratie: het nieuwe systeem start met data waar je weer van op aan kunt.
Belangrijk is dat de migratie herhaalbaar is: een script dat je zo vaak draait als nodig, niet een eenmalige handmatige actie. Elke proefronde laat zien wat er nog niet klopt, en bij de definitieve overstap is het een routineklus geworden. Ook uit Access-, FileMaker- of zelfs Excel-bestanden is data prima uit te lezen.
Maak tot slot een bewuste keuze over historie: gaan tien jaar oude orders mee naar het nieuwe systeem, of volstaat een doorzoekbaar archief? Beide kan, als je het maar vóór de migratie beslist.
Parallel draaien betekent dat het oude en het nieuwe systeem een afgebakende periode naast elkaar werken, zodat je verschillen ziet vóórdat je definitief omschakelt. Het is de goedkoopste verzekering in het hele traject: een afwijking valt op in een vergelijking, niet in je facturatie of je voorraad.
Wat vergelijk je? Aantallen en totalen: komen orders, voorraadstanden en factuurbedragen in beide systemen op hetzelfde uit? Daarnaast steekproeven uit de dagelijkse praktijk: een offerte, een werkbon, een levering die je in beide systemen volgt. Je eigen team doet die controles; zij kennen de praktijk beter dan welke ontwikkelaar ook.
Eén waarschuwing: spreek vooraf een einddatum en duidelijke criteria af. Parallel draaien is een testfase, geen permanente dubbele administratie. Die houdt niemand vol. De fase eindigt met een bewuste go/no-go: kloppen de cijfers en werkt het team er vlot mee, dan schakel je om. Zo niet, dan los je eerst de verschillen op, met het oude systeem nog gewoon in de lucht.
Zo verhouden de fasen, de werkzaamheden en de impact op je team zich tot elkaar:
Stel: een handelsbedrijf draait op een verouderd pakket plus een lappendeken van sheets. In deze aanpak neemt elke fase één proces over (eerst de orders, dan de voorraad, dan de facturatie), terwijl de handel gewoon doordraait. Geen big bang, geen stilstand: precies het punt van deze aanpak.
Bij SellYourTruck stapten truckdealers over van Excel en losse tools naar één platform. Dat groeide zonder herbouw uit tot een SaaS met ruim 60 dealers: doorontwikkelen in kleine stappen houdt een systeem bij de tijd.
Hoe je voorkomt dat het nieuwe systeem over tien jaar zelf legacy is? Vooral door het na de livegang niet stil te laten staan: nieuwe wensen in kleine stappen blijven oppakken, in plaats van ze jaren op te sparen tot er opnieuw een grote herbouw nodig is. Hoe zo'n traject van bouwen en doorontwikkelen eruitziet, lees je in onze werkwijze.
Eromheen bouwen is slimmer als de kern van het oude systeem nog betrouwbaar werkt, maar één ding ontbreekt: toegang van buiten kantoor, een koppeling met je boekhouding, een klantportaal. Een webschil of koppeling lost dat snel en betaalbaar op. Wringt het systeem zelf (datamodel, snelheid, onderhoudbaarheid), dan is eromheen bouwen uitstel, en is gefaseerd vervangen de betere route.
Drie signalen: niemand durft nog iets te wijzigen, de onderliggende techniek krijgt geen updates meer, en je team organiseert het werk steeds vaker óm het systeem heen, met losse lijstjes en overtypen als gevolg. Komt daar afhankelijkheid van één persoon of één machine bij, dan is het einde van de levensduur in zicht en wordt plannen belangrijker dan wachten.
Een klein project is in 4–8 weken live; bij grotere trajecten staat het eerste werkende deel er meestal binnen 8–12 weken. Omdat je per onderdeel omschakelt, profiteer je tussentijds al van elk afgerond deel. Je wacht niet op één grote oplevering aan het eind van het traject.
Dat kan, maar het is zelden verstandig. Eén-op-één herbouwen kopieert ook alle opgestapelde uitzonderingen en omwegen die in jaren gebruik zijn ingeslopen. De audit aan het begin is juist het moment om per werkproces te kijken: houden, versimpelen of schrappen? Zo krijg je een systeem dat past bij hoe je nú werkt.
We kijken vrijblijvend mee naar je huidige systeem en geven een eerlijke inschatting van de beste route: eromheen bouwen, gefaseerd vervangen of (nog even) niets doen. Liever direct contact? Bel 06 517 507 93 of stuur een WhatsApp.