Vraag een partner voor cloudmigratie voordat je tekent hoe hij inventariseert wat je draait, per applicatie een migratiestrategie kiest, de doelomgeving ontwerpt en beveiligt, elke omschakeling kan terugdraaien, je de kosten laat zien en je team voorbereidt om het resultaat te beheren. Concrete, schriftelijke antwoorden zeggen meer over de migratie die voor je ligt dan het dagtarief.
Vraag hoe ze uitzoeken wat je werkelijk draait
Een migratieplan is zo goed als de inventaris erachter. Vraag de partner hoe hij die opbouwt: uit gesprekken met de eigenaren van applicaties, uit infrastructuurdata zoals servermetrics en netwerkverbindingen, uit de code zelf, of uit alle drie. Bestaande documentatie is een beginpunt, geen bewijs, want ze raakt steeds verder verwijderd van wat er werkelijk draait.
Vraag wat de inventaris vastlegt en wie er daarna eigenaar van is. Een goed antwoord noemt de velden en bevestigt dat de inventaris bij jou blijft, wat je daarna ook besluit.
- Elke applicatie, de eigenaar vanuit de business en hoe kritiek ze is
- Runtimes, frameworks en besturingssystemen, met een markering bij alles wat end-of-life is
- Databases, gedeelde mappen, geplande taken en queues waar elke applicatie van afhangt
- Integraties in beide richtingen, ook de integraties die niemand heeft gedocumenteerd
- Licenties die gekoppeld zijn aan hardware of aantallen processoren en misschien niet naar de cloud meegaan
- Acceptabele downtime en de zakelijke kalender: maandafsluiting, piekseizoen, wettelijke deadlines
Verwacht een strategie per applicatie, niet één voor het hele landschap
Applicaties gaan op verschillende manieren naar de cloud. De gebruikelijke opties zijn een applicatie ongewijzigd verhuizen (rehost of lift and shift), haar met kleine aanpassingen op een ander platform zetten (replatform), bijvoorbeeld met een beheerde database, haar ombouwen om clouddiensten te gebruiken (refactor), haar vervangen door een SaaS-product, haar voorlopig laten waar ze is, of haar uitfaseren. Een partner die één aanpak voor alles voorstelt, heeft niet goed genoeg gekeken.
Vraag naar de criteria waarmee hij kiest, en vraag om ze vóór het tekenen toegepast te zien op drie of vier van je eigen applicaties. Zijn redenering over je echte systemen zegt meer dan een slide over de methode. Vraag vooral hoe hij omgaat met applicaties op runtimes die end-of-life zijn, want als je die ongewijzigd verhuist, neem je de oude risico's mee naar het nieuwe platform.
Zoek uit wie de landing zone ontwerpt en beveiligt
De landing zone is de voorbereide doelomgeving: accountstructuur, identiteit en toegang, netwerk, logging, versleuteling en de vangrails die elke applicatie erft. Een fout hier herhaalt zich in elke applicatie die erop landt. Vraag wie haar ontwerpt, of ze als code wordt vastgelegd, bijvoorbeeld met Terraform, en of je securityteam haar beoordeelt voordat de eerste applicatie verhuist.
Cloudbeveiliging is een gedeelde verantwoordelijkheid. De provider beveiligt de onderliggende infrastructuur, en jij blijft verantwoordelijk voor hoe je die configureert en gebruikt. Vraag de partner welke maatregelen hij inricht, welke bij je eigen team blijven, en hoe de toegang van zijn eigen engineers wordt verleend, gelogd en aan het eind weer ingetrokken.
- Aparte accounts of projecten per omgeving, met productie afgeschermd
- Single sign-on met gebruikers op naam en rollen met minimale rechten, zonder gedeelde beheerdersaccounts
- Centrale logging en audittrails die projectengineers niet kunnen uitzetten
- Standaard versleuteling in opslag en onderweg, met geheimen buiten de code
- Regio's die zijn gekozen om te voldoen aan je eisen voor dataresidentie en de AVG
Laat ze één omschakeling en één rollback met je doorlopen
De omschakeling (cutover) is het moment waarop verkeer en data overgaan naar de nieuwe omgeving, en daar is een migratie het meest zichtbaar voor de business. Vraag de partner om stap voor stap een omschakeling door te lopen voor een van je applicaties: hoe de data wordt gesynchroniseerd, hoe het verkeer wordt omgezet, welke controles daarna draaien en wie besluit dat het gelukt is.
Vraag daarna hoe ze terug zouden gaan. Een geloofwaardig plan noemt de voorwaarden die een rollback in gang zetten, de persoon die de beslissing neemt en hoe lang de oude omgeving beschikbaar blijft. Hebben gebruikers sinds het omzetten data in de nieuwe omgeving geschreven, vraag dan hoe die data terugkomt in de oude. Zwakke plannen slaan die vraag over.
Ons artikel over het migreren van honderden legacy-apps naar AWS laat zien hoe deze stappen runbooks worden in een groot applicatielandschap.
Wil de kosten zien voordat de eerste rekening binnenkomt
Cloudkosten gedragen zich anders dan die van een datacenter. Je betaalt voor wat draait, inclusief testomgevingen die niemand heeft uitgezet, opslag die blijft groeien en data die het netwerk van de provider verlaat. Vraag om een kostenraming per applicatie met de aannames op papier, en vraag hoe de partner die in de eerste maanden met het werkelijke gebruik gaat vergelijken.
Zicht op kosten is een ontwerpbeslissing, geen maandrapport. Vraag om tagregels die elke resource aan een applicatie en een eigenaar koppelen, budgetten en alerts vanaf de eerste dag, en een herziening van de instancegroottes zodra applicaties onder echte belasting hebben gedraaid. Cloudservers dimensioneren naar de oude hardware is een betrouwbare manier om te betalen voor capaciteit die niemand gebruikt.
Waarschuwingssignalen dat een migratievoorstel niet klaar is
Elk van deze signalen kan een verklaring hebben. Staan er meerdere in hetzelfde voorstel, dan is het risico meestal aan jou overgelaten om zelf te ontdekken.
- Een vaste planning voordat iemand je inventaris heeft gezien
- Eén migratiestrategie voor elke applicatie
- Geen schriftelijk rollbackplan, of een rollback die afhangt van het terugzetten van back-ups onder druk
- Cloudaccounts, infrastructuurcode of pipelines die van de partner zijn in plaats van van jou
- Kostenramingen zonder aannames, en geen plan voor tags of budgetten
- Kennisoverdracht gepland in de laatste week
Plan de kennisoverdracht vanaf de eerste week, niet de laatste
De migratie eindigt; het beheer van het platform niet. Vraag hoe je team leert te beheren wat er wordt gebouwd: samenwerken aan echte taken tijdens de migratie, runbooks voor terugkerende handelingen, en een rondleiding door monitoring en alerts met de mensen die dienst gaan draaien.
Vraag dat alles vanaf het begin in jouw accounts en repositories staat: infrastructuurcode, pipelines, runbooks en diagrammen. Spreek daarna af hoe de overdracht wordt geaccepteerd, bijvoorbeeld doordat je team zonder hulp van de partner een applicatie deployt en weer terugdraait.
We werkten mee in het team dat 600+ interne applicaties van Crédit Agricole van legacy-VM's naar AWS verhuisde, en leverden zelf 50+ van die migraties op. Wil je een second opinion op een migratievoorstel, of een team dat een deel van het werk oplevert, dan kunnen onze engineers voor cloudinfrastructuur deze vragen met je doorlopen.
De kern
- Vraag hoe de inventaris wordt opgebouwd en gecontroleerd, want elke schatting en elke planning in golven hangt ervan af.
- Verwacht een migratiestrategie die per applicatie wordt gekozen, met criteria die je op je eigen systemen toegepast ziet.
- Laat de landing zone als code vastleggen, beoordelen door je securityteam en bewaren in je eigen accounts.
- Accepteer geen omschakelplan zonder een benoemde trigger voor rollback en een manier om data terug te halen die na het omzetten is geschreven.
- Spreek tags, budgetten en de acceptatie van de overdracht af voordat de eerste applicatie verhuist.
Veelgestelde vragen
Moet de partner die ons landschap analyseert het ook migreren?
Dat kan, en het scheelt vaak tijd, omdat het team dat de inventaris opbouwde de randgevallen kent. Koop de analyse in als een apart resultaat waarvan jij eigenaar bent, zodat je ermee naar een andere partner kunt als het migratievoorstel je niet overtuigt.
Hoe vergelijk je voorstellen van verschillende migratiepartners?
Geef elke partner hetzelfde uittreksel uit de inventaris en dezelfde vragen, en vraag elk om zijn criteria op dezelfde paar applicaties toe te passen. Vergelijk de redenering, de rollbackplannen en de aannames achter de schattingen, niet alleen de totaalprijs.
Kan ons team tijdens de migratie nieuwe functies blijven uitbrengen?
Ja, als het plan zegt hoe. Spreek per applicatie een periode af waarin wijzigingen bevroren zijn, een manier om beide omgevingen synchroon te houden tijdens de verhuizing, en wie releases goedkeurt terwijl een applicatie onderweg is.