Een e-book van een softwarebedrijf dat uitlegt wanneer je géén migratie moet starten? Net dat hoofdstuk hoort erin. Eerlijkheid boven comfort: niet elke J2EE-applicatie moet weg. En een migratie op het verkeerde moment richt meer schade aan dan stilstand.
Vier situaties waarin je beter pauzeert.
Het systeem is stabiel én verandert nauwelijks
Een applicatie die haar werk doet, hooguit een paar kleine wijzigingen per jaar krijgt en binnen afzienbare tijd functioneel vervangen of uitgefaseerd wordt, verdient geen migratie. Ze verdient een gecontroleerd levenseinde.
De verstandige investering is dan risicobeheersing: security-patching op orde, kennis documenteren, een exitplan. In migratietermen: retain of retire, bewust behouden of uitfaseren.
Retain betekent nooit "niets doen"
Blijven updaten is daarbij geen detail, ook niet voor een systeem dat je bewust behoudt. Wie binnen de supported range van runtime, server en bibliotheken blijft, dicht een relevante CVE in dagen. Wie jaren achterloopt op de laatste versie die nog patches krijgt, betaalt bij het eerstvolgende ernstige lek maanden werk om überhaupt te kúnnen patchen.
Even bij stilstaan:
"Het verandert toch nooit" is soms zelfbedrog: een gevolg van het feit dat veranderen te duur geworden is, niet van het ontbreken van behoefte. Vraag de business wat ze zou willen als wijzigingen goedkoop waren. Het antwoord vertelt je in welke categorie het systeem écht valt.
De motivatie is technologisch, niet zakelijk
"Het team wil graag met Kubernetes werken." "Iedereen praat over microservices." Dat zijn signalen om te pauzeren. Architectuurkeuzes gedreven door wat goed staat op een cv zijn een reëel fenomeen. En een dure hobby.
De toets is simpel: kun je in één zin uitleggen welk bedrijfsprobleem de migratie oplost? En herkent de business dat probleem? Zo niet, dan is het huiswerk niet af.
Dit is hoofdstuk 4 van 14
Het e-book bevat ook het beslissingskader voor Spring Boot, Quarkus en moderne Jakarta EE-runtimes, het technische draaiboek, een hoofdstuk over AI in je migratie en een roadmap in vier fasen. Gratis, drie velden, de PDF opent meteen.
Stuur me het e-bookDe organisatie is er niet klaar voor
Een moderne architectuur veronderstelt dat je ze ook kunt exploiteren: geautomatiseerde pijplijnen, monitoring, teams die hun eigen services beheren. Wie microservices deployt met de processen van een klassiek legacy-systeem, één centrale releasekalender en handmatige changeprocedures, krijgt de nadelen van beide werelden.
Eerst de omgeving, dan pas het framework
Soms is de juiste eerste stap dus geen frameworkmigratie, maar het moderniseren van wat rond het bestáánde systeem staat: het platform en de pijplijn, de manier waarop de developmentteams georganiseerd zijn en de ondersteuning die ze van dat platform krijgen. Dat levert direct waarde op. En het legt het fundament waarop een latere migratie kan slagen.
Alles tegelijk willen
Een frameworkmigratie plus een cloudmigratie plus microservices plus een organisatieverandering, in één project? Dat is het recept voor jaren zonder tussentijdse waarde.
De vuistregel: verander niet meer dan één grote dimensie tegelijk per stap. Eerst het deploymentmodel, daarna pas de architectuur opknippen. Dat is bijna altijd veiliger dan beide ineens. En vaak blijkt na de eerste stap dat de tweede kleiner kan dan gedacht.
Wachten is ook een beslissing
Dit hoofdstuk is géén pleidooi voor uitstel. De risico's van legacy, de talentklok, de securitydruk en de groeiende kloof met wat de organisatie nodig heeft, verdwijnen niet door te wachten. Ze groeien.
Maar de conclusie "we migreren" verdient dezelfde kritische toets als de conclusie "we wachten". Het instrument daarvoor is een gestructureerde assessment: die vertelt je per applicatie of behouden, opwaarderen, migreren of uitfaseren de verstandigste route is.
< Kerninzichten />
- Stabiele systemen met een eindige horizon verdienen risicobeheersing en een exitplan, geen migratie.
- Zonder benoembaar bedrijfsprobleem is een migratie een hobby. Zonder organisatorische basis (pijplijn, monitoring, ownership) is ze een gok.
- Wachten is óók een beslissing met kosten: neem ze even bewust als de beslissing om te migreren.
< Vragen voor het management />
- Voor welke systemen in ons landschap is "gecontroleerd uitdoven" eerlijker dan "moderniseren"?
- Als we vandaag niet migreren: wat is dan ons plan voor patching, kennisborging en exit?
< Uit het e-book />
Evolueer, herschrijf niet
Legacy Java moderniseren met Spring Boot en Quarkus, zonder je business te verstoren. Veertien hoofdstukken voor IT-beslissers en architecten, geschreven door Pieter Vercammen, Managing Partner en Tech Lead van CraftCode. Met een beslissingskader voor de frameworkkeuze, het strangler fig-patroon, een technisch draaiboek, de rol van AI en een roadmap in vier fasen. Bijlage A is een assessment-checklist die je op je eigen landschap kunt loslaten.
Dit hoofdstuk verscheen integraal en ongewijzigd, op de tussenkoppen na.< FAQ />