Cloudmigratie wordt in presentaties en marketingmateriaal vaak neergezet als een relatief rechtlijnig proces: workloads in kaart brengen, een migratiestrategie kiezen, systemen verplaatsen en vervolgens direct profiteren van kostenbesparingen en flexibiliteit. De praktijk blijkt, zeker voor Nederlandse overheidsorganisaties, aanzienlijk complexer. Afdelingen moeten tegelijkertijd voldoen aan strikte BIO- en AVG-eisen, omgaan met verouderde applicaties waarvan de broncode soms niet meer beschikbaar is, rekening houden met eisen rondom data-opslag binnen Nederland of de EU, complexe aanbestedingsregels volgen en politieke gevoeligheden rondom buitenlandse cloudaanbieders zorgvuldig managen.
In deze case study beschrijven we een ongefilterde Azure-cloudmigratie van 24 maanden bij een middelgroot Nederlands ministerie (in deze tekst geanonimiseerd als Ministerie Y) met circa 4.200 fte, ruim 120 bedrijfskritische en ondersteunende applicaties, ongeveer 12 TB operationele data en een jaarlijks IT-budget van 18 miljoen euro. Het project werd oorspronkelijk begroot op 4,8 miljoen euro met een doorlooptijd van 18 maanden, maar kwam uiteindelijk uit op 7,2 miljoen euro en een looptijd van 24 maanden. Dat betekent een budgetoverschrijding van ongeveer 50 procent en een half jaar vertraging ten opzichte van de planning.
Ondanks deze uitdagingen realiseerde het ministerie uiteindelijk de beoogde doelstellingen: een structurele verlaging van de infrastructuurkosten met ongeveer 40 procent, een aantoonbaar verbeterde beveiligingspositie, een veel robuustere aanpak voor uitwijk en disaster recovery, en een fundament voor verdere digitale innovatie, waaronder data-analyse, moderne werkplekken en nieuwe online diensten voor burgers. In de rest van dit artikel laten we aan de hand van concrete situaties zien wat er goed ging, waar het misliep, waarom de oorspronkelijke aannames niet bleken te kloppen en welke lessen andere Nederlandse overheidsorganisaties hieruit kunnen trekken om vergelijkbare valkuilen te vermijden.
Deze case study biedt een eerlijk en praktijkgericht beeld van een Azure-migratie binnen de Nederlandse overheid. Je krijgt inzicht in de volledige projecttijdlijn, van de eerste businesscase tot en met de optimalisatiefase na de migratie. We laten zien hoe een grondige analyse van het applicatieportfolio leidde tot het uitfaseren van 35 applicaties en de migratie van 85 andere, welke migratiestrategieën zijn toegepast (zoals rehost, refactor en retire), hoe het ministerie omging met data-soevereiniteit en BIO-compliance in de publieke cloud, en hoe de netwerkarchitectuur is herontworpen van traditionele datacenters naar een moderne hub-spoke-topologie in Azure. Ook komen de oorzaken van budgetoverschrijdingen, technische mislukkingen en rollback-scenario's aan bod, evenals het belang van stakeholdermanagement, communicatie en politieke sensitiviteit. Tot slot vertalen we de gemeten resultaten en ROI naar concrete aanbevelingen voor andere overheidsorganisaties die een vergelijkbare cloudtransformatie overwegen.
Rationaliseer eerst, migreer daarna. Het ministerie begon met het plan om alle 120 applicaties één-op-één naar Azure te verplaatsen. Tijdens de analysefase bleek echter dat 35 applicaties in het afgelopen jaar geen enkele actieve gebruiker meer hadden, maar wel servers, licenties en beheerinspanning verbruikten. Daarnaast waren er 28 applicaties die grotendeels dezelfde functionaliteit boden, zoals meerdere HR-systemen en verschillende projectmanagementtools. Ook bleek dat 18 applicaties probleemloos konden worden vervangen door standaardfunctionaliteit in Microsoft 365. Door eerst bewust te kiezen welke applicaties worden uitgefaseerd, samengevoegd of vervangen, werd de migratieomvang teruggebracht van 120 naar 59 applicaties. Dat leverde naar schatting 1,8 miljoen euro minder migratiekosten en ongeveer 340.000 euro minder jaarlijkse beheerkosten op. De belangrijkste les: zie een cloudmigratie niet als een technische verhuizing, maar als een strategisch moment om je applicatielandschap op te schonen.
Initiële analyse: applicatie-afhankelijkheden en migratiecomplexiteit blootleggen
De initiële fase van het project begon in januari 2022 met een ogenschijnlijk eenvoudige opdracht: maak een compleet overzicht van alle applicaties die in aanmerking komen voor migratie naar Azure. In de configuratie- en assetmanagementdatabases stonden 87 applicaties geregistreerd, verdeeld over verschillende directies en beleidsdomeinen. Al snel bleek echter dat dit overzicht verre van volledig was. In gesprekken met afdelingen kwamen tientallen niet-geregistreerde toepassingen naar boven: Access-databases die ooit als tijdelijke oplossing waren opgezet, Excel-bestanden met uitgebreide VBA-automatisering, kleine webapplicaties die door externe leveranciers waren ontwikkeld en nog steeds draaiden, en pilots die nooit officieel waren afgesloten maar wel productiegegevens verwerkten. Uiteindelijk werden 33 extra applicaties en datastromen gevonden die nergens formeel waren vastgelegd.
Om tot een betrouwbaar totaalbeeld te komen, moest het projectteam veel dieper graven dan aanvankelijk gepland. Naast het uitlezen van inventarisatiesystemen werden interviews gehouden met sleutelfiguren in de organisatie, zoals applicatie-eigenaren, functioneel beheerders en hoofdgebruikers. Netwerkverkeer werd geanalyseerd om niet-geregistreerde servers, file shares en integraties op te sporen. Ook is gebruikgemaakt van geautomatiseerde discoverytools om services, verbindingen en gebruikte protocollen in kaart te brengen. Alleen al deze inventarisatiefase duurde ongeveer drie maanden en maakte duidelijk dat een cloudmigratie begint met het herstellen van de basis: weten welke applicaties er zijn, wie ze gebruikt en hoe ze met elkaar verbonden zijn.
De mate van documentatie verschilde sterk per applicatie. Moderne systemen hadden vaak actuele architectuurdiagrammen, beschrijvingen van koppelingen en duidelijke beheerprocedures. Legacy-applicaties die tien tot vijftien jaar eerder waren geïmplementeerd bleken daarentegen vrijwel geen bruikbare documentatie meer te hebben. Oorspronkelijke leveranciers waren verdwenen of contracten waren jaren geleden beëindigd, broncode was niet langer beschikbaar en veel kennis zat opgesloten in het hoofd van één of twee seniore medewerkers die binnen afzienbare tijd met pensioen zouden gaan. Voor het migratieteam betekende dit dat cruciale informatie over afhankelijkheden, configuraties en foutafhandeling ontbrak. Om systemen naar Azure te kunnen verplaatsen, moesten productieomgevingen deels worden teruggeëngineerd: configuraties werden uitgelezen, logging werd tijdelijk uitgebreid en testscenario's werden opgesteld om te begrijpen hoe het geheel zich daadwerkelijk gedroeg.
Bij het uitwerken van afhankelijkheden kwam een complex web van onderlinge relaties naar voren. Applicaties die in eerste instantie zelfstandig leken te functioneren, bleken op dezelfde databases te schrijven, bestanden uit te wisselen via gedeelde netwerkshares of gebruik te maken van gemeenschappelijke authenticatie- en autorisatievoorzieningen. Nachtelijke batchprocessen kopieerden gegevens van het ene systeem naar het andere, soms via scripts waar niemand de exacte werking nog van kende. Hierdoor kon het migratieteam niet simpelweg individuele applicaties los van elkaar verplaatsen. Er moesten logische migratiegroepen worden gevormd: wanneer een kernapplicatie naar Azure ging, moesten gekoppelde systemen in hetzelfde venster worden meegenomen of tijdelijk op een alternatieve manier worden aangesloten. Dit had direct impact op de planning, de benodigde testcapaciteit en de complexiteit van eventuele rollbackscenario's.
Parallel aan de technische analyse speelde een intensieve discussie over dataclassificatie en data-soevereiniteit. Volgens de BIO en aanvullende departementale richtlijnen moet strikt worden bewaakt waar vertrouwelijke en staatsgeheime gegevens zich bevinden. De beschikbaarheid van Azure-regio's in West-Europa maakt het mogelijk om data grotendeels binnen de EU te houden, maar niet alle datacenters bevinden zich fysiek in Nederland. Juristen, security officers en architecten werkten samen aan de vraag welke typen gegevens uitsluitend in een Nederlands datacenter mochten staan en voor welke categorieën gebruik van andere EU-regio's acceptabel is, mits er aanvullende maatregelen worden getroffen.
Deze gesprekken leidden uiteindelijk tot een gedifferentieerd beleid. Voor staatsgeheime informatie werd vastgelegd dat deze uitsluitend in een Nederlandse regio mag worden opgeslagen en dat klantbeheerde encryptiesleutels verplicht zijn. Voor departementaal vertrouwelijke gegevens werd gekozen voor opslag binnen de EU met sterke versleuteling en duidelijke logging, terwijl interne of publieke informatie meer flexibiliteit kreeg. Ook de keuze tussen door Microsoft beheerde sleutels en klantbeheerde sleutels in Azure Key Vault kwam uitgebreid aan bod. De securityafdeling pleitte voor maximale controle via eigen sleutelbeheer, terwijl de exploitatieorganisatie wees op de risico's van menselijke fouten, sleutelverlies en operationele complexiteit. Uiteindelijk werd een middenweg gevonden: voor de hoogste dataklassen geldt een strikt regime met klantbeheerde sleutels, voor lagere klassen is gekozen voor een eenvoudiger model met door Microsoft beheerde sleutels. Deze keuzes in de initiële fase legden een belangrijk fundament voor de verdere migratie en zorgden ervoor dat compliance- en security-eisen niet pas aan het eind werden getoetst, maar vanaf het begin integraal onderdeel van het ontwerp waren.
Migratie-uitvoering: technische tegenslagen en gecontroleerde rollbacks
Na de uitgebreide voorbereidingsfase werd in maart 2023 de eerste migratiegolf gepland. Op papier ging het om twaalf relatief eenvoudige applicaties met een laag risicoprofiel. De gedachte was dat deze systemen in één weekend konden worden overgezet, zodat het projectteam ervaring kon opdoen zonder direct de meest kritieke processen te raken. De planning was klassiek: op vrijdagavond zouden de betrokken applicaties worden uitgezet in het datacenter, in de nacht en op zaterdag zou de migratie naar Azure plaatsvinden, op zondag zou er ruimte zijn voor testen en validatie en op maandagochtend zouden gebruikers zonder merkbare onderbreking verder werken op de nieuwe omgeving.
De praktijk pakte anders uit. Een SharePoint 2010-omgeving die al jaren werd gebruikt voor documentbeheer binnen het ministerie bleek sterk afhankelijk van een specifieke combinatie van .NET-versies en aanvullende componenten. In Azure werden virtuele machines uitgerold met een moderne versie van het platform, waardoor de applicatie direct na de migratie niet meer wilde starten. Foutmeldingen waren weinig informatief en verwezen naar ontbrekende assemblies en incompatibele bibliotheken. Het team bracht bijna een volledige dag door met het installeren van verouderde componenten, het aanpassen van configuraties en het opnieuw toekennen van rechten. Uiteindelijk kwam de omgeving weer in de lucht, maar de geplande tijdslijnen waren inmiddels volledig uitgelopen.
Een tweede applicatie, een financieel systeem met een zwaar belaste database, liet na de migratie een duidelijke verslechtering van de prestaties zien. Rapportages die voorheen enkele seconden duurden, deden er nu vele malen langer over. Bij nader onderzoek bleek dat de oorspronkelijke omgeving was geoptimaliseerd voor specifieke hardware in het datacenter, met lokaal aangesloten opslag en zorgvuldig afgestemde RAID-configuraties. De standaardopslag in Azure bood niet dezelfde latency- en throughputkarakteristieken. Door noodgedwongen te schalen naar duurdere opslag, aanvullende indexen toe te voegen en query's te optimaliseren, werd de performance verbeterd, maar het niveau van de oude omgeving werd niet direct gehaald. Gebruikers merkten wekenlang dat het systeem trager aanvoelde en dat heeft het vertrouwen in de migratie in deze fase geen goed gedaan.
Een derde systeem, een verouderde client-serverapplicatie, bleek door en door afhankelijk van hardgecodeerde IP-adressen. Overal in configuratiebestanden, registersleutels en zelfs in de database kwamen vast ingestelde adresgegevens terug. Omdat in Azure met andere IP-reeksen en netwerksegmenten werd gewerkt, viel de applicatie na de migratie simpelweg stil. De oorspronkelijke leverancier bestond niet meer, broncode was onvindbaar en er was geen enkele vorm van moderne configuratievoorziening. Het team moest met zoekacties door scripts, registries en databases letterlijk elk IP-adres handmatig vervangen. Wat op de planning stond als een taak van enkele uren, groeide uit tot een inspanning van dertig uur, waarbij meerdere specialisten continu betrokken waren.
Aan het einde van het weekend vol problemen waren slechts zes van de twaalf applicaties stabiel genoeg om te voldoen aan de acceptatiecriteria. Het projectteam stond voor een lastige keuze: toch live gaan met slechts een deel van de systemen en gebruikers confronteren met instabiele dienstverlening, het migratievenster verlengen en doorwerken in de werkweek, of alles terugdraaien en de oude omgeving weer in gebruik nemen. In overleg met de opdrachtgever werd gekozen voor een volledige rollback. In de nacht van zondag op maandag werden alle wijzigingen teruggedraaid, waardoor medewerkers maandagochtend gewoon konden doorwerken op de vertrouwde on-premises systemen. Voor gebruikers leek er niets gebeurd, maar in het projectteam was het duidelijk dat de aanpak opnieuw tegen het licht moest worden gehouden.
De nasleep van deze eerste golf was constructief maar confronterend. In een uitgebreide evaluatie werden de oorzaken van de problemen geanalyseerd. De belangrijkste conclusies waren dat de complexiteit van legacy-applicaties was onderschat, dat het testtraject onvoldoende was ingericht en dat de gekozen tijdsdruk te groot was. Het team besloot daarom de werkwijze fundamenteel aan te passen. Voor volgende migratiegolven werd een testomgeving ingericht die de productieomgeving in Azure zo goed mogelijk nabootste. Applicaties werden daar eerst volledig uitgerold, inclusief koppelingen en beveiligingsinstellingen, waarna technische testen, performance-metingen en gebruikersacceptatietesten werden uitgevoerd. Problemen kwamen daardoor eerder aan het licht, op een moment dat de impact nog beheersbaar was.
Daarnaast werden de migratievensters verruimd. In plaats van één weekend werd gekozen voor perioden van meerdere dagen, soms zelfs met een fase waarin de oude en nieuwe omgeving tijdelijk parallel draaiden. Voor kritieke systemen kregen geselecteerde gebruikersgroepen de mogelijkheid om gedurende een proefperiode in Azure te werken terwijl de rest van de organisatie nog op de oude omgeving zat. Op basis van hun feedback werden kinderziektes opgelost voordat een volledige overstap werd gemaakt. Dit vergde meer tijd en tijdelijk hogere kosten, maar voorkwam crisissituaties en versterkte het vertrouwen in de migratieaanpak. Tegen de tijd dat de vijfde migratiegolf plaatsvond, ongeveer anderhalf jaar na de start van het project, was het proces uitgegroeid tot een voorspelbaar ritme. De kwaliteit van de voorbereidingen was verbeterd, de meeste verrassingen werden al in testomgevingen gevonden en rollbackscenario's bleken steeds minder vaak nodig. Het team had zichtbaar geleerd van de eerste tegenslagen en wist die ervaring om te zetten in een volwassen migratieproces.
Meetbare resultaten: rendement, beveiligingswinst en strategische waarde
De financiële onderbouwing van de migratie was vanaf het begin een belangrijk gespreksonderwerp binnen het ministerie. In de oorspronkelijke businesscase werd uitgegaan van een eenmalige investering van ongeveer 4,8 miljoen euro, tegenover jaarlijkse besparingen van 1,9 miljoen euro door het uitfaseren van datacenters, het verminderen van hardwarevervangingen en een efficiëntere inzet van beheercapaciteit. Door de extra complexiteit, langere doorlooptijd en aanvullende beveiligings- en compliance-eisen kwam het uiteindelijke investeringsbedrag hoger uit: circa 7,2 miljoen euro. Tegelijkertijd bleken de gerealiseerde besparingen na optimalisatie groter dan verwacht, namelijk ongeveer 2,4 miljoen euro per jaar.
Een belangrijk deel van de baten komt uit het gecontroleerd verlaten van twee van de drie fysieke datacenters. Door deze locaties uit te faseren, vielen kosten weg voor huisvesting, energie, koeling, fysieke beveiliging en onderhoud. Daarnaast moesten er aanzienlijk minder nieuwe servers en netwerkcomponenten worden aangeschaft. Waar voorheen iedere verouderde server fysiek moest worden vervangen, wordt in de cloud capaciteit flexibel opgeschaald of juist afgeschaald. Dit leidde tot een daling van de jaarlijkse uitgaven aan hardwarevernieuwing met naar schatting 650.000 euro. Ook netwerkverbindingen werden opnieuw ontworpen. Duur betaalde MPLS-verbindingen maakte plaats voor moderne, direct op de cloud aangesloten verbindingen, wat een structurele besparing opleverde zonder dat dit ten koste ging van de beschikbaarheid of betrouwbaarheid.
Naast de direct zichtbare besparingen heeft de overstap naar Azure operationele efficiëntie opgeleverd die vooraf niet volledig was meegenomen in de businesscase. Door gebruik te maken van automatische schaalmechanismen draait rekenkracht niet langer onnodig op volle sterkte tijdens rustige periodes zoals avonden en weekenden. Hierdoor daalden de compute-kosten merkbaar. Voor voorspelbare workloads werden gereserveerde instanties ingezet, waardoor lagere tarieven konden worden bedongen dan bij volledig verbruik op basis van pay-as-you-go. Ook het back-uplandschap is vereenvoudigd: waar voorheen meerdere afzonderlijke oplossingen werden beheerd, is gekozen voor één geïntegreerde aanpak in de cloud. Dit verminderde zowel licentiekosten als beheerinspanning.
Op basis van de gerealiseerde besparingen is een nieuwe terugverdientijd berekend. Gezien de hogere initiële investering duurt het ongeveer 38 maanden voordat de gecumuleerde besparingen de totale projectkosten evenaren. Over een periode van vijf jaar resteert desondanks een positief financieel resultaat: de jaarlijkse besparing van circa 2,4 miljoen euro leidt tot ongeveer 12 miljoen euro aan lagere operationele kosten, wat neerkomt op een netto voordeel van ongeveer 4,8 miljoen euro ten opzichte van de totale migratiekosten. Hoewel de weg naar dat resultaat minder rechtlijnig was dan gehoopt, concludeerden zowel financieel als inhoudelijk verantwoordelijken dat de beslissing om naar de cloud te gaan zichzelf uiteindelijk terugbetaalt.
Minstens zo belangrijk als de financiële cijfers zijn de verbeteringen in de beveiligingspositie. De Microsoft Secure Score steeg van ongeveer 42 procent vóór de migratie naar circa 83 procent erna. Dit is te danken aan het systematisch inzetten van cloudnative beveiligingsdiensten zoals Microsoft Defender for Cloud, Azure Policy en geautomatiseerde patch- en updatevoorzieningen. Kwetsbaarheden worden nu continu gescand, prioriteiten worden automatisch bepaald en beheerders ontvangen concrete aanbevelingen voor herstelmaatregelen. De naleving van patchbeleid verbeterde aantoonbaar: waar vroeger een aanzienlijk deel van de servers niet tijdig werd bijgewerkt, laat de rapportage nu zien dat meer dan 90 procent binnen de afgesproken termijnen is voorzien van de laatste updates.
Ook op het gebied van uitwijk en herstel heeft de migratie een verschil gemaakt. In de oude situatie bestond er wel een disasterrecoveryplan op papier, maar volledige tests waren zeldzaam omdat de impact op de productieomgeving te groot zou zijn. Met Azure Site Recovery kon het ministerie realistische proeven uitvoeren waarin een uitwijk naar een secundaire regio werd gesimuleerd, de functionaliteit werd gecontroleerd en vervolgens werd teruggeschakeld naar de primaire omgeving. Zulke oefeningen lieten zien dat een hersteltijd van enkele uren haalbaar is, waar voorheen werd uitgegaan van één of meerdere dagen. Dat geeft zowel bestuurders als operationele teams meer vertrouwen in de continuïteit van kritieke processen.
Ten slotte is ook de manier waarop compliance wordt aangetoond ingrijpend veranderd. Waar auditors eerder wekenlang gegevens moesten verzamelen uit uiteenlopende systemen, kan nu een groot deel van de benodigde informatie rechtstreeks uit Azure en Microsoft Purview worden gehaald. Beleidsregels worden technisch afgedwongen via Azure Policy en de naleving daarvan is direct inzichtelijk. Rapportages richting interne toezichthouders, de auditdienst en externe toezichthouders kunnen sneller worden opgesteld en zijn beter onderbouwd. Hiermee heeft de cloudmigratie niet alleen geleid tot kostenverlaging en technische vernieuwing, maar ook tot een professionelere, beter aantoonbare beheersing van risico's en naleving van wet- en regelgeving.
De Azure-cloudmigratie bij Ministerie Y laat zien dat een grootschalige IT-transformatie binnen de overheid veel meer omvat dan het verplaatsen van servers en applicaties naar een nieuw platform. Juridische en politieke vraagstukken, de relatie met leveranciers, het betrekken van medezeggenschap, het omgaan met verouderde systemen en het naleven van strenge compliance-eisen bleken minstens zo bepalend voor het tempo en de uitkomst van het project als de technische keuzes. De budgetoverschrijding en vertraging maken duidelijk dat initiële planningen vaak te optimistisch zijn wanneer organisatieverandering, kennisopbouw en cultuurverschillen onvoldoende worden meegewogen.
Tegelijkertijd bevestigt het eindresultaat dat een goed doordachte cloudmigratie voor de overheid substantieel meerwaarde kan bieden. De combinatie van lagere infrastructuurkosten, een aantoonbaar betere beveiligingspositie, kortere hersteltijden bij verstoringen en een flexibeler platform voor innovatie maakt dat de investering zich over de looptijd terugverdient. De belangrijkste lessen voor andere Nederlandse overheidsorganisaties zijn om ruim de tijd te nemen voor een grondige analyse van het applicatieportfolio, om het durven uitfaseren van overbodige of verouderde systemen expliciet onderdeel te maken van de strategie, om uitgebreid te testen in representatieve omgevingen vóórdat er grote productiewijzigingen worden doorgevoerd en om te investeren in kennisopbouw bij eigen medewerkers.
Daarnaast is heldere en continue communicatie richting bestuurders, gebruikers en partners essentieel om draagvlak vast te houden, zeker wanneer zich tegenvallers voordoen. Wie cloudmigratie benadert als een integrale organisatieverandering op het gebied van mensen, processen en technologie, en niet alleen als een technisch project, heeft de grootste kans om dezelfde positieve effecten te realiseren als Ministerie Y, met minder verrassingen onderweg.