Van code naar productie zonder onderbrekingen

Bij veel Belgische overheidsinstanties wordt de modernisering van de implementatiepijplijn nog steeds gezien als een eenmalige gebeurtenis in plaats van een doorlopend proces. De overgang naar productie blijft een risicovolle operatie waarbij meerdere teams worden ingezet, onderhoudsvensters nodig zijn en een dienst soms wordt geblokkeerd totdat alles weer op zijn plaats valt. Ontwikkelaars leveren hun code af en wachten vervolgens af.

Deze scheiding tussen ontwikkeling en productie brengt reële kosten met zich mee. Niet alleen in de vorm van vertragingen, maar ook wat betreft het vertrouwen: hoe meer je tegen elke release opziet, hoe minder releases je doet, en hoe moeilijker het wordt om continu te leveren.

We hebben samen met een grote Belgische federale overheidsinstelling gewerkt aan een volledige modernisering van haar implementatiepijplijn. Het resultaat: 98% van de applicaties is gemigreerd naar het nieuwe platform, geen downtime in de productieomgeving en ontwikkelteams die werkelijk autonoom zijn, van code tot productie. In dit artikel wordt uitgelegd wat we hebben gedaan, en nog belangrijker: welke keuzes ervoor hebben gezorgd dat we dit resultaat konden bereiken zonder een ‘Big Bang’.

Bron: 5th floor, klantcase „Van code tot productie, volledig zelfstandig”, 2026. Neem voor meer informatie contact met ons op via sales@5thfloor.be.

Download de PDF

Het uitgangspunt: silo’s, handmatige implementaties, JBoss-toepassingen

De instelling had enkele duizenden medewerkers en tientallen bedrijfsapplicaties. Op papier een solide IT-organisatie. In de praktijk kwamen bij elke release vijf structurele knelpunten naar voren:

• Een strikte scheiding tussen ontwikkelaars en het team dat verantwoordelijk is voor de implementatie in productie. De code wordt van de ene naar de andere groep doorgegeven, waarbij elke stap zijn eigen tijdschema en prioriteiten heeft.
• Handmatige implementaties: traag en foutgevoelig.
• Er was geen garantie dat wat tijdens de tests was gevalideerd, precies overeenkwam met wat naar de productieomgeving werd verzonden.
• Een verouderde JBoss-basis, die moeilijk verder te ontwikkelen is.
• Er was geen vangnet als er iets misging: het terugdraaien was een bewerking op zich, zonder automatisering.

Dit patroon zien we regelmatig in de publieke sector. Niet omdat teams over onvoldoende vaardigheden beschikken, maar omdat de organisatie en de gebruikte tools geen gelijke tred hebben gehouden met de toenemende complexiteit van de applicatieportefeuille.

Waarom we niet alles opnieuw hebben geschreven

De verleiding in een dergelijke situatie is om voor een volledige heropbouw te kiezen. Het bestaande systeem bevriezen, een grootschalige parallelle migratie uitvoeren en vervolgens in één keer overschakelen. De beroemde ‘Big Bang’.

Op papier klinkt het aantrekkelijk. In de praktijk loopt het vaak mis. Zoals Gilles Stragier op 19 maart 2026 tijdens zijn webinar in het kader van de EU AI Week 2026 vertelde, spreken de cijfers uit de sector over ‘Big Bang’-herschrijfprojecten boekdelen: ongeveer 70% overschrijdt het budget of de planning, en 17% wordt halverwege stopgezet.

We hebben voor een andere aanpak gekozen: applicatie voor applicatie migreren, de nieuwe pijplijn opbouwen op basis van de tools die de teams al gebruikten, en de productie gedurende het hele proces in de lucht houden. Een overgang, geen transformatie.

Het platform: containerisatie, OpenShift, Helm

Dit is wat er is ingevoerd:

• Containerisatie van applicaties met Docker. Een image dat één keer wordt gebouwd en vervolgens overal op identieke wijze wordt geïmplementeerd. Geen verschillen meer tussen test- en productieomgevingen.

• Orchestratie via OpenShift, gekozen vanwege de aansluiting bij de beveiligingseisen van de publieke sector en de betrouwbaarheid op grote schaal.

• Aangepaste Helm-charts. Elke nieuwe applicatie beschikt automatisch over monitoring (Grafana), gecentraliseerde logboekregistratie (Kibana) en beveiliging (Keycloak). Handmatige herconfiguratie per project is niet langer nodig.

• Een mechanisme zonder uitvaltijd. De nieuwe versie wordt op de achtergrond opgestart en de omschakeling vindt pas plaats nadat de implementatie is gevalideerd. Als er iets misgaat, blijft de huidige versie actief. Gebruikers merken er niets van.

• Een bibliotheek met herbruikbare scripts die is geïntegreerd in Bamboo en Bitbucket, de tools waarmee de teams al vertrouwd waren. Pipelinesjablonen, het doorvoeren van images tussen omgevingen, geautomatiseerde implementatie.

• Tijdelijke testomgevingen. Elke geautomatiseerde testsessie draait in een eigen omgeving, die direct wordt aangemaakt en na gebruik weer wordt verwijderd, zonder dat er sprake is van interferentie tussen teams. Wat de tests valideren, is precies wat naar de productieomgeving wordt doorgegeven.

En een punt dat vaak over het hoofd wordt gezien: databasemigraties en beveiligingsconfiguraties worden automatisch vanuit de applicatie zelf doorgevoerd, zonder dat er menselijke tussenkomst nodig is.

De cijfers na de migratie

Wat betreft het toepassingsgebied van dit platform: dit is wat het momenteel oplevert

Deze resultaten hebben betrekking op een specifiek project, binnen een specifieke context. Om ze elders te kunnen toepassen, moet de context van elke organisatie worden beoordeeld. Zie het gedeelte ‘Voor wie is dit bedoeld?’ hieronder.

Wat echt het verschil maakte (en dat was niet de technologie)

Ten eerste de keuze om voort te bouwen op wat er al was, in plaats van een nieuwe stack op te leggen. Bamboo en Bitbucket waren al in gebruik. In plaats van ze te vervangen, hebben we ze uitgebreid. Ontwikkelaars hoefden niet alles opnieuw te leren, waardoor de klassieke weerstand tegen transformatieprojecten werd voorkomen.

Vervolgens: gezamenlijke ontwikkeling. Elk onderdeel van het platform (pijplijnen, Helm Charts, implementatiescripts) is samen met de ontwikkelteams gebouwd, niet voor hen. Dat verschil merk je in het dagelijks gebruik: teams nemen verantwoordelijkheid voor wat ze zelf hebben helpen ontwerpen.

Ten slotte: autonomie als dagelijkse doelstelling, niet als eindresultaat. Tegen het einde van het project testen, bouwen en implementeren ontwikkelaars alles zelf. De automatische beveiligingsmaatregelen (tests, rollback, monitoring) nemen de plaats in van handmatige controles. De scheiding tussen dev en prod is verdwenen, en niemand is zijn rol kwijtgeraakt. Het team dat van oudsher verantwoordelijk was voor implementaties, zag zijn werkzaamheden verschuiven naar platformkennis en coaching, in plaats van repetitieve uitvoering.

Voor wie is dit bedoeld?

Deze aanpak werkt als aan bepaalde voorwaarden is voldaan. Een intern IT-team dat groot genoeg is om de verantwoordelijkheid voor het platform op zich te nemen. De bereidheid van het management om te investeren in de autonomie van het team, en niet alleen daarover te praten. Bestaande tools die verder kunnen worden ontwikkeld in plaats van weggegooid te worden.

Als de context heel anders is (een minimaal IT-team, grote afhankelijkheid van één enkele integrator, een applicatieportfolio verspreid over meerdere leveranciers zonder gezamenlijk beheer), kun je hetzelfde recept niet zomaar toepassen. Je moet je aanpassen en soms eerst andere werkgebieden aanpakken (beheer, teamstructurering) voordat je aan de technische modernisering begint.

Dat is ook de reden waarom we het over ‘overgang’ hebben in plaats van over ‘transformatie’: een geleidelijke ontwikkeling, verankerd in de realiteit van elke organisatie.

Veelgestelde vragen

Een stap verder gaan

Dit project maakt deel uit van onze ‘IT Mission ’-aanpak, een van de drie pijlers van ‘ 5th floor ’, naast L4F (analyse en sturing van de applicatieportefeuille via AI) en organisatorische en culturele transformatie.

5th floor is sinds 2017 een partner in de digitale transformatie van Belgische overheidsinstellingen en is sinds 2025 B Corp-gecertificeerd (score 89,5, openbare beoordeling beschikbaar).

Als je je herkent in deze blogpost (een kloof tussen dev en prod, implementaties waar mensen tegen opzien, of de wens om te moderniseren zonder te weten waar je moet beginnen), neem dan contact met ons op. Een gesprek van een uur is vaak al voldoende om de eerste aanknopingspunten in kaart te brengen.