Hoe bereken je of nieuw bouwen goedkoper is dan blijven onderhouden?

Nieuw bouwen is goedkoper dan blijven onderhouden wanneer de jaarlijkse onderhoudskosten van je huidige software structureel hoger zijn dan de afgeschreven investering in een nieuw systeem. Als vuistregel geldt: zodra je meer dan 30 tot 40 procent van de oorspronkelijke bouwkosten per jaar kwijt bent aan onderhoud, loont een herbouwtraject vrijwel altijd op de middellange termijn. In dit artikel werk je stap voor stap door de rekensom, van het herkennen van de eerste signalen tot het maken van een onderbouwde beslissing.

Wanneer worden onderhoudskosten een signaal om opnieuw te bouwen?

Onderhoudskosten worden een signaal om opnieuw te bouwen wanneer ze elk jaar stijgen zonder dat de software functioneel verbetert. Zolang onderhoud je systeem stabiel, veilig en uitbreidbaar houdt voor een redelijk bedrag, is het een normale bedrijfsuitgave. Zodra het budget grotendeels opgaat aan brandjes blussen in plaats van waarde toevoegen, is de grens bereikt.

Praktische signalen om op te letten:

Elke kleine aanpassing kost buitenproportioneel veel tijd of geld omdat de codebase onbeheersbaar is geworden.
Developers die de software kennen vertrekken, en nieuwe mensen hebben maanden nodig om ingewerkt te raken.
Integraties met andere systemen lukken niet of nauwelijks meer zonder flinke workarounds.
Beveiligingsupdates worden steeds vaker uitgesteld omdat ze te complex zijn om door te voeren.
Gebruikers klagen structureel over traagheid, fouten of ontbrekende functionaliteit die concurrenten wel bieden.

Eén van deze signalen op zichzelf is zelden voldoende reden. Maar als je er meerdere tegelijkertijd herkent, is het tijd om de kosten serieus naast elkaar te leggen.

Wat zijn de werkelijke kosten van het blijven onderhouden van oude software?

De werkelijke kosten van het onderhouden van oude software zijn bijna altijd hoger dan ze op het eerste gezicht lijken. Naast de directe facturen van je ontwikkelaar of leverancier zijn er verborgen kosten die zelden op één plek worden bijgehouden, maar die bij elkaar opgeteld een aanzienlijk bedrag vormen.

Denk aan de volgende kostenposten die je mee moet rekenen:

Directe ontwikkelkosten: bugfixes, patches, kleine aanpassingen en verplichte updates.
Productiviteitsverlies: uren die medewerkers kwijt zijn aan omwegen, handmatige handelingen of systeemfouten.
Risicopremie: de kans op uitval, datalekken of compliance-problemen neemt toe naarmate software veroudert.
Gemiste kansen: functionaliteit die je niet kunt bouwen omdat de architectuur het niet toelaat, terwijl concurrenten wel doorontwikkelen.
Kennis- en documentatieschuld: het steeds duurder worden van elke aanpassing doordat niemand meer precies weet hoe het systeem werkt.

Tel je al deze posten bij elkaar op, dan ontdek je vaak dat de jaarlijkse werkelijke kosten twee tot drie keer hoger liggen dan het bedrag op de onderhoudsfactuur.

Hoe bereken je de total cost of ownership van nieuw bouwen?

De total cost of ownership (TCO) van nieuw bouwen bereken je door alle kosten over de verwachte levensduur van het nieuwe systeem op te tellen en die te vergelijken met de geprojecteerde kosten van doorgaan met het huidige systeem over diezelfde periode. Een eerlijke vergelijking kijkt minstens drie tot vijf jaar vooruit.

Voor het nieuwe systeem tel je de volgende kostencomponenten op:

Initiële bouwkosten: ontwerp, ontwikkeling, testen en livegang.
Migratie en implementatie: datamigratie, koppelingen met andere systemen en gebruikerstraining.
Jaarlijks onderhoud en hosting: structureel lager bij een moderne, goed gedocumenteerde codebase.
Doorontwikkeling: nieuwe functies die je de komende jaren wilt toevoegen.
Productiviteitswinst: uren die medewerkers besparen door een sneller en slimmer systeem, als negatieve kostenpost.

Zet die totale som tegenover de TCO van het huidige systeem: het huidige jaarlijkse onderhoud vermenigvuldigd met de looptijd, plus de verborgen kosten uit de vorige sectie. Het omslagpunt, het moment waarop nieuw bouwen de investering heeft terugverdiend, noem je de terugverdientijd. Bij goed uitgevoerde maatwerkprojecten ligt die doorgaans tussen de twee en vier jaar.

Als je werkt met ERP-software of andere bedrijfskritische systemen, is het slim om deze berekening te laten ondersteunen door iemand die zowel de technische als de bedrijfsmatige kant begrijpt.

Wat is technische schuld en hoe weegt het mee in de berekening?

Technische schuld is de opgebouwde achterstand in codekwaliteit, architectuur en documentatie die ontstaat wanneer software snel of met compromissen is gebouwd en daarna niet structureel is bijgehouden. Net als financiële schuld brengt technische schuld rente met zich mee: elke nieuwe aanpassing kost meer tijd en geld dan nodig zou zijn bij een schone codebase.

Technische schuld weegt zwaar in de make-or-buy-berekening omdat het een vermenigvuldiger is op alle toekomstige onderhoudskosten. Hoe hoger de schuld, hoe duurder elke volgende aanpassing wordt. Dit maakt het lastig om toekomstige onderhoudskosten realistisch te schatten op basis van historische facturen, want die zullen structureel stijgen.

Je kunt technische schuld niet altijd precies in euro’s uitdrukken, maar je kunt hem wel inschatten. Vraag je ontwikkelaar of een onafhankelijke partij om een code-audit. Die geeft je een indicatie van hoe beheersbaar de codebase is, hoeveel uren een gemiddelde aanpassing kost ten opzichte van wat redelijk zou zijn, en welke risico’s er schuilen in de huidige architectuur. Die informatie is goud waard voor je berekening.

Welke factoren bepalen of nieuw bouwen uiteindelijk goedkoper uitvalt?

Of nieuw bouwen uiteindelijk goedkoper uitvalt, hangt af van een combinatie van factoren: de hoogte van de technische schuld, de verwachte levensduur van het nieuwe systeem, de mate van maatwerk die nodig is en hoe snel de investering productiviteitswinst oplevert. Er is geen universeel antwoord, maar er zijn wel duidelijke indicatoren.

Factoren die nieuw bouwen aantrekkelijker maken

De huidige software is ouder dan acht tot tien jaar en gebaseerd op verouderde technologie.
De onderhoudskosten stijgen elk jaar, ook zonder dat er nieuwe functies worden gebouwd.
Het systeem blokkeert groei: je kunt niet schalen, niet integreren of niet voldoen aan nieuwe wetgeving.
De leverancier of de interne kennis van het systeem is beperkt of dreigt te verdwijnen.

Factoren die doorgaan met onderhouden rechtvaardigen

De software is stabiel, goed gedocumenteerd en de onderhoudskosten zijn voorspelbaar laag.
Een nieuw systeem vereist een ingrijpende migratie die de bedrijfsvoering tijdelijk verstoort.
De functionele eisen veranderen de komende jaren waarschijnlijk sterk, waardoor een nieuwe bouw snel achterhaald kan raken.
Het budget voor een herbouwtraject is er nu simpelweg niet, terwijl het huidige systeem nog voldoet.

Hoe pak je de beslissing praktisch aan als de cijfers dichtbij elkaar liggen?

Als de kosten van nieuw bouwen en doorgaan met onderhouden dichtbij elkaar liggen, beslis je op basis van strategische factoren: welke optie geeft je organisatie meer flexibiliteit, minder risico en een betere uitgangspositie voor de komende vijf jaar? De cijfers zijn het startpunt, niet het eindpunt van de beslissing.

Een paar praktische stappen die helpen wanneer de rekensom geen duidelijke winnaar aanwijst:

Laat een onafhankelijke code-audit uitvoeren om de werkelijke staat van de huidige software in kaart te brengen.
Maak een scenarioplanning: wat kost het als je over twee jaar alsnog moet herbouwen, na twee extra jaren onderhoud?
Betrek de eindgebruikers: zij weten als geen ander waar de pijn zit en hoeveel productiviteit er verloren gaat.
Overweeg een gefaseerde aanpak: in sommige gevallen is het mogelijk om het meest kritieke deel van de software te vernieuwen zonder alles in één keer op te gooien.
Kijk naar de risicokant: welke optie heeft het hoogste risico op uitval, beveiligingsproblemen of compliance-issues?

Bij twijfel is een gefaseerde herbouw vaak de slimste keuze. Je spreidt de investering, je valideert de nieuwe aanpak in de praktijk en je houdt het risico beheersbaar. Wil je meer weten over hoe moderne softwareoplossingen eruitzien? Dat geeft je ook een realistischer beeld van wat een herbouwtraject inhoudt.

Hoe VL Software helpt bij de keuze tussen nieuw bouwen en onderhouden

VL Software helpt organisaties om deze beslissing onderbouwd te maken, zonder dat je meteen in een groot en kostbaar traject stapt. Als onderdeel van VL Consultants BV combineren we technische expertise met bedrijfsmatig inzicht, zodat je een eerlijk en volledig beeld krijgt van je opties.

Wat VL Software voor je kan betekenen:

Technische analyse van je huidige software: we brengen de staat van je codebase in kaart en maken de technische schuld inzichtelijk.
TCO-berekening op maat: we zetten de werkelijke kosten van doorgaan naast een realistische investering in nieuw bouwen.
Advies over een gefaseerde aanpak: waar mogelijk zoeken we naar een route die de investering spreidt en het risico beperkt.
Maatwerk softwareontwikkeling: als herbouwen de juiste keuze is, bouwen we een moderne, schaalbare oplossing met technologieën zoals Laravel, React en GraphQL.
Detachering van ervaren developers: heb je tijdelijk versterking nodig om de analyse of de bouw te doen? Dat kan ook.

Benieuwd wat de slimste keuze is voor jouw situatie? Neem contact op en bespreek vrijblijvend de mogelijkheden met ons team.