Skip to main content
  • Auteur

    Conclusion

    |
  • Publicatiedatum

    17 februari, 2026

    |
  • Deel

IT-legacy in de praktijk

Van kroonjuweel tot molensteen

Veel systemen die eigenlijk verouderd zijn draaien nog steeds, maar vaak tegen hoge kosten, met grote risico’s en veel frustratie. En toch durft niemand ze zomaar los te laten. Wat als de vervanging mislukt? Wat als de kennis verloren gaat? En hoe stel je een business case op voor een vervanging die functioneel gezien weinig tot niets oplevert?

 

Precies dat maakt legacy één van de hardnekkigste vraagstukken in de bestuurskamer. Het goede nieuws: er is een weg vooruit voor bestaande en potentieel nieuwe legacy. Maar dat vraagt om lef, geduld en een stappenplan. We doen een voorzet

Wees kritisch op
de devil you know

Het is verleidelijk om vast te houden aan wat je kent. De systemen zijn misschien log en ouderwets, maar ze draaien. Iedereen weet waar de knoppen zitten en wat de beperkingen zijn. Dat voelt veilig. Toch is dit schijnveiligheid. Want intussen groeien de risico’s: beveiligingslekken die niet meer te patchen zijn, dure licenties die blijven oplopen, specialisten die met pensioen gaan. Hoe langer je wacht, hoe kwetsbaarder je wordt.

 

Een belangrijke valkuil daarbij is de sunk cost fallacy: de neiging om oude investeringen te blijven verdedigen. Omdat er ooit miljoenen in het systeem zijn gestoken, voelt het alsof je waarde weggooit als je afscheid neemt. Maar die kosten zijn al gemaakt en komen niet meer terug. Vasthouden leidt er vaak toe dat organisaties alles één-op-één overhevelen, inclusief overbodige functies, processen en ontwerpfouten uit het verleden. Het resultaat is een dure kopie van het verleden, verpakt in moderne technologie, ofwel ‘functionele legacy’.

 

Wat helpt?

 

Maak het concreet: breng in kaart wat het kost om je legacy in de lucht te houden. In geld, risico’s en gemiste kansen. En stel de vraag: wat hebben we echt nodig om onze organisatie vooruit te brengen? Vaak blijkt pas dan dat “gewoon blijven doordraaien” duurder en gevaarlijker is dan vernieuwen.

 

Signalen dat je te veel leunt op legacy

 

  • Je leverancier ondersteunt je software niet meer.
  • Slechts een handvol mensen in de organisatie begrijpt hoe het systeem werkt en hoe het te gebruiken is.
  • Niemand reageert op vacatures rond het legacysysteem, omdat het te onbekend terrein is.
  • Nieuwe collega’s hebben om dezelfde reden moeite zich het nieuwe systeem eigen te maken.
  • Integratie met moderne tools (API’s, cloud, SSO) is bijna onmogelijk.
  • Wijzigingen duren weken of zijn simpelweg niet te realiseren.
  • Je hoort steeds vaker: “het systeem kan dat niet”.
  • Standaardsoftware: ingekochte pakketten voor bedrijfsprocessen (bijv. SAP R/3 of ouder, Microsoft Navision, Oracle E-Business Suite 10, WordPerfect).
  • Maatwerksoftware: intern ontwikkeld of in opdracht gebouwd; vaak nauw verweven met specifieke processen.
  • Platformen, tools & infrastructuur: onderliggende technologie en frameworks (bijv. Windows NT, Internet Explorer, COBOL, AngularJS, MS Access, Java Applets, dBASE IV).

 

Soorten legacy (in het kort)

 

  • Standaardsoftware: ingekochte pakketten voor bedrijfsprocessen (bijv. SAP R/3 of ouder, Microsoft Navision, Oracle E-Business Suite 10, WordPerfect).
  • Maatwerksoftware: intern ontwikkeld of in opdracht gebouwd; vaak nauw verweven met specifieke processen.
  • Platformen, tools & infrastructuur: onderliggende technologie en frameworks (bijv. Windows NT, Internet Explorer, COBOL, AngularJS, MS Access, Java Applets, dBASE IV).

 

Het type legacy bepaalt de impact op je bedrijfsvoering. Een legacy ERP-systeem of een verouderde database heeft bijvoorbeeld veel grotere zakelijke implicaties dan verouderde ondersteunende software. Uiteraard iets om rekening mee te houden.

Kill your
darlings

Dit is misschien de moeilijkste les. Elke organisatie heeft functies of processen die ooit waardevol waren, maar die nu vooral ballast vormen.

 

Vaak hoor je: “Dat doen we altijd zo.” Of: “Die functionaliteit gebruiken we al twintig jaar, die moet mee.” Vaak beseft een organisatie daarnaast niet dat ze met legacy te maken heeft. Het systeem lijkt goed te werken, terwijl processen eigenlijk inefficiënt zijn en risico’s pas zichtbaar worden als niemand meer weet hoe het systeem functioneert. Veel van deze darlings kun je daarom beter loslaten. Hoe meer je meesleept naar een nieuw systeem, hoe complexer, duurder en risicovoller je migratie wordt.

 

Wat helpt?

 

Ga met eindgebruikers in gesprek. Vraag wat ze nodig hebben en echt gebruiken aan systeem-features. Je zult merken dat er verrassend veel overbodig is. Zie een migratie als kans om op te schonen: in je data, je processen en je applicatielandschap.

 

Kill your darlings in de praktijk

 

  • Bundel afspraken en definities: werk met één set kernprocessen in plaats van tien varianten.
  • Zoek geen onderscheidend vermogen in luxe systemen: daar word je niet op beoordeeld. Accepteer voor generieke processen een standaardwerkwijze.
  • Archiveer oude data slim, in plaats van alles mee te nemen.
  • Focus op businesswaarde: elke functie die geen aantoonbare waarde levert, gaat eruit.
  • Bouw een potje op: neem al je systemen op in de boekhouding en schrijf jaarlijks af, zodat je een financieel reservefonds opbouwt dat gebruikt kan worden voor toekomstige vervangingen, net zoals je dat met machines en kapitaalintensieve installaties doet.

Bouw stap voor stap
aan de toekomst

Een big bang-migratie klinkt aantrekkelijk (“klaar in één keer!”), maar is in de praktijk bijna ondoenlijk. Je loopt enorme risico’s en de winkel moet intussen gewoon openblijven.

 

Een verstandiger aanpak: werk in stappen. Gebruik het strangler pattern: bouw nieuwe functionaliteit naast het oude systeem en schuif langzaam steeds meer processen door. Zo blijf je in control en kun je tijdig bijsturen.

 

Wat helpt?

 

  • Begin met een doelarchitectuur: een duidelijke stip op de horizon.
  • Bouw eerst een integratievoorziening en neem vervolgens stapsgewijs nieuwe modules in gebruik. Begin bijvoorbeeld met het recruitmentproces, voordat het volledige HR-systeem wordt vervangen.
  • Maak eigenaarschap expliciet: legacy ontstaat vaak door gebrek aan verantwoordelijkheid(sgevoel) voor lifecycle management. Zorg dat dat nu wél goed geregeld is.

Different
by design

De grootste fout die je kunt maken, is nieuwe legacy bouwen. Dat gebeurt sneller dan je denkt. Zonder duidelijke keuzes beland je opnieuw in maatwerk, afhankelijkheid en technische schuld.

 

Wat helpt?

 

Wees expliciet in je ontwerpprincipes en architectuurkeuzes. Bepaal welke systemen je inkoopt, wat je zelf ontwikkelt en hoe je standaardiseert op technologie en integratie van data. Documenteer, borg en herzie alle keuzes periodiek. En begin altijd met de eindvraag: hoelang willen we dit systeem draaiende houden? En hoe zorgen we dat dit systeem ook op die termijn nog flexibel en waardevol is?

 

Voorkom nieuwe legacy

 

  • Documenteer elke architectuurkeuze.
  • Hanteer open standaarden.
  • Regel eigenaarschap van dag één.
  • Plan al tijdens de start de exitstrategie.
  • Elk systeem dat lang genoeg meegaat, wordt vroeg of laat legacy. De kunst is niet om dat te vermijden, maar om er bewust mee om te gaan.
  • Dan wordt legacy niet je molensteen, maar gewoon een tussenstation op weg naar de toekomst.

Different:
Functioneel boven different

Een klassieke manier om met legacy om te gaan, is technisch: je neemt de bestaande code en vertaalt die regel voor regel naar een moderne programmeertaal of een nieuw platform. Dat lijkt logisch en veilig, maar in de praktijk krijg je vooral een 1-op-1-kopie van het oude systeem. Het enige wat verandert, is de technologie eronder. Voor de organisatie voelt dat vaak als “veel kosten, weinig winst”.

 

Bij Conclusion doen we het net even anders. En een andere manier van werken begint bij de functionaliteit. Wat doet het systeem vandaag eigenlijk? Welke processen ondersteunt het, welke functies zijn noodzakelijk, en welke worden amper gebruikt? Die inzichten verzamel je met technische analyses uit bijvoorbeeld observability data, maar ook door gebruikersinterviews en observaties. AI helpt ons om de grote hoeveelheid logica en data in oude systemen sneller te doorgronden, door analyses te maken van schermen, tests, documentatie en ontwerpen, en deze functionele inzichten te benutten voor de generatie van nieuwe systeemonderdelen.

 

Deze functionele analyse is een vrij nieuwe aanpak, ondersteund door AI. Het resultaat is dat je een afgebakende set kernfunctionaliteiten als basis voor herbouw hanteert. Eigenlijk heel logisch. Met de inzet van AI wordt dit ook realistisch en haalbaar.

Klantmagazine website 1920x1080

Jouw gids in digitale transformatie
Ontdek DIFFERENT

Digitale transformatie zet organisaties op scherp. Als organisatie ga je aan de slag met AI, databetrouwbaarheid, cloudstrategieën, technologische duurzaamheid en de groeiende behoefte aan sterk gepersonaliseerde dienstverlening. In DIFFERENT vind je inzichten in 10 cruciale thema’s, inspirerende praktijkverhalen en scherpe expertvisies.

Durf anders te doen. Vraag het magazine aan en pak je voorsprong.