Terug naar de blog
30 augustus 2026

Zo migreert het MKB naar de cloud: 7R strategie en praktische checklist

IT-specialist houdt de serverstatus in de gaten tijdens de cloudmigratie

De meeste MKB-bedrijven migreren het beste gefaseerd naar de cloud: begin met e-mail en samenwerking via Microsoft 365 en behoud kritieke legacy-systemen tijdelijk on-premise. Bepaal per applicatie een 7R-strategie en start altijd met een grondige inventarisatie. Astia begeleidt dit traject dagelijks bij MKB-bedrijven en ziet dat een discoveryfase het verschil maakt tussen een soepele overstap en een dure verrassing.

Kort samengevat:

  • Een gefaseerde aanpak begint met het migreren van e-mail via Microsoft 365, terwijl kritieke legacy-systemen voorlopig on-premise blijven.
  • De keuze voor migratiestrategieën hangt af van de systemen’ kritiek, afhankelijkheden en de kosten van migratie versus behoud.
  • Een uitgebreide inventarisatie en een discoveryfase voorkomen verrassingen en zorgen voor een soepele overgang naar de cloud.
  • Bij e-mailmigratie speelt de schaalgrootte een rol: tot enkele honderden mailboxen is een cutover-migratie geschikt, bij grotere omgevingen hybri­de aanpak.
  • Na de migratie blijven kostenbeheer, beveiligingsinstellingen en rightsizing cruciaal om onverwachte hogere cloudkosten te voorkomen.

Inhoudsopgave

Wat is het verschil tussen on-premise en cloud voor het MKB?

Bij on-premise beheer draaien je servers, software en data in je eigen pand of datacenter. Je betaalt vooraf voor hardware (CAPEX) en je IT-team of leverancier houdt alles draaiende: updates, back-ups, beveiliging. Bij cloud diensten huur je rekenkracht en opslag bij een aanbieder zoals Microsoft en betaal je maandelijks (OPEX), meestal per gebruiker.

Die overstap van on-premise naar cloud levert MKB-bedrijven een paar concrete voordelen op:

  • Voorspelbare kosten: geen grote investeringen vooraf, wel een vast maandbedrag.
  • Minder beheerslast: patches, updates en serverbeheer verschuiven naar de cloudleverancier.
  • Flexibel schalen: extra gebruikers of opslag regel je binnen dagen, niet maanden.
  • Overal werken: medewerkers werken net zo makkelijk thuis als op kantoor.

On-premise oplossingen blijven soms de betere keuze. Denk aan software met strikte dataresidency-eisen, machines die met lage latency moeten communiceren met productieapparatuur, of verouderde systemen die simpelweg niet cloud-geschikt zijn. In die gevallen is een hybride opzet vaak realistischer dan een volledige overstap.

Welke migratiestrategie past bij welke applicatie?

Niet elke applicatie verdient dezelfde aanpak. Het 7R-raamwerk geeft zes duidelijke routes om per systeem te bepalen hoe je het naar de cloud brengt, of dat je het juist laat staan.

  1. Rehost: je verplaatst een applicatie ongewijzigd naar de cloud (“lift and shift”). Snel, maar je profiteert nog niet van cloudvoordelen.
  2. Replatform: kleine aanpassingen tijdens de verhuizing, bijvoorbeeld een database omzetten naar een beheerde clouddienst.
  3. Refactor: de applicatie wordt herbouwd om optimaal cloud-native te draaien. Duurder, maar toekomstbestendig.
  4. Repurchase: je vervangt de oude applicatie door een clouddienst die hetzelfde doet, zoals e-mail via Microsoft 365 in plaats van een eigen Exchange-server.
  5. Relocate: je verplaatst een hele werklast naar de cloud zonder de onderliggende architectuur aan te passen.
  6. Retain: je houdt het systeem voorlopig on-premise, bijvoorbeeld vanwege compliance of een naderend einde van de levensduur.
  7. Retire: je zet de applicatie helemaal uit omdat niemand hem nog echt gebruikt.

Kies per applicatie op basis van drie criteria: hoe kritiek is het systeem voor de bedrijfsvoering, hoeveel afhankelijkheden heeft het met andere software, en wat kost het om te migreren versus te laten staan. Een fileserver leent zich vaak voor rehost of replatform naar OneDrive en SharePoint. Een verouderd boekhoudpakket zonder cloudvariant blijft soms het beste gewoon staan, tot vervanging logischer wordt.

Pro-tip: Begin de 7R-oefening met je meest gebruikte applicaties, niet met de ingewikkeldste. Zo boek je snel zichtbare resultaten en leert je team hoe migreren in de praktijk werkt.

Hoe stel je een discovery-checklist op voor je migratie?

Een goede cloud migratie begint niet met migreren, maar met tellen. Wat heb je eigenlijk, wie gebruikt het, en wat gebeurt er als het uitvalt? Zonder die inventarisatie plan je in het duister, en dat leidt tot technische schuld die je juist tijdens een migratie kunt opruimen.

Zet minstens deze onderdelen op je lijst:

  • Servers en applicaties: welke systemen draaien er, wie is de eigenaar en wanneer is de laatste update geweest?
  • Koppelingen en afhankelijkheden: welke systemen praten met elkaar en breekt er iets als je er één verplaatst?
  • Compliance-eisen: welke data valt onder specifieke bewaarplichten of sectorregels?
  • Gebruik en prioriteit: scoor elk systeem op impact bij uitval en op migratiegemak, zodat quick wins bovenaan komen.

Neem ook de beveiligingskant direct mee. Controleer of multifactor-authenticatie overal staat ingesteld, welke data versleuteld is (in rust en onderweg), en wat je back-up-strategie is inclusief RTO (hersteltijd) en RPO (maximaal dataverlies). Bij een cloudmigratie geldt het shared responsibility model: de cloudleverancier beveiligt het platform, jij blijft verantwoordelijk voor toegang, instellingen en data.

Cutover, hybride of IMAP: welke route past bij jouw mailmigratie?

E-mail is voor de meeste MKB-bedrijven de eerste stap naar de cloud, en Microsoft biedt daarvoor drie hoofdroutes. Een cutover-migratie verplaatst alle mailboxen in één keer en past bij kleinere organisaties (doorgaans tot een paar honderd mailboxen). Een hybride migratie laat je geleidelijk mailboxen overzetten terwijl de oude en nieuwe omgeving naast elkaar draaien, ideaal voor grotere of complexere omgevingen. IMAP-migratie gebruik je vooral bij overstappen vanaf niet-Exchange-systemen.

Let hierbij goed op: IMAP migreert alleen mailboxitems zoals e-mails, maar geen agenda’s, contactpersonen of taken. Die moet je apart migreren of handmatig overzetten.

Een praktisch stappenplan ziet er zo uit:

  • Draai eerst een pilot met een kleine, niet-kritieke gebruikersgroep.
  • Synchroniseer mailboxen voordat je de definitieve overstap maakt.
  • Wijzig de DNS/MX-records pas nadat synchronisatie is geverifieerd.
  • Controleer na de overstap steekproefsgewijs of agenda’s en contacten compleet zijn.

Volgens indicaties uit de branche duurt een e-mailmigratie doorgaans één tot twee weken, tegenover vier tot acht weken voor een volledige serveromgeving.

Hoe voorkom je downtime tijdens de cutover?

Migreren in golven werkt beter dan alles ineens overzetten. Begin klein, leer van elke fase en schaal pas op als je vertrouwen hebt in het proces.

  1. Pilotgolf: één afdeling of een beperkte gebruikersgroep, liefst met laag risico bij problemen.
  2. Golf 1, laag risico: systemen die weinig kritiek zijn voor de dagelijkse bedrijfsvoering.
  3. Volgende golven: steeds kritischere systemen, tot je bij de zwaarste workloads uitkomt.

Test bij elke golf drie dingen grondig: functioneert de applicatie zoals verwacht (UAT), presteert hij snel genoeg onder normale belasting, en werkt de back-up en restore daadwerkelijk. Een back-up die je nooit hebt teruggezet, is in de praktijk geen back-up.

Voor de cutover zelf geldt een vaste checklist: verlaag ruim van tevoren de TTL-waarde van je DNS-records zodat wijzigingen snel doorkomen, communiceer duidelijk naar gebruikers wanneer systemen tijdelijk niet bereikbaar zijn, en voer vlak voor de overstap nog een laatste synchronisatie uit. Regel ook een rollback-procedure, met een duidelijke eigenaar die de knoop doorhakt als iets misgaat. Een rollback die alleen op papier bestaat, werkt niet onder tijdsdruk.

Pro-tip: Wijs voor elke migratiegolf één verantwoordelijke aan die zowel het “go” als het “no-go”-besluit mag nemen. Zonder duidelijke eigenaar sneuvelt een rollback-plan vaak op het moment dat je het juist nodig hebt.

Wat moet je na de migratie blijven doen?

De grootste kostenfouten ontstaan pas ná de migratie, niet ervoor. Resources die na de overstap blijven draaien terwijl niemand ze meer gebruikt, zijn de meest genoemde reden voor onnodig hoge cloudrekeningen.

Zet daarom deze routine op:

  • Rightsizing: controleer maandelijks of resources passen bij het werkelijke gebruik, niet bij de oorspronkelijke schatting.
  • Tagging en budgetalerts: label kosten per afdeling of project en stel meldingen in bij afwijkingen.
  • Monitoring en incidentbeheer: bewaak prestaties actief in plaats van te wachten op klachten van gebruikers.
  • Periodieke reviews: plan elk kwartaal een korte evaluatie van kosten, prestaties en beveiligingsinstellingen.

Een managed partner ontzorgt precies op dit vlak: monitoring, SLA-bewaking en incidentafhandeling vragen continue aandacht die de meeste MKB-bedrijven er niet naast kunnen doen.

Wat leert Astia van migraties in de praktijk?

Astia begeleidt migraties voor MKB-bedrijven in uiteenlopende branches en ziet steeds hetzelfde patroon: bedrijven die eerst een migratiescan laten uitvoeren, lopen achteraf tegen veel minder verrassingen aan. Een typisch traject verloopt via een scan van de bestaande omgeving, gevolgd door een pilot met een beperkte gebruikersgroep, de daadwerkelijke implementatie in golven en een periode van hypercare vlak na de livegang, waarin extra ondersteuning klaarstaat voor onverwachte vragen. Die laatste fase wordt vaak onderschat, terwijl juist daar het vertrouwen van gebruikers wordt gewonnen of verloren.

De vier fasen van een cloudmigratie voor het MKB

Waarom checklists niet genoeg zijn

Een stappenplan met discoveryfase, pilot en golven klinkt logisch, en dat is het ook. Toch faalt de meeste migratie niet op de techniek, maar op wat daarna gebeurt. Bedrijven vieren de livegang en vergeten dat een cloudomgeving onderhoud vraagt dat structureel anders is dan bij een eigen server.

Waarom checklists niet genoeg zijn — overview diagram

De gangbare aanname is dat cloud migratie een project met een einddatum is. Dat klopt niet. Rightsizing, toegangsbeheer en kostenbewaking zijn geen nazorgtaken die je één keer afvinkt, maar een doorlopende verantwoordelijkheid. Bedrijven die dat onderschatten, zien binnen een jaar hun cloudkosten sluipend oplopen zonder dat iemand precies kan uitleggen waarom.

Wat de lezer dus als eerste zou moeten prioriteren, is niet de technische migratie zelf, maar de vraag wie na de livegang eigenaar wordt van kosten, beveiliging en performance. Regel dat eigenaarschap vóór je begint, niet erna. Een discoveryfase die alleen naar systemen kijkt en niet naar wie ze straks beheert, is maar half af.

— Mick

Astia als partner bij je overstap naar de cloud

Astia begeleidt MKB-bedrijven van eerste scan tot volledig beheerde cloudomgeving, zonder dat jij je bezig hoeft te houden met DNS-instellingen of rollback-procedures. Het kernaanbod bestaat uit een migratiescan die je omgeving in kaart brengt, managed werkplekbeheer voor de dagelijkse ondersteuning van je team, beheer van je Microsoft 365-omgeving en nazorg die net zo serieus wordt genomen als de migratie zelf.

Astia

Wat Astia onderscheidt van een eenmalig ingehuurde IT’er, is de combinatie van lokale betrokkenheid en een vast maandabonnement: geen verrassingen achteraf, wel een team dat je organisatie kent. Voor MKB-bedrijven die willen weten waar ze precies staan, biedt een cloudmigratie op maat een concreet vertrekpunt. Vraag een migratiescan aan en krijg binnen afzienbare tijd helder in beeld welke systemen klaar zijn voor de cloud en welke nog even blijven staan.

Waar vind je meer technische diepgang?

Voor gedetailleerde stappen rond mailboxmigratie raadpleeg je de officiële Microsoft-documentatie, met exacte configuratie-opties per scenario. Voor het 7R-raamwerk en een uitgebreide aanpak van discovery tot uitvoering biedt Cloud.nl een compleet overzicht, terwijl Bosman ICT Services concrete doorlooptijden en kostenindicaties geeft voor MKB-trajecten.

Bronnen

Aanbevelingen