In veel Belgische overheidsinstanties wordt het moderniseren van deployment pipelines nog steeds behandeld als een eenmalige gebeurtenis in plaats van een continue praktijk. Naar productie gaan blijft een riskante operatie die meerdere teams mobiliseert, onderhoudsvensters vereist en soms een service blokkeert totdat alles weer tot rust is gekomen. Ontwikkelaars leveren hun code, en dan wachten ze.
Deze muur tussen de ontwikkeling en productie heeft een reële kostprijs. Niet alleen in vertragingen, maar ook in vertrouwen: hoe meer je elke release vreest, hoe minder je er doet, en hoe moeilijker het wordt om continu te leveren.
We werkten samen met een grote Belgische federale openbare instelling aan een volledige modernisering van hun deployment-pipeline. Het resultaat: 98% applicaties gemigreerd naar het nieuwe platform, nul downtime in productie en ontwikkelingsteams die echt autonoom zijn van code tot productie. Dit artikel beschrijft wat we hebben gedaan, en belangrijker nog, de keuzes die ons in staat stelden dit te bereiken zonder een Big Bang.
Bron voor de genoemde cijfers: 5th floor, klantcase “Van code naar productie, volledig autonoom”, 2026. Neem voor meer informatie contact met ons op via sales@5thfloor.be.
Het startpunt: silo's, handmatige implementaties, JBoss-applicaties
De instelling had enkele duizenden medewerkers en tientallen bedrijfstoepassingen. Op papier een solide IT-organisatie. In de praktijk kwamen bij elke release vijf structurele blokkades naar boven:
- Een strikte scheiding tussen ontwikkelaars en het team dat verantwoordelijk is voor productiedeployments. Code wordt van de ene naar de andere doorgegeven, met verschillende tijdlijnen en prioriteiten bij elke stap.
- Handmatige implementaties, traag en foutgevoelig.
- Er is geen garantie dat wat in de test gevalideerd was, exact hetzelfde was wat naar productie is verzonden.
- Een verouderde JBoss-basis, moeilijk te laten evolueren.
- Geen vangnet als er iets misging: terugdraaien was een operatie op zich, zonder automatisering.
Dit zien we regelmatig terug in de publieke sector. Niet omdat teams de vaardigheden missen, maar omdat de organisatie en tooling niet hebben meegroeid met de toenemende complexiteit van het applicatieportfolio.
Waarom hebben we niet alles herschreven
De verleiding, geconfronteerd met een situatie als deze, is het volledige herbouwproject. Het bestaande systeem bevriezen, een grote parallelle migratie uitvoeren en dan in één keer overschakelen. De befaamde Big Bang.
Op papier is het aantrekkelijk. In de praktijk mislukt het vaak. Tijdens het webinar van de EU AI Week 2026, gepresenteerd door onze medeoprichter Gilles Stragier op 19 maart 2026, waren de cijfers over Big Bang herschrijfprojecten veelzeggend: ongeveer 70% overschrijden het budget of de planning, 17% worden halverwege geannuleerd.
Transparantiestatement: deze ordegroottes werden genoemd tijdens onze interne webinar. Voor externe publicatie raad ik aan om de primaire bron (Standish Group / CHAOS Report of gelijkwaardig) terug te traceren voordat u ze preciezer citeert.
We hebben een andere keuze gemaakt: applicatie per applicatie migreren, de nieuwe pijplijn bouwen bovenop de tools die de teams al gebruikten, en de productie gedurende de hele periode live houden. Een transitie, geen transformatie.
Het platform: containerisatie, OpenShift, Helm
Hier is wat is geïmplementeerd:
- Docker-containerisatie van toepassingen. Eenmaal gebouwd, overal identiek ingezet. Geen afwijkingen meer tussen test- en productieomgevingen.
- Orchestratie via OpenShift, gekozen vanwege de afstemming met de beveiligingseisen van de publieke sector en de betrouwbaarheid op schaal.
- Helm Charts op maat. Elke nieuwe applicatie erft automatisch monitoring (Grafana), gecentraliseerde logging (Kibana) en beveiliging (Keycloak). Geen handmatige herconfiguratie meer voor elk project.
- Een zero-downtime-mechanisme. De nieuwe versie komt op de achtergrond, en de overgang gebeurt pas zodra de implementatie is gevalideerd. Als er iets misgaat, blijft de huidige versie actief. Geen enkele gebruiker merkt er iets van.
- Een bibliotheek van herbruikbare scripts geïntegreerd in Bamboo en Bitbucket, de tools die de teams al kenden. Pipeline templates, image-promotie tussen omgevingen, geautomatiseerde deployment.
- Tijdelijke testomgevingen. Elke geautomatiseerde testronde draait in zijn eigen omgeving, die on-the-fly wordt aangemaakt en na gebruik wordt vernietigd, zonder inmenging tussen teams. Wat de tests valideren, is precies wat naar productie gaat.
En een punt dat vaak over het hoofd wordt gezien: database migraties en beveiligingsconfiguraties worden automatisch vanuit de applicatie zelf toegepast, zonder menselijke tussenkomst.
De cijfers na migratie
Binnen het bereik dat door dit platform wordt gedekt, is hier wat het vandaag produceert
| 98% | 100% | 0 | Automatische terugdraaiing |
| van applicaties draaien op het nieuwe platform, waaronder legacy JBoss-applicaties, die in een tweede fase worden gecontaineriseerd. | applicaties automatisch profiteren van monitoring, beveiliging en database migraties via de Helm Charts. | downtime tijdens productiedeployments. | in geval van storing, zonder handmatige tussenkomst. |
Deze resultaten behoren tot een specifiek project, in een specifieke context. Het repliceren van deze resultaten elders vereist een beoordeling van de context van elke organisatie. Zie het gedeelte “Voor wie is dit bedoeld?” hieronder.
Wat echt het verschil maakte (en het was niet de technologie)
Als ik drie dingen uit dit project mocht behouden, zouden geen van beide technisch zijn.
Eerst, de keuze om voort te bouwen op wat bestond in plaats van een nieuwe stack op te leggen. Bamboo en Bitbucket waren al aanwezig. In plaats van ze te vervangen, hebben we ze uitgebreid. Ontwikkelaars hoefden niet alles opnieuw te leren, wat de klassieke weerstand tegen transformatieprojecten vermeed.
Vervolgens, co-creatie. Elke steen van het platform (pipelines, Helm Charts, deployment scripts) is samen met de ontwikkelingsteams gebouwd, niet voor hen. Het verschil is merkbaar in het dagelijks gebruik: teams nemen eigenaarschap van wat ze hebben helpen ontwerpen.
Tenslotte, autonomie als dagelijks doel, niet als eindresultaat. Tegen het einde van het project testen, bouwen en implementeren ontwikkelaars zichzelf. De automatische beveiligingen (tests, rollback, monitoring) nemen het over van menselijke controles. De muur tussen dev en prod is verdwenen en niemand verloor zijn baan. Het team dat historisch verantwoordelijk was voor implementaties zag hun werk verschuiven naar platformexpertise en coaching, in plaats van repetitieve uitvoering.
Voor wie is dit?
Deze aanpak werkt wanneer aan bepaalde voorwaarden is voldaan. Een intern IT-team dat groot genoeg is om eigenaarschap te nemen van het platform. De bereidheid van het management om te investeren in autonomie van het team, niet alleen om deze uit te roepen. Bestaande tools die kunnen worden geëvolueerd in plaats van weggegooid.
Als de context sterk verschilt (minimaal IT-team, grote afhankelijkheid van een enkele integrator, applicatieportfolio verspreid over meerdere leveranciers zonder gedeeld bestuur), is hetzelfde recept niet zomaar van toepassing. Je moet je aanpassen, soms beginnen met andere werkstromen (bestuur, teamstructurering) vóór de technische modernisering.
Dat is ook waarom we spreken van transitie in plaats van transformatie: een geleidelijke beweging, verankerd in de realiteit van elke organisatie.
FAQ
Verder gaan
Dit project maakt deel uit van onze IT-missie benadering, een van de drie pijlers van 5th floor naast L4F (applicatie portfolioanalyse en -sturing met AI) en organisatorische en culturele transformatie.
5th floor is sinds 2017 partner in de digitale transformatie van Belgische publieke instellingen, en sinds 2025 B Corp gecertificeerd (score 89.5, openbare beoordeling beschikbaar).
Als u uw situatie herkent in dit bericht (een muur tussen dev en prod, implementaties die mensen bang maken, of de wens om te moderniseren zonder te weten waar te beginnen), neem dan contact op. Een gesprek van een uur is vaak voldoende om de eerste aanzetten uit te stippelen.
