Cloud migratie: stappenplan voor bedrijven die klaar zijn voor de cloud
Overweeg je een cloud migratie? Leer de strategieën, valkuilen en een bewezen stappenplan voor een succesvolle overgang.
Cloud migratie is het verplaatsen van applicaties, data en infrastructuur van lokale servers naar een cloudplatform als AWS, Azure of Google Cloud. Voor middelgrote bedrijven levert het aantoonbaar lagere beheerkosten, betere schaalbaarheid en toegang tot moderne diensten — mits de strategie klopt. Goed uitgevoerd biedt de cloud structureel voordeel. Slecht uitgevoerd is het duurder dan wat je achterliet. Hier is hoe je het aanpakt.
Waarom migreren naar de cloud?
De meeste organisaties kijken naar de cloud om vijf redenen. Niet alle vijf zijn even zwaar — de balans verschilt per organisatie.
- Schaalbaarheid op aanvraag. Capaciteit uitbreiden of inkrimpen zonder hardware-investeringen. Piekmomenten kosten niet meer dan nodig.
- Lagere beheerlasten. Geen fysieke servers, geen datacentrumkosten, minder interne IT-beheer. De provider beheert de onderlaag; jij beheert wat erop draait.
- Locatieonafhankelijkheid. Cloudtoepassingen zijn bereikbaar waar ook een internetverbinding is. Relevant voor hybride teams en meerdere vestigingen.
- Ingebouwde continuïteit. Cloud providers bieden redundantie en disaster recovery als standaardfunctie, niet als dure add-on.
- Toegang tot moderne diensten. AI, machine learning, geavanceerde analytics — die zitten al in het cloudplatform. Je activeert ze wanneer jij er klaar voor bent, zonder nieuwe infrastructuur.
McKinsey (2023) stelde vast dat organisaties die naar de cloud migreerden gemiddeld 20–30% besparen op totale IT-infrastructuurkosten, mits ze ook hun workloads rationaliseren. Die besparing is niet automatisch. Ze is het resultaat van bewuste keuzes — zie de valkuilen-sectie.
De 6 migratiestrategieën.
AWS formuleerde de '6 Rs' en ze zijn inmiddels industrie-standaard. Elke applicatie vraagt om een afzonderlijke beslissing — er is geen universele aanpak die voor alle systemen werkt.
| Strategie | Wat het betekent | Wanneer het past |
|---|---|---|
| Rehost (lift-and-shift) | Applicatie kopiëren naar cloud zonder aanpassingen | Snel migreren, later optimaliseren |
| Replatform | Kleine aanpassingen voor cloudcompatibiliteit, geen code-herschrijving | Managed databases, geoptimaliseerde runtime |
| Repurchase | Overstap naar een SaaS-product | Legacy CRM → Salesforce, on-prem HR → Workday |
| Refactor / Re-architect | Applicatie herbouwen voor cloudnatieve architectuur | Strategisch systeem met lange levensduur |
| Retire | Applicatie uitfaseren | Systeem heeft geen actieve gebruikers meer |
| Retain | Voorlopig lokaal houden | Compliance-vereisten, recent geïnvesteerd, te complex voor nu |
Voor de meeste middelgrote organisaties ziet de verdeling er zo uit: 40% rehost, 30% replatform of repurchase, 20% retain, 10% retire of refactor. Die laatste categorie — refactor — is duur en tijdrovend. Plannen ermee is zinvol, maar doe het bewust, niet als standaardkeuze voor elke applicatie.
Stappenplan: hoe een cloud migratie in de praktijk werkt.
Een cloud migratie is geen eenmalig event maar een gestructureerd programma. Vijf fasen:
- Discovery en inventarisatie. Breng in kaart welke applicaties je hebt, wat ze doen, hoeveel ze kosten en welke afhankelijkheden er bestaan. Gebruik tools als AWS Migration Evaluator of Azure Migrate als startpunt. Doel: geen verrassingen halverwege. Elke ongedocumenteerde afhankelijkheid die je later ontdekt, kost tijd en geld.
- Prioritering en portfoliobeslissing. Pas de 6 Rs toe op elke applicatie. Groepeer ze in migratiegolven: wave 1 zijn de low-risk, high-gain kandidaten. Begin nooit met je meest complexe core-systeem — dat is de zekere weg naar vertraging en kostenoverschrijding.
- Foundation en landingszone. Richt je cloudomgeving in voordat je de eerste applicatie verplaatst. Netwerksegmentatie, identity & access management (IAM), logging, monitoring, kostenmanagement. Dit is het meest onderschatte onderdeel van een migratie — en het meest kritische. Een slecht ingerichte landingszone vergt achteraf maanden aan opschonen.
- Piloot en wave 1. Migreer 2–3 niet-kritieke applicaties. Valideer je aanpak, leer van de uitvoering en documenteer wat werkt. Pas je playbook aan op basis van de eerste ervaringen voordat je de rest inplant.
- Uitrol en optimalisatie. Verplaats de rest in opeenvolgende golven. Na elke golf: kosten reviewen, performance meten, ongebruikte resources opschonen. Cloud-optimalisatie is een continu proces, geen eindpunt.
Kosten en valkuilen.
Cloud is goedkoper. In theorie. Drie factoren maken migraties in de praktijk duurder dan gepland.
Verborgen kosten die budgetten opblazen:
- Egress fees. Data uit de cloud sturen kost geld. Bij hoge datavolumes — denk aan grote databasesyncs of mediabestanden — loopt dit snel op. Dit staat zelden in de eerste begroting.
- Ongebruikte resources. Cloud is flexibel, maar ook makkelijk vergeten. Niet-verwijderde volumes, idle instances, over-geprovisioned databases kosten elke maand geld. Onderzoek van Flexera (2024) laat zien dat organisaties gemiddeld 28% van hun clouduitgaven verspillen aan ongebruikte of onderbenutte resources.
- Licenties. Windows Server, SQL Server, Oracle — sommige licenties zijn niet zonder extra kosten overdraagbaar naar de cloud. Controleer dit vooraf, niet achteraf.
- Opleiding en inwerking. Je team moet de cloud leren beheren. Dat kost tijd en geld, maar wordt zelden in het budget opgenomen.
Aanpak-valkuilen die projecten doen mislukken:
- Lift-and-shift als eindbestemming. Snel migreren is een prima strategie voor snelheid — maar niet als eindpunt. Een applicatie die voor on-premise werd gebouwd, presteert suboptimaal in de cloud zonder optimalisatie. Plan die optimalisatie in, of betaal structureel te veel.
- Geen governance van dag 1. Cloudomgevingen groeien snel en chaotisch zonder structuur. Achteraf opruimen kost meer dan vooraf inrichten.
- Te ambitieuze scope. Organisaties die alles tegelijk willen migreren, lopen vast. Begin klein, leer snel, schaal daarna op.
Lift-and-shift vs. re-architecture: wanneer kies je wat?
Dit is de meest gestelde vraag bij cloud migraties. Het eerlijke antwoord: beide hebben hun plaats. De keuze hangt af van het systeem, niet van een universele voorkeur.
| Lift-and-shift | Re-architecture | |
|---|---|---|
| Snelheid | Weken tot maanden | Maanden tot jaren |
| Initiële kosten | Laag | Hoog |
| Kosten na 1–2 jaar | Stijgend (suboptimale cloud-fit) | Dalend (cloud-native efficiëntie) |
| Risico | Laag | Hoog |
| Aanbevolen voor | Snel migreren, legacy uitfaseren later | Strategisch systeem met lange levensduur |
Lift-and-shift is geen slechte keuze. Het is een bewuste keuze om nu snelheid te prioriteren en optimalisatie later te doen. Dat werkt — als je die optimalisatie daadwerkelijk plant en uitvoert. Organisaties die lift-and-shift als permanente eindtoestand behandelen, betalen structureel te veel voor suboptimale cloudprestaties.
Re-architecture is de juiste keuze voor systemen die de komende vijf tot tien jaar cruciaal blijven. De hogere initiële investering betaalt zich terug in lagere beheerkosten, betere performance en toekomstige uitbreidbaarheid. Combineer beide aanpakken per applicatie — dat is wat de meest succesvolle migratieprogramma's doen.
Een cloud migratie is meer strategie dan technologie. De organisaties die er aantoonbaar voordeel uit halen, beginnen met een helder beeld van waarom ze migreren, kiezen per applicatie de juiste aanpak en bouwen governance in vanaf dag één. Meer weten over hoe je dat aanpakt voor jouw specifieke situatie?