Azure-dataplatform migreren: valkuilen en slimme keuzes

Bij BWNEXT beginnen we een Azure dataplatformmigratie niet bij technologie, maar bij drie keuzes die het resultaat bepalen: migratiestrategie, kostenmodel en architectuurpijlers. Een gestructureerd traject verplaatst of herarchitecteert bestaande dataworkloads, pijplijnen en opslag naar Microsoft Azure, met diensten als Azure Synapse Analytics, Microsoft Fabric en Azure Data Lake Storage; zonder die afwegingen loopt een project al snel uit in budget, planning en beheercomplexiteit. Daarbij zien we in de praktijk steeds opnieuw dezelfde valkuilen:

sten en complexiteit komen gewoon mee naar de cloud

• Het Azure Well-Architected Framework biedt vijf architectuurpijlers als toetssteen voor elke migratiekeuze
• Microsoft adviseert bij Synapse-naar-Fabric migraties: begin klein en bereid je voor op meerdere kleine migraties
• AVG-compliance vereist verwerkersovereenkomsten en end-to-end encryptie; boetes kunnen oplopen tot 20 miljoen euro of 4% van de wereldwijde jaaromzet
• BWNEXT start elk migratietraject met een discovery van doorgaans één week, gevolgd door een platformselectie op basis van drie dimensies: ontwikkelaarsgerichtheid, kostenmodel en platformrijpheid

Waarom een Azure migratie vaker mislukt dan verwacht

Wat BWNEXT herhaaldelijk tegenkomt bij organisaties die een Azure dataplatform willen migreren: de initiële vraag is helder, maar de onderliggende situatie is complexer dan gedacht. Een data-architect bij een industriële producent met een paar honderd medewerkers zegt dat ze een bestaand datawarehouse naar de cloud willen verplaatsen. Na een week analyse blijkt dat de pipelines onderling afhankelijk zijn, de databeveiligingsrol niet duidelijk belegd is, en de business niets weet van het nieuwe platform. Wat begon als een technische migratie, is feitelijk een platform-, governance- en veranderopgave.

Dit patroon is niet uitzonderlijk. Volgens Eurostat gebruikte in 2025 al meer dan de helft van de EU-bedrijven betaalde clouddiensten, een stijging van ruim zeven procentpunt ten opzichte van 2023. De druk om te migreren neemt toe, maar de voorbereiding houdt daar doorgaans geen gelijke tred mee.

De lift-and-shift-valkuil

De meest gemaakte fout bij cloudmigraties is een directe een-op-een kopie van de on-premises omgeving naar Azure. Organisaties gaan er dan van uit dat schaalbaarheid en kostenvoordelen automatisch volgen. In de praktijk landen de bestaande architectuurproblemen gewoon mee in de cloud, maar dan met een hogere rekening omdat clouddiensten anders geprijsd zijn dan on-premises licenties.

Bij een lift-and-shift naar Azure bleven in meerdere projecten die BWNEXT beoordeelde, virtuele machines geconfigureerd met de instellingen van het oude datacenter. Dat leverde prestatieproblemen, hoger CPU-gebruik en onnodig hoge cloudkosten op, puur omdat de workloads niet waren beoordeeld en geoptimaliseerd vooraf.

Wanneer is lift-and-shift wél verantwoord?

Lift-and-shift is niet per definitie fout. Volgens de Microsoft Fabric migratie-documentatie is deze aanpak geschikt als je een beperkt aantal warehouses migreert, je data al in een goed ontworpen ster- of sneeuwvlokschema staat, en je onder tijds- en kostendruk staat. Voor grootschalige, verouderde datawarehouse-omgevingen is herontwerp vrijwel altijd de betere keuze.

Zelf aan de slag:

• Inventariseer welke workloads afhankelijkheden hebben naar andere systemen: zijn er meer dan vijf koppelingen, dan is lift-and-shift doorgaans risicovol
• Controleer of je databeveiligingsrol (data owner, data steward) expliciet belegd is voordat je begint
• Voer een pre-migratie validatie uit om compatibiliteitsproblemen in schema en code vroegtijdig te signaleren
• Vraag jezelf: wil ik problemen verplaatsen, of wil ik ze oplossen?

De vijf architectuurpijlers als besliskader

"Dat het dus niet alleen met een platform ertussen plakken opgelost kon worden."

— Jop

Voor elk migratieproject hanteert BWNEXT het Azure Well-Architected Framework als structureel toetskader. Dit framework is gebaseerd op vijf pijlers: betrouwbaarheid, beveiliging, kostenoptimalisatie, operationele excellentie en prestatie-efficiëntie. Elk architectuurkeuze wordt langs deze vijf dimensies beoordeeld voordat een migratieplan definitief wordt.

Betrouwbaarheid en downtime

Downtime is bij productiesystemen vaak het grootste risico. Microsoft's Azure Database Migration Service maakt migraties met minimale downtime mogelijk, maar dat vereist een online migratiestrategie waarbij de applicaties tijdens het kopieerproces blijven schrijven naar de bron. Bij offline migraties moet het schrijven gestopt worden, wat productie-impact heeft. De migratieduur hangt af van het aantal databases, de grootte van de tabellen, indexstructuren en beschikbare IOPS, en is daardoor moeilijk exact vooraf te schatten. Een testmigratie op een kopie van de productieomgeving geeft doorgaans de meest betrouwbare schatting.

Kostenoptimalisatie en FinOps

Kosten zijn bij grotere organisaties structureel het lastigste gesprek. BWNEXT lost dit op door pay-as-you-go kostenmodellen voor te stellen als instapmodel, zodat klanten eerst de cloudkosten begrijpen voordat ze committeren aan reserveringen. Bij Microsoft Fabric, bijvoorbeeld, betaal je op basis van Capacity Units. Pipelines die elk uur draaien zonder incrementele logica, ook buiten kantoortijden, kunnen ongemerkt forse maandkosten genereren puur door onnodige runs. FinOps-discipline, het continu bewaken en optimaliseren van clouduitgaven, is geen post-migratie activiteit maar begint al in de ontwerpfase.

Beveiliging en AVG-compliance

Organisaties die cloudproviders inzetten als gegevensverwerker zijn wettelijk verplicht verwerkersovereenkomsten af te sluiten en passende technische maatregelen te treffen, waaronder end-to-end encryptie. Overtredingen van de AVG kunnen leiden tot boetes tot 20 miljoen euro of 4% van de wereldwijde jaaromzet. In de praktijk ziet BWNEXT dat beveiligingsarchitectuur en AVG-compliance als laatste worden toegevoegd, terwijl ze al in de doelarchitectuur verankerd moeten zijn. Dit geldt extra sterk voor organisaties in gereguleerde sectoren als finance of healthcare.

Zelf aan de slag:

• Toets je doelarchitectuur langs alle vijf WAF-pijlers vóór aanvang van de uitvoering
• Stel een FinOps-dashboard in vanaf dag één: Azure Cost Management geeft dagelijks inzicht in verbruik per service
• Verifieer dat je verwerkersovereenkomst met de cloudprovider actueel is en end-to-end encryptie dekt
• Plan een parallel run-fase: draai oud en nieuw tegelijk om query-uitkomsten en KPIs te valideren

Stap-voor-stap: hoe een Azure dataplatform migratie eruitziet

Stap 1: Discovery en platformkeuze

BWNEXT begint elk traject met een discovery van doorgaans één week. In die fase wordt de bestaande architectuur in kaart gebracht: welke pijplijnen zijn er, welke afhankelijkheden bestaan er, welke databronnen zijn kritisch, en wat is de ambitie op het gebied van AI en analytics? Pas daarna volgt de platformkeuze. Platforms worden beoordeeld op drie dimensies: hoe ontwikkelaars- versus businessgericht is het platform, wat is het kostenmodel (pay-as-you-go versus gereserveerde capaciteit), en hoe matuur is het platform in productieomgevingen?

Stap 2: Doelarchitectuur ontwerpen

Op basis van de discovery wordt een doelarchitectuur ontworpen. De keuze tussen een lakehouse-architectuur (Microsoft Fabric, Databricks), een klassiek datawarehouse (Azure Synapse dedicated SQL pool) of een hybride setup hangt af van de workload-typen, de gewenste gebruikersinteractie en de bestaande tooling. Meer hierover vind je in het artikel over de keuze tussen Databricks, Snowflake en Microsoft Fabric.

Stap 3: Schema- en codevalidatie

Voordat data verplaatst wordt, worden schema (DDL) en databasecode (DML) gecontroleerd op compatibiliteit met het doelplatform. Bij een Synapse-naar-Fabric migratie betekent dit onder andere het markeren van niet-ondersteunde T-SQL-syntaxis in opgeslagen procedures en functies. Incompatibele code die niet vooraf herkend wordt, veroorzaakt doorgaans de langste vertragingen in het migratieproject.

Stap 4: Incrementele migratie in kleine batches

Microsoft adviseert uitdrukkelijk: begin klein en bereid je voor op meerdere kleine migraties. Een eerste migratiebatch van doorgaans 1 tot 10 terabyte is groot genoeg om de werking van de doelomgeving te valideren, maar klein genoeg om snel waarde te laten zien. BWNEXT hanteert een metadata-gedreven framework waarbij pijplijnen iteratief worden gemigreerd en gevalideerd, in plaats van alles in één keer over te zetten.

Stap 5: Parallel draaien en valideren

Oud en nieuw draaien gelijktijdig. Queryresultaten, rijtellingen en business-KPIs worden vergeleken tussen bron- en doelomgeving. Pas wanneer de uitkomsten consistent zijn, wordt de cutover gepland. BWNEXT stelt in deze fase ook de metadata-tabel en het governance-framework in, zodat business-gebruikers het platform in hun eigen taal kunnen aansturen, zonder dat ze code hoeven te schrijven.

Stap 6: Cutover en hypercare

De feitelijke cutover wordt gepland in een periode met laag applicatieverkeer. Na de go-live volgt een hypercare-periode van doorgaans twee tot vier weken, waarin snelle herstelacties mogelijk zijn en de oude omgeving nog niet wordt uitgezet. Pas na stabiele productiewerking wordt de broninfrastructuur gefaseerd afgebouwd.

Stap 7: FinOps en doorontwikkeling

Na de migratie begint het echte werk: kostenbewaking, prestatie-optimalisatie en governance. Organisaties die geen FinOps-routine instellen na go-live, zien cloudkosten doorgaans oplopen door ongebruikte resources en suboptimale configuraties. BWNEXT biedt op dit punt ook een tweede data engineer aan bij klanten waar de plaatselijke consultant de meest ervaren persoon op de vloer is geworden, zodat de doorontwikkeling van het platform geen vertraging oploopt.

Zelf aan de slag:

• Plan de discovery vooraf als apart project, niet als eerste sprint van de migratie
• Gebruik Azure Migrate voor een geautomatiseerde inventarisatie van workloads en afhankelijkheden
• Stel een herhaalbaar migratiepatroon in na de eerste batch: documenteer het proces van begin tot eind
• Activeer kostenwaarschuwingen in Azure Cost Management vanaf dag één na go-live

Migratiestrategie kiezen: een besliskader

Niet elke situatie vraagt om dezelfde aanpak. De tabel hieronder geeft een praktisch overzicht van de drie meest gebruikte migratiestrategieën:

De meest geschikte strategie hangt altijd af van de platformrijpheid van de doelomgeving, de beschikbare expertise en de mate waarin de business bereid is te veranderen. BWNEXT adviseert op basis van alle drie dimensies, niet alleen op technische gronden. Lees meer over hoe dit er in de praktijk uitziet bij cloudmigratie zonder dataverlies.

Zelf aan de slag:

• Stel vast hoe matuur je huidig schema is: meer dan drie jaar oud zonder herontwerp is doorgaans een signaal voor re-architectuur
• Bepaal of je AI-workloads wilt toevoegen binnen 12 maanden: zo ja, dan is lift-and-shift een kortetermijnkeuze
• Vraag bij meerdere consultancypartijen een korte platformscan aan voordat je een strategie kiest
• Betrek business-stakeholders in de strategiekeuze: technische voorkeur en businessbereidheid moeten op één lijn liggen

Senior expertise als kritische succesfactor

Een Azure dataplatform migreren is geen junior-taak. De valkuilen zitten niet in het kopiëren van data, maar in de ontwerpbeslissingen vooraf: welk kostenmodel past, hoe worden beveiligingsrollen ingericht, hoe wordt de business opgeleid om het nieuwe platform te gebruiken? Bij opdrachtgevers die werken met generieke profielen die onvoldoende Azure-diepgang hebben, ontstaan doorgaans de meest kostenintensieve problemen pas na go-live, wanneer herstructureren duurder is dan van tevoren ontwerpen.

BWNEXT levert senior cloud-architecten en data engineers die deze beslismomenten kennen vanuit end-to-end projectervaring. Ze stellen de ongemakkelijke vragen over eindoelen, AI-expansieplannen, beveiligingsvereisten en businessbereidheid, al in de eerste week. Dat is precies de werkwijze die de EU in haar Digital Decade-doelstelling als fundament ziet: drie op de vier EU-bedrijven moet cloud, big data of AI inzetten in 2030. Voor die ambitie zijn niet meer junior implementeerders nodig, maar senior consultants die het platform als fundament begrijpen.

Voor opdrachtgevers in Zuid-Holland die senior Azure-expertise zoeken voor complexe migratietrajecten, biedt BWNEXT een directe intake voor opdrachtgevers waarbij de match op senioriteitsniveau en domeinkennis centraal staat, niet op uurtarief of beschikbaarheid.

Zelf aan de slag:

• Beoordeel bij elke consultant in je migratieteam of ze écht end-to-end Azure-projecten hebben afgerond, inclusief go-live en post-migratie optimalisatie
• Zorg dat minimaal één senior architect de WAF-beoordeling uitvoert voordat de uitvoering start
• Stel vast of je interne team de post-migratie FinOps-routine kan oppakken, of dat externe begeleiding nodig blijft
• Plan een kennisoverdrachtsessie in het project: business-gebruikers moeten het platform begrijpen, niet alleen de data engineers

Veelgestelde vragen

Wat is het verschil tussen lift-and-shift en re-architectuur bij een Azure dataplatform migratie?

Lift-and-shift is het een-op-een verplaatsen van bestaande workloads naar Azure zonder structurele wijzigingen aan de architectuur. Re-architectuur betekent dat je de doelarchitectuur opnieuw ontwerpt op basis van Azure-native diensten, zoals een lakehouse-structuur of Microsoft Fabric. Lift-and-shift is sneller en goedkoper op korte termijn, maar levert geen kostenvoordeel op als de bestaande architectuur suboptimaal was. Re-architectuur vergt meer tijd en expertise, maar resulteert doorgaans in een platform dat beter schaalbaar is en minder operationele overhead heeft.

Hoe lang duurt een typische Azure dataplatform migratie?

De doorlooptijd varieert sterk op basis van de complexiteit van de omgeving, de gekozen strategie en de beschikbare expertise. Een lift-and-shift van een beperkte omgeving kan in doorgaans twee tot zes weken zijn uitgevoerd; een volledige re-architectuur van een enterprise datawarehouse neemt doorgaans vier tot tien maanden in beslag. De ontbrekende factor is vrijwel altijd de validatiefase: het parallel draaien van oud en nieuw kost tijd, maar is onmisbaar voor een betrouwbare cutover. BWNEXT begint elk traject met een één-week discovery om de scope en realistische planning te onderbouwen.

Hoe helpt BWNEXT bij een Azure dataplatform migratie?

BWNEXT levert senior cloud-architecten en data engineers die het volledige migratietraject begeleiden, van discovery en platformkeuze tot go-live en post-migratie FinOps. De aanpak start met een grondige analyse van de bestaande situatie, inclusief beveiligingsarchitectuur, datagovernance en businessbereidheid, voordat een migratieplan wordt opgesteld. Consultants van BWNEXT zijn in vaste dienst, werken end-to-end en brengen diepe kennis mee van Azure, Microsoft Fabric en aangrenzende platformen. Meer informatie over de aanpak vind je op de BWNEXT-website voor opdrachtgevers.

Wat zijn de belangrijkste AVG-verplichtingen bij een Azure cloudmigratie?

AVG-compliance bij cloudmigratie vereist dat je met de cloudprovider een verwerkersovereenkomst afsluit en passende technische maatregelen treft, waaronder end-to-end encryptie. Organisaties die dit nalaten, riskeren boetes tot 20 miljoen euro of 4% van de wereldwijde jaaromzet. In de praktijk ziet BWNEXT dat beveiliging en compliance als laatste worden toegevoegd aan een migratieproject, terwijl ze al in de doelarchitectuur verankerd moeten zijn. Een security review maakt standaard deel uit van het migratietraject dat BWNEXT uitvoert.

Wat zijn de meest voorkomende kostenrisico's na een Azure migratie?

Onverwachte cloudkosten na go-live ontstaan doorgaans door drie patronen: ongebruikte resources die niet zijn uitgeschakeld, pijplijnen die elk uur draaien zonder incrementele logica, en overgedimensioneerde compute-instanties die zijn ingericht voor piekbelasting maar continu actief zijn. FinOps-discipline, het continu bewaken en optimaliseren van clouduitgaven, is geen optionele activiteit maar een structureel onderdeel van elke succesvolle migratie. BWNEXT stelt kostenwaarschuwingen en dashboards in als standaard onderdeel van de go-live, zodat kostenafwijkingen direct zichtbaar zijn. Zie ook het artikel over hoe senior consultants data- en AI-projecten voor mislukken behoeden voor bredere context.

Conclusie

Een Azure dataplatform migreren is een strategisch besluit, geen IT-klus. De keuze tussen lift-and-shift, re-platforming en re-architectuur bepaalt niet alleen de technische uitkomst, maar ook de cloudkosten voor de komende jaren. De duurste fouten ontstaan niet tijdens de migratie zelf, maar in de beslissingen ervoor: onvoldoende discovery, beveiliging als bijzaak, en een kostenmodel dat pas na go-live wordt begrepen.

BWNEXT begeleidt organisaties door dit traject met senior cloud-architecten en data engineers die het Azure-landschap end-to-end kennen. Van de eerste discovery tot de post-migratie FinOps-routine. Voor opdrachtgevers in Zuid-Holland en de rest van Nederland die een migratie willen aanpakken zonder kostenoverschrijding, is de aanpak van BWNEXT beschreven op de pagina voor opdrachtgevers.