Lift-and-shift is de duurste manier om in Azure te blijven

De knoop is door, de factuur valt tegen

Je hebt de knoop doorgehakt. De on-premise SQL Servers gaan naar Azure. Het businessplan is rond, Azure Migrate staat klaar, en binnen een paar maanden draaien de workloads in de cloud. Missie geslaagd.

Drie maanden later valt de eerste echte factuur op de mat, en die is fors hoger dan iedereen had ingeschat.

Het probleem zit in de specs die je meeneemt

On-premise SQL Servers zijn vrijwel altijd ruim gesized. Logisch ook: je koopt hardware voor drie tot vijf jaar, dus je dimensioneert en anticipeert voor de piek die je over twee jaar misschien gaat zien. Plus een marge. Plus nog wat ruimte voor die jaarafsluiting in december. Plus reserve voor het geval dat.

In een eigen datacenter is dat geen probleem. De hardware is afgeschreven, de stroomrekening verandert nauwelijks of je server nu op 20% of 70% CPU draait. Idle capaciteit is gratis. In Azure is idle capaciteit een vaste maandelijkse factuur.

Wat Henk in de praktijk ziet: teams die hun on-premise specs meekopiëren naar Azure nemen te veel af omdat de mindset niet meekantelt. On-premise size je voor de piek, in Azure size je voor het patroon.

De drie kostenkillers bij SQL Server lift-and-shift

Verkeerde VM-familie.

Dit is de stille killer. SQL Server-workloads zijn in negentig procent van de gevallen memory-bound, niet compute-bound. Toch belanden databases keer op keer op algemene dev/test workhorse VM’s met veel cores maar relatief weinig geheugen per core.

Het gevolg: SQL Server kan onvoldoende data cachen, moet vaker data van disk lezen, queries worden trager, disk burst capacity is niet beschikbaar en de natuurlijke reactie is “deze VM is te klein, schaal ’m op.” Je betaalt nu voor nog meer cores die je niet gebruikt, terwijl het probleem geheugen was. Er zijn tientallen SKU’s waaruit we kunnen kiezen (bijv. de B- en E-series). Memory-optimized, hogere IOPS-limieten, en in veel gevallen goedkoper dan een opgeschaalde D-series die hetzelfde geheugen probeert te bereiken via brute force.

Sizing voor piek in plaats van patroon.

Je on-premise SQL Server piekt een half uurtje per dag op 75% CPU. De rest van de tijd dobbert hij rond de 8%. In de cloud betaal je voor die 75%-capaciteit, 24 uur per dag, zeven dagen per week.

Dat is geen tekortkoming van Azure: dat is een gemiste kans ten tijde van de migratie. De cloud is gebouwd op het idee dat je op- en afschaalt. Doe je dat niet, dan betaal je premium prijzen voor on-premise gedrag. Voor variabele workloads bestaan B-series burstable VM’s die credits opbouwen tijdens rustige uren en uitgeven tijdens pieken. Voor dev-, test-, QA- en batch-omgevingen levert Azure SQL Database Serverless direct winst: die schaalt automatisch terug naar nul na kantoorsluiting wanneer je medewerkers vrij zijn, en je betaalt aanzienlijk minder.

Storage die niet bij de workload past.

In het eigen datacenter werd storage één keer ingericht en daarna nooit meer aangeraakt. In Azure is storage een actieve keuze met directe kostengevolgen: Standard SSD-disks met een limiet van 500 IOPS versus Premium SSD’s met 5000, Ultra Disk, host-caching aan of uit, data- en logfiles op aparte disks. Standaardinstellingen accepteren betekent vrijwel altijd te veel betalen, te trage queries, of allebei tegelijk.

Van capaciteit kopen naar consumptie sturen

Hier zit de kern. Lift-and-shift is technisch een migratie, maar economisch een verandering. On-premise kocht je capaciteit (CapEx), schreef je af en gebruikte je ’m zo veel mogelijk om de investering terug te verdienen. In Azure consumeer je capaciteit (OpEx) en moet je dus het omgekeerde doen: zo weinig mogelijk gebruiken voor zo veel mogelijk businesswaarde.

Dat vraagt om andere reflexen. Size voor het patroon in plaats van de piek. Richt autoscaling in in plaats van te provisioneren voor “het geval dat”. Schakel workloads uit waar het mag in plaats van ze aan te laten omdat het kan. Evalueer de architectuur continu in plaats van één keer per drie jaar.

Het zijn reflexen die on-premise teams nooit hebben hoeven ontwikkelen, omdat het er niet toe deed. In Azure doet het er elke maand toe. Letterlijk, op de factuur.

Lift-and-shift mag prima, als startpunt

Misverstand uit de weg: lift-and-shift is geen foute strategie. Het is vaak juist de snelste, veiligste manier om uit een verouderd datacenter te komen, om van een aflopend Windows Server- of SQL Server-supportcontract af te zijn, of om VMware-licenties achter je te laten. Voor veel organisaties is het de enige realistische eerste stap.

De fout zit in het behandelen van de lift-and-shift als betonnen eindstation. Wie na de migratie niet onmiddellijk gaat right-sizen, monitoren en optimaliseren, betaalt in de praktijk al snel drie tot vijf jaar lang premium cloudprijzen voor on-premise overcapaciteit. Dat is een aanpak-probleem, geen Azure-probleem.

Wat dit concreet vraagt

Een goede Azure-omgeving voor data-workloads heeft drie dingen nodig. Doorlopend inzicht in wat je verbruikt versus wat je nodig hebt. VM-keuzes die passen bij het karakter van de daadwerkelijke workloads. Review en rightsizing opnemen als integrale verantwoordelijkheid, en het lef om actie te ondernemen op die inzichten: terugschalen, uitzetten, herarchitecturen waar het loont.

Bij OptimaSure combineert Henk dat in één aanpak. De Azure Cost Scan brengt binnen 30 dagen in kaart waar je geld weglekt: overgedimensioneerde VM’s, verkeerd gekozen type hardware families, idle resources, storage hotspots. CloudXcellence, de eigen tooling van OptimaSure, koppelt binnen één dag aan je Azure-omgeving en laat per resource categorie en op resource niveau zien wat je kunt besparen. Je klikt direct door naar actie. Geen ticket, geen wachtrij, geen rapport in een lade.

Voor de data-specifieke kant (SQL Server-configuraties, indexstrategie, query-optimalisatie) schakelt OptimaSure de DBA-expertise van zusterbedrijf OptimaData in. Want zonder gezonde databases geen gezonde cloudfactuur.

De snelste manier eruit, de duurste manier erin

Lift-and-shift is de snelste manier om uit je datacenter te komen. Zonder vervolgstap is het ook de duurste manier om in Azure te blijven hangen, en die rekening loopt elke maand opnieuw door.

Twintig tot dertig procent besparen op je Azure-factuur is voor de meeste organisaties geen optimistische aanname, maar laaghangend fruit. De vraag is alleen: wie plukt het?

Wil je weten waar jouw Azure-omgeving lekt? Vraag een Azure Cost Scan aan. Binnen 30 dagen inzicht, binnen 31 dagen structureel besparen.