Legacy systemen moderniseren staat bij veel Nederlandse bedrijven op de agenda, maar zelden bovenaan — tot het te laat is. Een factureringssysteem uit 2009, een ERP-koppeling die alleen de oprichter nog begrijpt, een maatwerktool die draait op een server die niemand meer patcht. Het werkt, dus het blijft liggen. Tot een leverancier stopt met support, een sleutelmedewerker vertrekt, of een nieuwe wet- en regelgeving eist dat data ergens anders vandaan komt dan het oude systeem kan leveren. Dan is modernisering geen project meer, maar een crisis.
Het goede nieuws: legacy systemen moderniseren betekent niet automatisch alles wegdoen en opnieuw beginnen. Er zijn drie hoofdroutes, elk met een andere prijs, risico en doorlooptijd. In dit artikel zetten we ze op een rij, geven we een praktisch keuzekader, en benoemen we de valkuilen die modernisering vaker laten mislukken dan de techniek zelf.
Wat legacy systemen bedrijven echt kosten
De kosten van een verouderd systeem zijn zelden zichtbaar in één regel op de begroting. Ze zitten verspreid over de organisatie:
- Onderhoudskosten die jaarlijks stijgen, terwijl de functionaliteit gelijk blijft.
- Sleutelpersoonafhankelijkheid: één of twee mensen die het systeem écht doorgronden.
- Beveiligingsrisicodoor verouderde frameworks, ontbrekende patches of platforms die de fabrikant niet meer ondersteunt.
- Vertraagde besluitvorming doordat data vastzit in silo’s die niet praten met moderne rapportagetools.
- Onmogelijke koppelingen met nieuwe software, omdat het systeem geen API biedt of alleen verouderde protocollen spreekt.
Technische schuld stapelt zich op
Elke work-around die ooit is gebouwd om een beperking te omzeilen, is een stukje technische schuld. Op zichzelf onschuldig, maar bij elkaar opgeteld een systeem dat niemand meer durft aan te raken. Dat is het moment waarop ‘we passen het straks wel aan’ omslaat in ‘we kunnen dit niet meer aanpassen’.
Signalen dat modernisering niet langer kan wachten
Een paar concrete signalen die er vaak aan voorafgaan dat legacy systemen van risico naar crisis omslaan:
- De leverancier van het systeem of het onderliggende platform kondigt end-of-life aan.
- Nieuwe wet- en regelgeving (denk aan de AI Act of aangescherpte privacy-eisen) vraagt om data of rapportages die het systeem niet kan leveren.
- Er is nog maar één medewerker die wijzigingen durft door te voeren, en die persoon overweegt te vertrekken.
- Elke koppeling met nieuwe software vraagt om een handmatige, foutgevoelige tussenstap.
- De hostingpartij of hardwareleverancier kan geen garanties meer geven op beschikbaarheid.
Herken je twee of meer van deze signalen? Dan is het verstandig om modernisering niet langer als ‘iets voor volgend jaar’ te behandelen, maar als een concreet traject te agenderen.
Drie strategieën om legacy systemen te moderniseren
Bij modernisering wordt vaak meteen gedacht aan ‘alles vervangen door iets nieuws’. Dat is precies de reden dat veel trajecten duurder uitvallen dan nodig. Er zijn drie realistische routes.
1. Rehosting: dezelfde functionaliteit, nieuwe fundering
Bij rehosting verhuist de bestaande applicatie — zonder grote code-aanpassingen — naar moderne infrastructuur, meestal de cloud. De logica en functionaliteit blijven ongewijzigd, maar het systeem draait voortaan op een stabiel, onderhouden platform. Dit is de snelste en goedkoopste route, en een logische eerste stap wanneer de software zelf nog voldoet maar de onderliggende infrastructuur het probleem is. Onze ICT & cloud oplossingen zijn hier vaak op gericht: risico’s uit de infrastructuur halen zonder de bedrijfslogica aan te tasten.
2. Re-engineering: de kern herbouwen als maatwerk
Wanneer het systeem wel functioneel waardevol is, maar de technische basis niet meer houdbaar, is herbouw als maatwerkoplossing vaak de beste investering. Hierbij wordt de bedrijfslogica die het bedrijf uniek maakt — vaak jarenlange kennis, verwerkt in regels en processen — overgezet naar een moderne, onderhoudbare codebase. Dit is meer werk dan rehosting, maar levert een systeem op dat weer jarenlang meegaat én uitbreidbaar is. Bekijk hoe we dit aanpakken via maatwerk software.
3. Vervangen: overstappen op een nieuw platform
Soms is vervanging de enige verantwoorde keuze — bijvoorbeeld wanneer het legacy systeem generieke functionaliteit biedt die inmiddels prima wordt afgedekt door bestaande standaardsoftware, of wanneer de onderliggende technologie zo verouderd is dat herbouwen net zoveel kost als opnieuw beginnen. Vervanging is ingrijpender qua verandermanagement (nieuwe interfaces, nieuwe workflows), maar voorkomt dat je over vijf jaar weer tegen dezelfde muur aanloopt.
Combinaties komen vaker voor dan een enkele route
In de praktijk kiezen bedrijven zelden voor precies één strategie voor de hele organisatie. Een veelgebruikt patroon: het orderverwerkingssysteem met unieke prijslogica wordt herbouwd als maatwerk, terwijl de verouderde boekhoudmodule wordt vervangen door een standaardpakket. Zo investeer je alleen zwaar in de onderdelen die daadwerkelijk onderscheidend zijn, en houd je de rest eenvoudig.
Wat kost modernisering, en hoe bouw je een business case
Een moderniseringstraject wordt zelden goedgekeurd op techniek alleen — de business case moet kloppen. Drie elementen horen daar altijd in thuis.
Vergelijk met de kosten van niets doen
De vergelijking die vaak ontbreekt, is niet ‘wat kost modernisering’ maar ‘wat kost uitstel’. Reken onderhoudskosten, het risico op uitval, en de tijd die medewerkers kwijt zijn aan handmatige work-arounds mee over een periode van drie tot vijf jaar. Vaak blijkt dat niets doen de duurste optie is, alleen minder zichtbaar in één keer.
Fasering houdt de investering beheersbaar
In plaats van één groot budget vooraf vast te leggen, werkt een gefaseerde aanpak beter: begin met het onderdeel met het hoogste risico of de grootste bedrijfsimpact, lever dat op, en gebruik de resultaten om het vervolg te onderbouwen. Dit verlaagt niet alleen het financiële risico, maar ook de kans dat het project halverwege vastloopt door voortschrijdend inzicht.
Reken uitwijkscenario’s mee
Bij systemen die processen ondersteunen die niet stil mogen vallen — facturatie, orderverwerking, klantcommunicatie — moet de business case ook het risico van een mislukte livegang meenemen. Een parallelle draaiperiode, waarin oud en nieuw systeem tijdelijk naast elkaar bestaan, kost extra, maar voorkomt dat een moderniseringstraject zelf de bron van downtime wordt.
Een praktisch keuzekader
Welke route past, hangt af van vier vragen die je per systeem — niet per organisatie — moet beantwoorden:
Hoe uniek is de bedrijfslogica?
Bevat het systeem regels, berekeningen of processen die het bedrijf onderscheiden van concurrenten? Dan is die logica het behouden waard, via rehosting of re-engineering. Is de functionaliteit generiek (facturatie, boekhouding, CRM), dan ligt vervanging door bewezen standaardsoftware vaak meer voor de hand.
Hoe groot is het beveiligings- en continuïteitsrisico?
Draait het systeem op software die niet meer wordt gepatcht, of op hardware die end-of-life is? Dan is uitstel het duurste scenario. Rehosting kan dit risico op korte termijn wegnemen, ook als een volledige herbouw nog niet haalbaar is.
Hoe afhankelijk ben je van koppelingen?
Moet het systeem praten met een boekhoudpakket, een e-commerceplatform of een CRM? Verouderde systemen missen vaak moderne API’s, waardoor koppelen alleen kan via foutgevoelige, handmatige exports. Dit is precies waar automatisering en integraties waarde toevoegen: een tussenlaag die legacy systemen alsnog laat communiceren met moderne tools, zonder meteen het hele systeem te vervangen.
Wat is de realistische levensduur die je nodig hebt?
Een tijdelijke oplossing voor twee jaar vraagt een andere investering dan een fundament dat tien jaar moet meegaan. Wees hier expliciet over voordat het project start — het bepaalt of rehosting volstaat of dat re-engineering nodig is.
Veelgemaakte fouten bij modernisering
De meeste moderniseringstrajecten mislukken niet door de techniek, maar door de aanpak eromheen.
- Alles in één big-bang project willen doen. Grote, meerjarige trajecten met één opleverdatum hebben een hoog faalrisico. Kleinere, gefaseerde stappen met tussentijdse resultaten zijn beter te sturen en te valideren.
- De kennis van de huidige gebruikers overslaan. Legacy systemen bevatten vaak ongedocumenteerde bedrijfsregels die alleen bekend zijn bij de mensen die er dagelijks mee werken. Zonder hen goed te betrekken, verdwijnt kennis die je niet meer terugkrijgt.
- Geen duidelijk besluit over scope. Moderniseren wordt al snel een aanleiding om meteen alle wensen van de afgelopen tien jaar mee te nemen. Dat vertraagt het project en vergroot het risico.
- Onderschatten van dataoverdracht. Data migreren van een oud naar een nieuw systeem is vaak complexer dan de bouw van de nieuwe functionaliteit zelf, zeker bij jarenlange, inconsistente datasets.
Conclusie: begin met inzicht, niet met bouwen
Legacy systemen moderniseren is geen alles-of-niets beslissing. De juiste aanpak hangt af van hoe uniek de bedrijfslogica is, hoe groot het risico is, en hoe afhankelijk je bent van koppelingen met andere software.
Belangrijkste punten om mee te nemen:
- Rehosting verlaagt risico snel, zonder de functionaliteit aan te tasten.
- Re-engineering behoudt unieke bedrijfslogica in een onderhoudbare, moderne basis.
- Vervanging is de beste keuze bij generieke functionaliteit die standaardsoftware al goed afdekt.
- Faseren en gebruikerskennis meenemen verkleinen het risico op mislukking aanzienlijk.
Twijfel je welke route past bij jouw systeem? ByteMonkeys denkt graag mee over een moderniseringsstrategie die aansluit op je risico’s, budget en groeiplannen. Neem contact op voor een vrijblijvend gesprek over jouw legacy systeem.