Een maatwerk webapplicatie is financieel voordeliger dan het blijven patchen van legacy systemen wanneer de jaarlijkse kosten van patches, storingen en workarounds meer dan 40% tot 50% van de nieuwbouwwaarde bedragen. Dit omslagpunt maakt het economisch verantwoord om te investeren in een nieuw platform, mits de organisatie ook de interne capaciteit heeft om de overgang te ondersteunen.
Kostenoverwegingen bij maatwerk versus legacy patching
Bij het vergelijken van maatwerk webapplicaties met het patchen van legacy systemen, spelen verborgen kosten en risico's een cruciale rol. Het artikel onderzoekt wanneer maatwerk financieel gerechtvaardigd is en welke factoren de kostenverhouding beïnvloeden.
- Bepaal het omslagpunt door jaarlijkse patchkosten te vergelijken met de nieuwbouwwaarde.
- Erken de verborgen kosten van reactief onderhoud en gefragmenteerde patching.
- Overweeg de impact van datamigratie en interne capaciteit op het totale kostenplaatje.
- Evalueer de risico's van een 'Big Bang' vervanging versus een gefaseerde migratie.
- Neem interne uren en datakwaliteit expliciet op in de kostenraming.
Wanneer is maatwerk websoftware financieel beter dan patchen?
Maatwerk websoftware wordt een financieel en operationeel verdedigbare route zodra de jaarlijkse, cumulatieve kosten van patches, storingen en workarounds meer dan 40% tot 50% van de nieuwbouwwaarde bedragen.
Maatwerk websoftware wordt een financieel en operationeel verdedigbare route zodra de jaarlijkse, cumulatieve kosten van patches, storingen en workarounds meer dan 40% tot 50% van de nieuwbouwwaarde bedragen. Dit is geen algemene marktstandaard, maar een interne richtwaarde om een omslagpunt zichtbaar te maken. Onder die grens kan incrementeel onderhoud nog passen bij een beperkte resterende gebruiksduur. Boven die grens verschuift de beoordeling: de organisatie betaalt dan ieder jaar een substantieel deel van een vervangingsproject zonder dat daarmee vanzelf een samenhangend nieuw fundament ontstaat.
De vergelijking vraagt om een jaarlijkse optelsom in plaats van een beoordeling van losse wijzigingsverzoeken. Een patch kan op zichzelf klein lijken, terwijl een storing, een noodreparatie en een handmatige workaround op verschillende budgetregels terechtkomen. De financiële vraag is daarom niet uitsluitend wat de volgende wijziging kost, maar welk deel van de nieuwbouwwaarde de huidige exploitatie ieder jaar opnieuw verbruikt. Als die uitgaven zich opstapelen, wordt uitstel een terugkerende operationele keuze met een herkenbare prijs.
Een maatwerktraject vraagt tegelijk om inzet die in een alleen-technische raming gemakkelijk ontbreekt. Voor modernisering met legacy-integraties is wekelijks 10 tot 20 uur interne capaciteit van domeinexperts nodig voor requirement reviews, data profiling en acceptatietesten. Die uren zijn geen vrijblijvende projectreserve: zij bepalen of procesregels correct worden vastgelegd, of gegevens vooraf kunnen worden beoordeeld en of de nieuwe werkwijze voldoende wordt getoetst voordat zij operationeel wordt ingezet. Ontbreekt deze capaciteit, dan kan een investering in nieuwbouw de onzekerheid van het bestaande landschap verplaatsen naar de uitvoering van het project.
De financiële grens is dus bruikbaar als combinatie van twee observaties: de terugkerende last van het bestaande systeem en de feitelijke capaciteit om vervanging gecontroleerd uit te voeren. Een nieuw platform is niet automatisch goedkoper door zijn initiële bouwbudget; het wordt verdedigbaar wanneer de jaarlijkse reparatielast structureel hoog is én de organisatie tijd kan vrijmaken om de overgang inhoudelijk te dragen.
Waarom lijkt patchen goedkoper dan maatwerk?
Patchen krijgt in een goedkeuringsronde vaak een gunstige uitgangspositie omdat de uitgave klein, direct en afgebakend oogt. Een maatwerktraject maakt juist veel werk zichtbaar voordat er gebouwd wordt: gegevens moeten worden beoordeeld, koppelingen aangepast en acceptatie ingericht. Het contrast is daardoor misleidend wanneer alleen de eerstvolgende factuur wordt vergeleken. De werkelijke kosten volgen vaak een keten waarin onderdelen die aanvankelijk buiten de begroting vallen later onder tijdsdruk alsnog moeten worden betaald.
Een herkenbaar verloop begint bij onvolledige budgettering tijdens de leveranciersselectie. Wanneer datamigratie en aanpassingen aan API’s niet zijn meegenomen, verschijnt de complexiteit pas tijdens de uitvoering. De begroting komt onder druk te staan, waarna de reactie kan zijn om te bezuinigen op gebruikersacceptatietesten en testdekking. Daarmee verdwijnt niet het onderliggende werk, maar de controle erop. Het risico verplaatst zich naar de ingebruikname, waar instabiliteit ernstige verstoring van de dagelijkse operatie kan veroorzaken. Patchen lijkt in deze vergelijking goedkoop omdat de kosten van deze keten niet vooraf als één geheel worden getoond.
Ook data profiling wordt gemakkelijk als voorbereidende activiteit behandeld in plaats van als onderdeel van de kostenvergelijking. Zonder voorafgaande beoordeling kunnen geautomatiseerde migratiescripts vastlopen op corrupte historische records. Een snelle as-is-migratie zonder opschoning lijkt dan een uitweg, maar kan vervuilde gegevens in de nieuwe webapplicatie brengen. Als gevolg daarvan kunnen langdurige parallelle runs nodig worden. De organisatie draagt dan tijdelijk zowel dubbele hosting- als licentiekosten, terwijl de verwachte beëindiging van het oude systeem uitblijft.
Het verschil zit daarmee niet in een abstract voordeel van maatwerk, maar in de manier waarop kosten zichtbaar worden gemaakt. Patchen wordt meestal beoordeeld per ingreep; vervanging dwingt tot het benoemen van afhankelijkheden vooraf. Voor een verdedigbare vergelijking horen migratie, API-aanpassingen, gegevenskwaliteit, testwerk en de mogelijke duur van parallelle exploitatie in dezelfde raming thuis als de zichtbare ontwikkel- of onderhoudskosten.
Welke kostencomponenten worden vaak vergeten?
De beschikbare onderbouwing noemt een bandbreedte van 20% tot 40% van het IT-budget en de ontwikkelcapaciteit.
Een bruikbare kostenvergelijking onderscheidt niet alleen bouw- en onderhoudsbudgetten, maar ook de activiteiten die nodig zijn om data, werkprocessen en de bestaande omgeving verantwoord te scheiden. De volgende posten maken zichtbaar waar de rekening kan verschuiven.
- Reactief onderhoud en herstel van koppelingen. Gefragmenteerd patchen vraagt niet alleen geld voor de patch zelf. Ook het reactief onderhouden van de omgeving en het repareren van verbroken koppelingen leggen beslag op IT-budget en ontwikkelcapaciteit. De beschikbare onderbouwing noemt een bandbreedte van 20% tot 40% van het IT-budget en de ontwikkelcapaciteit. Het gevolg is niet slechts hogere beheerlast: capaciteit die naar reparaties gaat, staat niet beschikbaar voor ander ontwikkelwerk. In een begroting hoort deze post daarom als terugkerende exploitatiekosten terug te komen, met afzonderlijke zichtbaarheid voor werkzaamheden rond koppelingen.
- Datamigratie, transformatie en validatie. Het kostbare scenario is het migreren en transformeren van alle vervuilde historische data. Daartegenover staat een afbakening waarin uitsluitend actieve stamdata wordt overgezet en het legacy-systeem read-only beschikbaar blijft voor auditdoeleinden. Dit is een afruil tussen de directe inspanning voor volledige gegevensverwerking en de kosten van het behouden van een toegankelijk archief. Neem dus niet alleen een migratiebedrag op, maar leg vast welke gegevens worden gevalideerd, welke data actief nodig blijft en welke historische gegevens uitsluitend raadpleegbaar blijven. Zonder die keuze is “datamigratie” een te brede budgetregel om de kosten werkelijk te toetsen.
Bronnen bij deze sectie: the cost of poor quality software in the us: a 2022 report, technical debt and it budgets
Welke variabelen beïnvloeden de kostenverhouding?
De kostenverhouding tussen patchen en maatwerk hangt niet alleen af van het bedrag van de volgende wijziging. Twee voorwaarden geven richting aan de beoordeling van voortgezet onderhoud: de resterende economische levensduur van het bedrijfsproces en de kwaliteit van de bestaande koppelingen. Voortgezet patchen of consolideren is rationeel verdedigbaar wanneer het proces naar verwachting minder dan twee à drie jaar resteert én de onderliggende API’s stabiel en volledig gedocumenteerd zijn. De termijn is hierbij een interne richtlijn, geen algemene norm.
De combinatie van die voorwaarden is bepalend. Een kort resterend proces maakt een omvangrijk vervangingsproject moeilijker te rechtvaardigen, omdat de investering minder lang aan dat proces kan worden toegerekend. Stabiele en volledig gedocumenteerde API’s beperken daarbij de onzekerheid rond voortgezet gebruik of consolidatie. Valt een van beide voorwaarden weg, dan verandert de afweging. Een proces met een langere resterende levensduur vraagt om een ander perspectief dan uitsluitend de kosten van het komende onderhoudsjaar. Evenzo is een korte levensduur geen vrijbrief om op onzekere koppelingen te blijven bouwen.
Een afzonderlijke keuze betreft de vorm van vervanging. Volledig procesgericht maatwerk, bijvoorbeeld een Laravel-webapplicatie, biedt volledige eigendom en controle over de oplossing. Standaard SaaS-software kan sneller starten, maar kan kwetsbare maatwerkkoppelingen en doorlopende licentiekosten per gebruiker vereisen. Dit is geen uitspraak dat één route altijd voordeliger is. Het maakt zichtbaar dat een snelle start niet hetzelfde is als een lage totale kostenlast gedurende de resterende levensduur van het proces.
Fasering verandert de kostenverhouding doordat zij de vervanging niet als één ondeelbare gebeurtenis behandelt. Bij een procesgericht maatwerkplatform kan de mate van eigendom en controle worden gewogen tegen de duur van de overgang. Bij SaaS verschuift de vergelijking naar licenties en de duurzaamheid van benodigde koppelingen. Voor een goedkeuringsronde ontstaat zo een scherpere vraag: sluit de gekozen vorm van verandering aan bij de resterende procesduur én bij de betrouwbaarheid van de interfaces waarop de organisatie voorlopig blijft leunen?
Welke scenario's illustreren de kostenverschillen?
Stel dat een maatwerkinvestering wordt afgewezen omdat de initiële CapEx zichtbaar hoger is dan een reeks kleine ingrepen. De organisatie kiest vervolgens voor ad-hoc plugins en scripts als lapmiddel. Zolang externe API’s niet wijzigen, blijft die aanpak ogenschijnlijk beheersbaar. Bij een wijziging in zo’n API kunnen koppelingen echter breken. De directe reactie bestaat uit noodreparaties en aanvullende inzet van freelancers. In het beschreven patroon overstijgen die cumulatieve uitgaven binnen 24 maanden het oorspronkelijke nieuwbouwtarief, terwijl migratierisico en technische schuld verdubbelen.
Dit scenario laat vooral zien waarom een vergelijking per afzonderlijke ingreep onvoldoende is. De oorspronkelijke afwijzing berust op het verschil tussen een zichtbare investering vooraf en verspreide onderhoudskosten daarna. Zodra de externe afhankelijkheid verandert, worden de eerder uitgestelde werkzaamheden spoedwerk. De kosten bestaan dan niet alleen uit de herstelactie, maar ook uit de opeenvolging van scripts, plugins en tijdelijke oplossingen die naast elkaar blijven bestaan. De financiële afwijking ontstaat dus door de samenloop van veranderende koppelingen en reactief herstel, niet doordat iedere individuele ingreep op zichzelf uitzonderlijk duur is.
Een alternatief scenario richt zich op de overgang zelf. Een gefaseerde ontkoppeling van een legacy-architectuur kan worden uitgevoerd met benaderingen zoals Strangler Fig en Anti-Corruption Layers, met minimale bedrijfsonderbreking als doel. Daarbij wordt niet verondersteld dat het oude systeem in één stap verdwijnt. Nieuwe onderdelen kunnen geleidelijk de rol van bestaande onderdelen overnemen, terwijl er een expliciete grens wordt ingericht tussen oud en nieuw. De kosten zijn dan niet alleen ontwikkelkosten; ook de tijdelijke inrichting die de overgang mogelijk maakt behoort bij de raming.
De twee scenario’s maken een verschillend risico zichtbaar. Ad-hoc verlenging verschuift de rekening naar het moment waarop een koppeling faalt. Gefaseerde ontkoppeling maakt tijdelijke overgangswerkzaamheden vooraf zichtbaar en richt zich op beperking van bedrijfsonderbreking. Voor de goedkeuring gaat het daarmee om een keuze tussen onvoorziene herstelkosten na een verstoring en expliciete kosten voor gecontroleerde vervanging.
Welke budgetregels moet je opnemen?
Maak van de goedkeuringsronde geen vergelijking tussen één bouwbedrag en één onderhoudsbedrag. Neem onderstaande regels op als expliciete onderdelen van dezelfde kostenraming.
- Scheid korte budgetzekerheid van Total Cost of Ownership. Incrementeel onderhoud wordt vaak als OpEx begroot en geeft op korte termijn een overzichtelijke uitgave. Een schaalbaar maatwerkplatform wordt als CapEx behandeld en vraagt een grotere initiële toewijzing. Leg deze twee vormen niet naast elkaar zonder de structurele run costs mee te nemen. De relevante afruil is korte budgetzekerheid tegenover de totale kosten op langere termijn. De beschikbare onderbouwing kwalificeert de structurele run costs van een schaalbaar maatwerkplatform als significant lager; behandel die verwachting als onderdeel van de raming, niet als een automatisch resultaat van ieder maatwerkproject.
- Begroot interne inzet per fase met een RACI- en capaciteitsmatrix. Neem niet alleen externe ontwikkel- en onderhoudsregels op. Een gedetailleerde RACI- en capaciteitsmatrix specificeert hoeveel uur interne materiedeskundigen en product owners per fase nodig zijn. Daarmee wordt zichtbaar wie verantwoordelijk is voor inhoudelijke input en hoeveel capaciteit die verantwoordelijkheid vraagt. Deze regel voorkomt dat interne reviews, besluitvorming en acceptatie buiten het financiële beeld vallen. De matrix biedt bovendien een concrete basis om fasen te vergelijken: een budget kan pas als uitvoerbaar gelden wanneer de aangewezen interne rollen de benodigde uren daadwerkelijk kunnen leveren.
Bronnen bij deze sectie: technical debt and it budgets, managing the consequences of technical debt: 5 stories from the field
Veelgestelde vragen over kostenvergelijking
Deze adapters kunnen de ontwikkelkosten met 15% tot 25% verhogen.
De meest gehoorde bezwaren gaan vaak over de zichtbare startkosten en de angst dat vervanging zelf meer verstoring veroorzaakt dan voortgezet onderhoud. De fasering van de overgang geeft daar een andere kostenlens voor.
- “Waarom lijkt patchen goedkoper, welke kosten missen we dan en wat doen integraties met de raming?” Patchen lijkt goedkoper wanneer de vergelijking stopt bij de eerstvolgende onderhoudsuitgave. Bij vervanging komen overgangswerkzaamheden juist eerder in beeld, vooral wanneer het oude en nieuwe landschap tijdelijk naast elkaar bestaan. Een Big Bang-vervanging in één release vermijdt zulke tijdelijke tussenlagen, maar blijft volgens de beschikbare afruil risicovol. Een gefaseerde migratie volgens het Strangler Fig-patroon verlaagt operationeel risico doordat onderdelen stapsgewijs kunnen worden vervangen. Daar staat een concrete tijdelijke kostenpost tegenover: synchronisatie-adapters. Deze adapters kunnen de ontwikkelkosten met 15% tot 25% verhogen. Die bandbreedte geldt specifiek voor deze gefaseerde aanpak met tijdelijke synchronisatie-adapters; zij is geen algemene opslag voor elke migratie. Het antwoord op de vraag over integraties is daarom niet dat zij altijd tot een Big Bang dwingen of altijd patchen duurder maken. Zij bepalen wel waar de kosten landen: vooraf als expliciete overgangsinrichting, of later als risico binnen een vervanging die in één release wordt uitgevoerd. In een budgetvergelijking hoort die keuze daarom naast de bouwkosten te staan. De financiële discussie wordt dan concreter: accepteert de organisatie het hogere operationele risico van één release, of reserveert zij geld voor tijdelijke adapters om de overgang gecontroleerd te faseren?
Belangrijke overwegingen bij de keuze voor maatwerk
Een besluit wordt beter toetsbaar wanneer de onzekerheden vooraf worden onderzocht en vervolgens zichtbaar worden toegewezen aan scope, planning en budget. De voorbereiding van een voorstel verdient daarom dezelfde aandacht als de keuze voor patchen of vervanging.
- Vraag vóór een bindend voorstel om onderzoek naar code en data. Een formele Discovery of een code- en data-audit voorafgaand aan een bindend voorstel maakt migratie- en integratierisico’s transparant prijsbaar. Dat verandert de goedkeuringsronde van een vergelijking tussen aannames in een vergelijking tussen benoemde onzekerheden. De audit richt zich niet op een algemeen oordeel over het bestaande systeem, maar op de factoren die later het budget kunnen wijzigen: de toestand van de code, de gegevens die moeten worden meegenomen en de koppelingen die tijdens de overgang een rol spelen. Wanneer deze punten pas na ondertekening worden onderzocht, blijft het voorstel weliswaar eenvoudiger, maar verschuift de financiële discussie naar het moment waarop afwijkingen al moeten worden opgelost. Een voorafgaande Discovery biedt ruimte om de omvang van migratie en integratie te begrenzen voordat een bedrag bindend wordt. Daarmee ontstaat ook een heldere verdeling tussen wat binnen het voorstel valt en welke onzekerheden nog een expliciete aanname of reserve vragen. De concrete grens blijft dat een bindend budget zonder voorafgaande beoordeling van code en data migratie- en integratierisico’s niet transparant kan inprijzen.
