Deciding to move to the cloud is the easy part. NCSC, the Dutch national cyber security centre, is candid that even it is still early in its own cloud journey, and it frames cloud adoption as something with major consequences for how an organisation organises its security architecture, its processes and the technical knowledge it needs in-house — not a weekend project. If you've already worked through the cloud-versus-on-premise decision, this guide picks up from there: what to settle before you migrate anything, which kind of cloud service you're actually buying, what to nail down with a vendor before signing, and the exit strategy question most SMEs skip until it's too late.
Before You Migrate Anything
A migration that starts with copying files to whatever cloud tool someone found first tends to end with nobody quite sure what's running where. Three decisions belong before any data moves:
Inventory what you actually have. Systems, data, and — critically — the dependencies between them. A CRM that feeds an invoicing tool that feeds an accounting export is one migration, not three independent ones, and missing that ordering is the single most common cause of a migration that drags on.
Set a priority order. Not everything needs to move on day one, and not everything should. Low-risk, well-understood systems make a better first move than the system your entire invoicing process depends on.
Decide what "done" looks like for each system, including who tests it and what a successful cutover has to demonstrate, before you start rather than after something breaks.
What Kind of Cloud Service Are You Actually Buying?
"The cloud" isn't one thing, and the difference matters for how much your business ends up managing itself. NCSC lays out the three common models plainly: with IaaS (infrastructure as a service), the provider manages the infrastructure and network hardware, but you're responsible for setting up and maintaining everything on top of it — comparable to renting server space. With PaaS (platform as a service), the provider also manages and monitors the underlying infrastructure and operating system, so you only deal with the software you install on the platform. With SaaS (software as a service), you consume one or more finished web applications that the provider develops, maintains and manages entirely — the packages that need the least technical knowledge to run.
In practice, an SME without a dedicated IT function is usually better served staying as far toward SaaS as the actual requirement allows, and reaching for IaaS only when a specific application genuinely needs that level of control. Every step toward IaaS is a step toward needing in-house or outsourced technical capacity you may not currently have.
What to Settle With a Vendor Before You Sign
NCSC's guidance on this is specific enough to use as a checklist rather than a vague warning:
- Baseline account security. At minimum, an application should be protected by a username, a password and two-factor authentication before any real data goes near it.
- Where the data actually sits. Ask which country hosts the servers your data will live on, and who has access to it — not as a formality, but because NCSC explicitly warns that some foreign authorities can gain relatively easy access to cloud services even when the data itself is stored somewhere like Europe under different rules. Storage location alone doesn't settle the question; ask the vendor directly what access arrangements exist.
- Whether you should encrypt before you upload. For genuinely sensitive data, NCSC raises the option of encrypting files yourself before they reach the provider, so a compromise at the vendor's end doesn't expose your data at all. Some providers offer "zero-knowledge" encryption, where only you hold the keys — with the real trade-off that losing that key means the files are unreadable forever, and the provider itself cannot recover them.
- Access management and audit logs. Get a clear picture of who can access what, and whether the vendor's audit logs record who logged in, when, and what actions they took once inside.
- Network-level restrictions. Some providers let you restrict access to specific IP addresses — your office network, for instance — or require a VPN connection before the service can be reached at all, which is worth asking about even if you don't plan to use it immediately.
The Exit Strategy Question Most SMEs Skip
The more of your operations run through one cloud provider, the more dependent you become on them — and NCSC's advice here is to make agreements about how you'd leave and where your data would go before you're locked in, not after. A provider going out of business or contract renegotiations that go nowhere are the realistic scenarios, and NCSC is fair that this happens rarely with large, established providers — but rarely is not never, and an exit plan is far cheaper to write before migration than to improvise during one. Concretely, that means asking upfront: in what format can you get your data back, how long would an export take, and does anything about the setup make you harder to leave than you'd like.
Running the Migration Itself
This is where judgement matters more than any checklist. A staged approach consistently outperforms a single cutover: migrate one low-risk system or team first, let it run in parallel with the old setup for a defined period, and only decommission the old version once the new one has actually been tested under real use — not just verified to technically work. Whatever priority order came out of your inventory, follow it; the system everything else depends on should move once you've already learned from an earlier, smaller migration, not as the first attempt.
Tell staff what's changing and when, especially anything that touches how they log in or where they find something day to day — a technically perfect migration that nobody warned about still generates a flood of help-desk tickets in week one.
After the Migration
Once systems are live in the cloud, a couple of things NCSC flags are easy to forget because nothing forces you to think about them: set cost alerts on your cloud usage, since unnoticed capacity is exactly what lets an attacker run cryptojacking on your account without anyone spotting the bill until much later. And revisit your backup and incident response plans specifically for the new environment — a plan written for on-premise servers doesn't automatically cover what happens when the outage or the incident is at your cloud provider instead of in your own building.
FAQ
What's the real difference between IaaS, PaaS and SaaS? How much you manage yourself. IaaS gives you the infrastructure and leaves setup and maintenance to you; PaaS also manages the underlying platform and operating system, leaving you only the software you run on it; SaaS is a finished application the provider develops, maintains and runs entirely, needing the least technical knowledge from you.
Do we need to encrypt our data ourselves before it goes to the cloud? Not always, but for genuinely sensitive data NCSC recommends considering it, especially through a provider offering zero-knowledge encryption where only you hold the key. The trade-off is real: if you lose that key, the data is unreadable forever, and the provider cannot recover it for you either.
Is data stored in a European data centre automatically safe from foreign access? Not automatically. NCSC is explicit that some foreign authorities can gain relatively easy access to cloud services even when data is stored in a jurisdiction like Europe with different rules. Ask your vendor directly what access arrangements actually exist rather than assuming the storage location settles it.
Why do we need an exit strategy if we're happy with our current cloud provider? Because the alternative is negotiating your way out under pressure — during a bankruptcy, a failed contract renewal, or a security incident — rather than on your own terms. NCSC's point is that this happens rarely with large providers, but an exit plan costs little to write in advance and a great deal to improvise later.
How long does a cloud migration take for an SME? It depends entirely on how much needs to move, how many systems depend on each other, and how conservative your staged rollout is — there's no fixed timeline that applies generically. A proper inventory and priority order up front is what makes that estimate realistic rather than guessed.
Getting the Sequence Right the First Time
A cloud migration goes wrong less often from the technology than from skipping one of the decisions above until it's already too late to undo cheaply. Our Cloud Infrastructure service runs the inventory, the vendor security checklist and the staged rollout as one connected process, rather than leaving your team to discover the dependencies mid-migration. And because access management and audit logging are exactly where a rushed migration tends to leave gaps, our Cybersecurity & Identity team can make sure who-can-access-what is deliberately designed into the new environment, not inherited by accident from whatever was easiest to configure first.