Software lifecycle management, de verborgen kosten van uitstel

“We gaan pas migreren als Java 8 echt niet meer ondersteund wordt.” Dit soort uitspraken hoor ik nogal eens als ik met IT-managers praat. Hun platform draait stabiel, er zijn geen directe problemen, dus waarom tijd en budget besteden aan een upgrade?

Tot het moment dat ze ontdekken dat hun leverancier niet langer nieuwe functionaliteiten ontwikkelt voor hun versie. Of dat beveiligingspatches niet meer beschikbaar zijn.

Dan wordt upgraden ineens urgent. Contracten lopen af, beveiligingseisen verscherpen, leveranciers stoppen met de support. Wat de afgelopen jaren had kunnen worden opgelost, moet nu binnen een paar maanden gebeuren.

Dit scenario herken ik uit de gemeentemarkt: organisaties die jarenlang hebben gewacht terwijl ze eigenlijk best wisten dat ze moesten upgraden. Nu worden ze plotseling geconfronteerd met nieuwe spelregels. 

En ineens zijn er nieuwe spelregels

Organisaties die jarenlang oude Java-versies lieten draaien, kregen in januari 2023 een onverwachte rekening. Oracle veranderde zijn licentiemodel drastisch - van betalen per gebruiker naar betalen per werknemer.

Had je eerder geüpgraded naar nieuwere Java-versies of was je overgestapt op open source-alternatieven, dan ontliep je deze kostenexplosie. Maar organisaties die waren blijven hangen op oude versies en daardoor afhankelijk waren van commerciële support, zaten opeens vast aan een veel duurder contract.

Dit laat perfect zien waarom uitgesteld onderhoud zo gevaarlijk kan zijn: wat begint als een kostenbesparende maatregel (niet upgraden) wordt opeens een financiële valkuil.

Maar dit is nog maar het topje van de ijsberg.

Software veroudert sneller dan je denkt

Het Oracle-probleem is geen uitzondering. Hetzelfde patroon zie ik bij een heleboel andere technologieën. Organisaties stellen upgrades uit, worden afhankelijk van verouderde versies en lopen tegen dezelfde problemen aan.

PostgreSQL 12 bereikte end-of-life in november 2024, maar 11 procent van alle PostgreSQL-databases draait nog steeds op deze versie die niet meer wordt ondersteund. Deze organisaties krijgen geen beveiligingspatches meer en kunnen problemen niet meer laten oplossen door de community. Python 3.8 verloor in oktober 2024 alle ondersteuning. Dit raakt veel gemeentelijke websites, data-analyse tools en automatiseringsscripts die vaak op Python draaien. Applicaties die hierop blijven draaien, worden steeds kwetsbaarder voor aanvallen en externe auditors zullen dit als beveiligingsrisico aanmerken. 

Tegelijk worden software-cycli steeds korter. Waar je vroeger jaren had om een migratie voor te bereiden, is het nu eerder een kwestie van maanden. En de gevolgen van uitstellen worden steeds groter: beveiligingsrisico's, compatibiliteitsproblemen, verlies van support van de leverancier.

Onzichtbare problemen kunnen toch héél veel geld kosten

Hardware veroudert op den duur, dat is logisch. Dat dat ook voor software geldt, heeft het management vaak minder goed in de gaten. Bij een kapotte printer zie je direct dat er iets mis is. Software blijft gewoon draaien. Totdat het dat niet meer doet.

“Het werkt toch nog? Waarom zouden we tijd en geld besteden aan iets wat niet kapot is?” Het is een begrijpelijke gedachte. Tot het moment dat systemen offline gaan door een beveiligingslek. Of tot het moment dat de leverancier de stekker eruit trekt.

60 procent van alle datalekken komt voort uit systemen die niet zijn gepatcht. En de gemiddelde kosten van zo'n datalek? Die loopt al snel in de miljoenen euro’s. Voor een gemeente betekent dit niet alleen geld, maar ook reputatieschade bij burgers. 

Reactief onderhoud kost drie keer zo veel als proactief onderhoud

Waarom? Omdat je onder tijdsdruk werkt. Omdat je dure consultants moet inhuren die beschikbaar moeten zijn voor spoedklussen. Omdat je systemen misschien offline moeten voor een noodmigratie. Omdat je fouten maakt die later nog duurder zijn om op te lossen.

Een migratie die je rustig in een jaar had kunnen plannen, wordt opeens een crisisoperatie van drie maanden.

En onder tijdsdruk heb je geen tijd meer om van leverancier te wisselen. Je zit vast aan hun nieuwste versie. Leveranciers weten dat je in deze zwakke positie zit. Ze kunnen hun prijzen verhogen omdat overstappen nu te complex en tijdrovend is geworden. Je bent afhankelijk van hun planning, hun prioriteiten, hun roadmap.

De strategische waarde van software lifecycle management

Het probleem is dat veel organisaties software lifecycle management niet als strategische prioriteit zien.

Organisaties die hier goed in zijn, reserveren structureel tijd voor updates. Bijvoorbeeld een aantal uren per maand, zoals je telefoon ook regelmatig updates krijgt. Ze plannen migraties ruim van tevoren in plaats van te wachten op harde deadlines.

Ze maken bewuste keuzes over welke technologieën ze gebruiken. Open source-alternatieven kunnen soms hetzelfde bieden als dure commerciële software. En dat zonder vendor lock-in.

En vooral: ze zien softwareonderhoud niet als kostenpost, maar als investering in stabiliteit en veiligheid.

Als je daarbij samenwerkt, voorkom je ook nog eens dubbel werk. Bij gemeenten zie ik mooie voorbeelden van samenwerking. Waarom zou elke gemeente zelf uitzoeken hoe je een migratie doet? Deel kennis, deel kosten, deel risico's.

De tijd om te handelen is nu

Software lifecycle management wordt alleen maar belangrijker. Support-tijdlijnen worden korter. Beveiligingseisen strenger. En leveranciers worden creatiever met hun prijsmodellen.

De vraag is niet óf je software moet gaan updaten. De vraag is wanneer je het gaat doen, en of je het proactief of reactief doet.

Drie keer zo duur, weet je nog?

Klaar om de controle terug te pakken over je software lifecycle?

Bij WeAreFrank! hebben we jaren ervaring met complexe migraties, van Java-updates tot complete platformwissels. We hebben het Frank!Framework zelf succesvol gemigreerd naar de nieuwste Java-standaarden.

We helpen organisaties niet alleen met de technische kant van migraties, maar ook met strategische planning. Want de beste migratie is degene die je plant voordat je in de problemen zit.

Benieuwd hoe wij jouw software lifecycle management kunnen versterken? Plan een gratis strategiesessie in.

Vragen over deze case?
Neem contact op
Portrait of Jaco de Groot

Geschreven door
Jaco de Groot