Ervaringen met overstappen naar Microsoft Azure

[Imre Himmelbauer]

Hey iedereen,

Naar aanleiding van dit stuk wilde ik graag een artikel schrijven over servermigraties, specifiek naar Azure. Ik zag in de opmerkingen aardig wat vragen over waarom de migratie van GitHub zo 'lang' moet duren. Op mij komt het, gezien de omvang van het platform, best logisch over, maar ik kan dat niet onderbouwen aangezien ik 'maar' journalist ben. Zijn er hier systeembeheerders die ervaring hebben met (grote) migraties en daar wat meer over kunnen vertellen? Ik snap uiteraard dat waarschijnlijk niemand heel specifiek op GitHub zelf in kan gaan, aangezien je voor de ins en outs van deze migratie toegang moet hebben tot de servers van GitHub. Maar wat meer informatie over wat er allemaal komt kijken bij een (Azure-)migratie zou enorm helpen!

Bedankt alvast!

Imre

[Hero of Time]

Een lift'n'shift is relatief snel gedaan, maar als je te maken hebt met een legacy omgeving dat je geschikt wilt maken voor de toekomst, zal je aardig wat werk moeten verzetten om het naar huidige technieken om te zetten. Denk van complete VMs waar een webserver in draait naar een cluster van containers die dynamisch opschalen afhankelijk van de load. En dan heb je het alleen nog maar over het simpel serveren van je content en Git repository (die overigens ook aardig wat werk vereist om te verhuizen).

Er kunnen ook taken op de achtergrond draaien, pipelines en automations om builds te controleren e.d. Dat moet je ook zo maken dat het resultaat hetzelfde is, zowel tussen de twee platformen als met elke run.

Ik heb wel eens in m'n eentje migraties gedaan tussen hypervisors en nieuwe hardware. Dat kostte dan een weekend bijna non-stop werk op wat pauzes voor eten en slapen na. MS heeft natuurlijk een heel team of meerdere wereldwijd om dit uit te voeren, maar dat maakt de hoeveelheid werk niet minder. Bij mij ging het om complete VMs, maar als je zoals eerder al aangegeven de techniek gaat moderniseren is dat een stuk complexer. Op m'n huidige werk zijn de ontwikkelaars ook bezig om hun code meer geschikt te maken om in containers te kunnen draaien. Afhankelijk van de technical debt die je hebt, is dit niet zomaar 'eventjes' gedaan.

[Jazzy]

Om te beginnen moet je je realiseren dat 'Azure' bestaat uit meer dan 200 verschillende diensten. De bekendste is waarschijnlijk die waar je een complete virtuele server afneemt waar je dan zelf software op installeert, maar er zijn ook talloze andere diensten voor bijvoorbeeld databases, verwerken van grote hoeveelheden berichten, speech, machine learning, AI, etc.

Daarnaast is een dienst als Github een product waarvan de ontwikkeling gestart is in een tijd dat cloud-computing nog geen ding was. Startend met een heel basaal platformpje waar in de afgelopen 17 jaar (!) allerlei dingen aan toegevoegd zijn. Hoe je dingen in zeg 2012 aan elkaar knoopte is misschien niet hoe je het anno 2025 zou doen, laat staan dat men op dat moment kon voorzien dat je ooit meer dan 100 miljoen gebruikers zou hebben. Een enorm complexe, grote omgeving dus met allerlei onderliggende issues en technology debt.

Zo'n migratie zal dus geen lift and shift zijn, want dan neem je alle onderliggende problemen mee die je vervolgens als nog een keer zult moeten aanpakken. Dat betekent dat ieder onderdeel bekeken moet worden en je zorgvuldig moet plannen hoe je van alle legacy af gaat komen en in plaats daarvan moderne en schaalbare diensten gaat gebruiken. Super super complex dus.

Als je het zo bekijkt is een tijdlijn van 18 tot 24 maanden helemaal niet zo bijzonder. Voor context, als hier in Nederland een bedrijf van gemiddelde omvang een ander bedrijf overneemt en ze allebei dezelfde technische oplossingen gebruiken (zeg Windows voor de desktop, AD en Entra voor authenticatie, Microsoft 365 voor collaboration) dan praat je al snel over een doorlooptijd van eerste uitdenken tot afronden van de uitvoering van snel 6 maanden tot een jaar.

Dan heb je natuurlijk bij kleine organisaties kleine problemen, bij grote organisaties grote problemen. Denk aan politiek, kritieke personen die ineens op vakantie zijn of een andere baan hebben gevonden, inhuur van externen voor specifieke zaken, etc.

Het blijft heel lastig om uit te leggen aan iemand voor wie dit geen dagelijkse kost is, maar met mijn 30 jaar ervaring waarvan de laatste 15 in de grootzakelijke hoek kan ik wel zeggen dat ik niet zo schrik van die doorlooptijd.

[Blokker_1999]

Het is een typisch geval van mensen zonder ervaring die denken dat je zoiets wel snel even doet. Kan toch niet moeilijk zijn. Gewoon even alles overzeten, live gaan en klaar ermee. Maar als je eenmaal enkele grotere ICT infra projecten gedaan hebt, dan besef je dat het zo eenvoudig niet is natuurlijk.

Bij ons in de firma is recent ook de beslissing genomen om weg te migreren van on-premise servers naar Azure. Wij hebben daar een tijdsvak van maar liefst 5 jaar voor voorzien. Niet alleen omdat we geen lift and shift willen doen, maar ook omdat we alles tussendoor draaiende willen houden zonder dat er echt mankracht bij komt.

Zoals @Jazzy aangeeft gaat Github dit waarschijnlijk ook als kans aanzien om alles te moderniseren. Hoewel ik er niet aan twijfel dat Github vandaag al veel met kubernetes en Infrastructure-as-Code doet, veranderd de onderliggende omgeving wel enorm. Dat wil zeggen dat je van 0 af aan je architectuur moet gaan herontwerpen. Nadat je dat gedaan hebt moet je je automatisatie gaan herontwerpen en grondig testen. Daarbij ga je ook proberen van verouderde concepten weg te gooien en nieuwere concepten op te zetten. Dat moet allemaal ook zeer grondig getest worden voordat je iets in productie kunt zetten.

En dan heb je nog het formaat van de omgeving. Ik heb geen idee hoe groot Github is, maar het zal een gestage migratie zijn waarbij eindgebruikers niet veel mogen zien van die migratie. Want dan lever je slecht werk af. Ook daarvoor zal men meerdere, tijdelijke oplossinen moeten zoeken en grondig uittesten voordat men die live zet.

En bedenk dan ook nog even dat Github onderdeel van Microsoft is en dus vermoedelijk sneller support kan krijgen en escaleren in geval van problemen dan wanneer externe partijen zo een migratie zouden doen. Daarnaast vermoed ik ook dat Microsoft de problemen wil voorkomen die ze hadden na de overname van Hotmail en de migratie die ze daar gedaan hebben.

[Imre Himmelbauer]

Dank voor de uitgebreide reacties iedereen!

@Jazzy Is het te zeggen welke Azure-diensten mogelijk interessant zijn voor GitHub? Ik kan me namelijk bijvoorbeeld voorstellen dat Entra ID en vooral Blob Storage goede oplossingen zouden zijn voor dat platform.
@Blokker_1999 Wat komt er zoal kijken bij het proces dat je omschrijft? Dus het herontwerpen van een architectuur en de automatisatie, het vernieuwen van de concepten en dan het testen van alle zaken?
En hat zal denk ik vrij moeilijk zijn om te achterhalen wat de technical debt van GitHub is? Kan me wel voorstellen dat die aanzienlijk is, vooral zoals @Jazzy omschrijft door de mate waarin het platform is gegroeid.

[GarBaGe]

Imre Himmelbauer schreef op vrijdag 10 oktober 2025 @ 10:11:
... Is het te zeggen welke Azure-diensten mogelijk interessant zijn voor GitHub?...

Bij zo'n enorme klus wil je eigenlijk zoveel mogelijk as-is migreren (lift n shift) en dus niet gelijk ook allemaal veranderingen en aanpassingen doen.
Als je dat wel doet, verlaagd dat de kans op succes en verlengd dat de migratietijd.

Zodra de migratie een feit is, zouden ze een 2e project kunnen opstarten om Github te moderniseren, tech debt weg te werken en mogelijk meer Azure services te gaan gebruiken.

[Jazzy]

Imre Himmelbauer schreef op vrijdag 10 oktober 2025 @ 10:11:
@Jazzy Is het te zeggen welke Azure-diensten mogelijk interessant zijn voor GitHub? Ik kan me namelijk bijvoorbeeld voorstellen dat Entra ID en vooral Blob Storage goede oplossingen zouden zijn voor dat platform.

Het zou best kunnen dat Microsoft op termijn een Entra ID dienst gaat gebruiken voor de identiteiten en het aanmelden, maar dat is een goed voorbeeld van een verandering die impact op werkelijk al het andere heeft. Stel dat een gebruiker op een repo klikt of een commit wil doen, dan moet worden bekeken wie de gebruiker is en of die daar rechten toe heeft. De kans is groot dat we het dan niet over één functie hebben die moet worden aangepast, maar dat er een wildgroei is van allerlei code die je moet controleren en aanpassen.

Blob storage zou best een onderdeel van de oplossing kunnen zijn, misschien ook niet. Zonder de architectuur van Github te kennen valt daar echt geen zinnig woord over te zeggen.

Ik begrijp dat je het probeert plat te slaan, maar het is toch een beetje als een Gamma binnenlopen en vragen in welk pad de spullen staan om Almere na te bouwen.

[ Voor 7% gewijzigd door Jazzy op 10-10-2025 11:37 ]

[Question Mark]

Imre Himmelbauer schreef op donderdag 9 oktober 2025 @ 11:40:
Naar aanleiding van dit stuk wilde ik graag een artikel schrijven over servermigraties, specifiek naar Azure.

Een "servermigratie" is een simpele lift-and-shift, en slechts één van de manieren om workloads te verplaatsen. Om de juiste strategie te bepalen wordt veelal het "7R-model" gehanteerd:

Select your cloud migration strategies

(Retire, Rehost, Replatflorm, Refactor, Rearchitect, Replace, Rebuild, Retain)

Rebuild is daarbij de meest complexe en meest tijdrovende. Ik schat de kans aardig groot in dat Microsoft nu voor de migratie van Github deze aanpak gaat hanteren.

A rebuild strategy is a full redevelopment of a workload using cloud-native solutions. This approach is appropriate when legacy systems are obsolete or when modernization isn't feasible. Rather than modernizing legacy functionality, you can reimagine the solution to use Azure capabilities like PaaS, automation, and AI. Some workloads required a rebuild, like DHCP server. For other workloads, it's better to deploy new instances of services in Azure rather than migrating them, such as Active Directory Domain Controllers.

[ Voor 3% gewijzigd door Question Mark op 10-10-2025 11:53 ]

[Imre Himmelbauer]

Ik heb het idee dat de reacties van @GarBaGe en @Question Mark wat tegenstrijdig zijn, klopt dat? Of is het mogelijk dat je eerst as-is migreert en vervolgens alsnog een complete rebuild van je systeem doet?

[F_J_K]

Er is niet 1 mogelijke laat staan 1 beste manier voor een migratie. En verschillende mensen kunnen vanuit hun optiek en hun ervaring andere ideeen hebben. Waar ik vermoed dat geen van ons weet hoe het bij specifiek GitHub gaat.

Soms kan ‘oppakken en over de muur gooien’ handig zijn, soms niet. Wat dat betreft is https://learn.microsoft.c...-cloud-migration-strategy een leuke samenvatting van opties.

Een migratie naar Azure die bij mij gaande is, gaat over een aantal los van elkaar draaiende maar soms wel met elkaar gekoppelde serverapplicaties. Per applicatie wordt gekeken wat wijsheid is. As-is over zetten, inrichting en data migreren naar de SaaS-variant, nieuwe installatie in Azure en dan inrichting en data overzetten, iets anders kiezen. Op het juiste tempo voor de betreffende applicatie, wat ook betreft gebruikerstesten en de periode waarop het beste de downtime kan worden gepland. Tot nu toe is nul keer gekozen voor lift&shift.

En in Azure kan je dan meer aandacht hebben voor het beheer en de beveiliging van de dan daar draaiende servers. Qua (virtuele) netwerken, qua backup, qua beheer. Waar dan tenminste de (technisch) beheerders-accounts waar mogelijk wel in EntraID staan ook waar dat voor users en functioneel beheer nog niet kan - en worden beveiligd met de vele opties daar.

Edit: maar dat zal voor 1 hele grote gedistribueerde maatwerkapplicatie heel anders zijn.

[ Voor 3% gewijzigd door F_J_K op 10-10-2025 14:33 ]

[Question Mark]

Imre Himmelbauer schreef op vrijdag 10 oktober 2025 @ 13:55:
Ik heb het idee dat de reacties van @GarBaGe en @Question Mark wat tegenstrijdig zijn, klopt dat? Of is het mogelijk dat je eerst as-is migreert en vervolgens alsnog een complete rebuild van je systeem doet?

Dat is afhankeljk van het doel....

Als de technisch infra van de huidige omgeving op instorten staat zou het een goed doel kunnen zijn om zo snel mogelijk te migreren naar een Infrastructure-As-A-Service (IAAS) cloudoplossing (Rehost of Replatform).

Als het doel is om zo schaalbaarheid en prijstechnisch het meeste uit de cloud te halen, dan is overstappen naar cloudnative (Rebuild) een betere optie..

De eerste wordt ook wel "transitie" genoemd, en de tweede "transformatie". En deze kunnen ook in tijd na-elkaar doorlopen worden. Dus eerst de zooi zo snel mogelijk naar Azure (transitie), en daarna nog een transformatie doorlopen. De totale doorlooptijd van dat traject is alleen langer, kostbaarder en vraagt meer van mensen. Beide fases moeten immers gepland, getest en doorlopen worden (nog los van mogelijke tijdelijke impact op beschikbaarheid van diensten).