Het systeem werkt nog.Precies daarom is het riskant.
Breng een verouderd Java-systeem stap voor stap up-to-date, zonder alles te herschrijven en terwijl uw bedrijf er gewoon op blijft draaien.
Ergens in uw organisatie staat een toepassing die niemand wil aanraken. Ze verwerkt elke dag bestellingen, facturen, planning of klantgegevens. Ze draait op een Java-versie die al jaren geen beveiligingsupdates meer krijgt, de enige collega die nog weet hoe, rolt ze met de hand uit, en elke wijziging duurt langer dan de vorige omdat niemand iets anders durft aan te raken. Ze vervangen is al vaak besproken en telkens uitgesteld, want het bedrijf kan niet stilvallen terwijl er een nieuwe gebouwd wordt.
Wij moderniseren dat systeem ter plaatse. Eerst leggen we het bestaande gedrag vast met tests. Daarna brengen we runtime, frameworks en afhankelijkheden module per module naar actuele, ondersteunde versies, en automatiseren we deployment, monitoring en back-ups, zodat de toepassing niet langer afhangt van het geheugen van één persoon. Uw gebruikers werken ondertussen gewoon door. Elke fase gaat afzonderlijk naar productie, en u kunt pauzeren voor de volgende start.
Het resultaat is geen nieuw systeem met nieuwe bugs en een opleidingstraject. Het is het systeem dat uw mensen al kennen, op ondersteunde software, met een releaseproces dat elke engineer kan uitvoeren en code die uw volgende aanwerving kan lezen. Is een herschrijving van een onderdeel toch goedkoper, dan staat dat in de analyse, met de redenering erbij.
Wanneer dit de juiste keuze is
- Uw toepassing draait op een Java- of Spring-versie zonder beveiligingsupdates, en uw auditor of verzekeraar stelt er vragen over.
- Eén persoon weet hoe het systeem gebouwd, uitgerold of gedebugd wordt. Een vakantie of ontslag zou elke correctie blokkeren.
- Elke wijziging vraagt weken manueel regressietesten omdat er geen geautomatiseerde tests zijn, dus kleine vragen blijven maanden liggen.
- De database is tien jaar lang organisch gegroeid: ongebruikte tabellen, ongedocumenteerde kolommen, triggers die niemand begrijpt en een schema dat elke nieuwe functie tegenwerkt.
- U wilt de toepassing naar containers of de cloud brengen, maar ze verwacht nog altijd een handmatig ingestelde server en lokale bestanden.
Wat u krijgt
Een schriftelijke analyse en een gefaseerde roadmap
Een inventaris van wat het systeem bevat, de risico’s gerangschikt naar waarschijnlijkheid en impact, en een gefaseerd plan met per fase een raming waarvan de aannames erbij staan. Elke fase is op zichzelf al nuttig.
Een vangnet van tests rond het bestaande gedrag
Karakteriseringstests op basis van wat de toepassing vandaag doet, geschreven voor er iets verandert, als JUnit-tests die bij elke commit draaien. Verandert een upgrade een berekening of rapport, dan merkt u het aan de tests voor uw gebruikers het merken.
Actuele runtimes, frameworks en afhankelijkheden
Java op een long-term-support-release, Spring Boot op een ondersteunde versie, en externe bibliotheken bijgewerkt en in de build gescand op kwetsbaarheden. Module per module, en elke stap gecontroleerd in productie voor de volgende begint.
Herhaalbare builds, deployment en monitoring
De toepassing verpakt als Docker-image, gebouwd en uitgerold via CI/CD in plaats van met de hand, op Kubernetes of een eenvoudige containerhost, naargelang wat uw schaal rechtvaardigt. Monitoring, alerting, logs en geteste back-ups horen erbij.
Een opgeschoonde datalaag en ingeoefende overschakelingen
Schema- en datamigraties in PostgreSQL onder versiebeheer, ingeoefend op een kopie van productie, met een gedocumenteerde rollback voor elke overschakeling. Draait het systeem op een andere database, dan zegt de analyse of een overstap loont.
Hoe het werkt
Analyseren
Wij lezen de code, de database en de deploymentopzet, en praten met wie het systeem beheert. U krijgt een schriftelijk rapport en een gefaseerde roadmap.
Stabiliseren
Voor elke upgrade maken we de build reproduceerbaar en dekken karakteriseringstests het gedrag dat ertoe doet. Het systeem hangt niet langer af van één persoon.
Moderniseren in fasen
Upgrades landen module per module, en elke module wordt in productie gecontroleerd voor de volgende. Een monoliet splitsen we enkel op waar dat zichzelf terugbetaalt.
Overdragen of blijven
Na elke fase staan de code, pipelines en documentatie in uw accounts. Uw team neemt over, of wij blijven voor de volgende fase.
De technologie erachter
Kotlin & Java
Spring Boot
PostgreSQL
React & TypeScript
Docker & Kubernetes
CI/CD
Monitoring & alerting
Hetzner, AWS, Azure & DigitalOcean
Hoe een samenwerking er meestal uitziet
Eerst een analyse die de risico’s en een gefaseerde roadmap in kaart brengt, daarna uitvoering in fasen. Tussen de fasen kunt u pauzeren, terwijl het bestaande systeem blijft draaien. De analyse gebeurt aan een vaste prijs en levert een schriftelijk rapport op. Elke volgende fase ramen wij apart, met de aannames erbij, zodat u zich telkens voor één fase vastlegt en niet voor de hele roadmap. Fasen rekenen wij aan per gewerkte dag, binnen een plafond dat schriftelijk is afgesproken.
Vragen die u misschien hebt
Hoe prijzen jullie dit? Een herschrijving zou met één bedrag komen.
De analyse gebeurt aan een vaste prijs en levert een schriftelijk rapport op. Elke fase van de roadmap ramen wij daarna afzonderlijk, met de aannames erbij, en u beslist fase per fase of u verdergaat. Dat is bewust anders dan één bedrag voor een herschrijving: zo wordt de grootste onbekende, de omvang van het werk, niet vooraf gegokt en later in verrassingen betaald. Het systeem blijft de hele tijd draaien, dus u betaalt nooit voor twee systemen tegelijk. Elke fase rekenen wij aan per gewerkte dag, binnen een schriftelijk afgesproken plafond. Is het systeem gemoderniseerd, dan kan het bij ons blijven onder een maandelijkse overeenkomst.
Van wie zijn de code, de pipelines en de infrastructuur daarna?
Van u. De code staat vanaf de eerste commit in uw repositories, en de intellectuele eigendom van het geleverde werk gaat bij betaling naar u over. Alles draait in uw cloud- of hostingaccounts en is gedocumenteerd in begrijpelijke taal. Er zit geen tooling, licentie of hostinglaag van ons tussen. Beslist u het werk intern te houden of naar een andere leverancier te brengen, dan krijgen zij een systeem met tests, een werkende pipeline en een schriftelijk ontwerp, zonder afhankelijkheid van Experus.
Wat als de engineer van Experus niet beschikbaar is, of de samenwerking stopt?
Daar gaan wij bij het werk van uit. Elke wijziging staat in versiebeheer met een leesbare geschiedenis, build en deployment zijn geautomatiseerd in plaats van onthouden, en ontwerpbeslissingen schrijven we uit op het moment dat ze genomen worden. Zo kan elke bekwame Java- of Kotlin-engineer het systeem overnemen vanuit de repository en de documentatie. Elke opdracht heeft schriftelijk afgesproken data. Halen wij die niet, dan hoort u dat meteen en kiest u: herplannen, of stoppen en enkel betalen wat geleverd is. Lopend werk staat vanaf dag één in uw repositories en accounts, dus er gaat niets verloren op een laptop. Is de engineer op uw project langer afwezig, dan kan een vertrouwde specialist uit ons netwerk het overnemen, met uw akkoord.
Hoe lang duurt het?
Dat hangt af van de omvang van het systeem, hoe ver het achterloopt en hoeveel van zijn gedrag gedocumenteerd is. Het eerlijke antwoord bestaat pas na de analyse. Wel kunnen we vooraf zeggen waar de tijd naartoe gaat. De eerste fase, de build reproduceerbaar maken en tests rond het bestaande gedrag zetten, is het fundament voor al de rest, en maakt het systeem ook veiliger om met rust te laten als u moet pauzeren. Daarna landen upgrades module per module in productie, zodat u de hele tijd vooruitgang ziet in uw eigen omgeving in plaats van te wachten op één grote go-live.
Ontdek wat het systeem echt draagt
Beschrijf de toepassing, hoe oud ze ongeveer is en waarover u zich zorgen maakt. Wij antwoorden met enkele vragen en, als het past, een voorstel voor een analyse. Zonder verplichting, en met een duidelijk antwoord als modernisering niet de juiste stap is.