Cloud migration roadmap: A guide for European SMEs

Most cloud migration guides are written for organisations with a dedicated platform team. This one assumes what a European SME actually has: an existing estate, a small team with a day job, and a finance function that wants the numbers before the architecture.

The shift that matters most is financial, not technical

The largest change a migration makes to an SME is not where the servers are. It is moving spend from capital expenditure to operating expenditure, and that changes several things at once:

• Cash flow improves — no large purchase every four or five years
• Forecasting gets harder — a variable bill replaces a known depreciation schedule
• Approval moves — spend that used to be one board decision becomes hundreds of small engineering decisions

The third point is the one that catches SMEs. Capital spend had a natural governance gate. Operating spend does not, unless you build one — which is why cost attribution belongs in the plan from day one rather than as a later clean-up.

Calculating TCO so the comparison is honest

A cloud bill compared to a server purchase is not a comparison. Both sides need the same treatment over the same period — five years is the usual horizon because it spans one hardware refresh.

On-premises, fully loaded: hardware plus the year-four refresh, housing, power and cooling, licences at on-premises pricing, operations labour in hours, spare capacity carried year-round for peaks, and downtime at your actual availability.

Cloud, fully loaded: compute and storage at real usage, data transfer between zones and outbound, managed services at their convenience premium, operations labour that shrinks but changes shape rather than disappearing, and the optimisation work that produces the savings.

That last item is the one most plans omit and the one that determines whether the business case is real. The migration does not create the saving; the tuning afterwards does. Budget it or it does not happen.

Where pay-as-you-go genuinely helps — and where it does not

Pay-as-you-go is presented as universally cheaper. It is cheaper for a specific shape of demand.

It helps when:

• Load is seasonal or spiky — retail peaks, reporting periods, campaign traffic
• You are testing something whose demand you cannot predict
• Environments should exist only part of the time, which is true of every non-production environment

It does not help when:

• Load is flat and predictable — here committed capacity or owned hardware is cheaper per unit
• The workload sits on hardware you have not finished depreciating

That second case deserves more weight than it usually gets. The hardware refresh date is the natural decision point. Migrating a stable workload two years early often means paying for both.

Elasticity, in terms a growing business can use

“Elasticity on demand” means capacity follows load rather than being purchased ahead of it. For a growing SME the practical consequences are:

• You stop sizing for a forecast. Forecasts for a growing business are wrong in both directions, and both are expensive — over-provisioned capacity is paid for, under-provisioned capacity is lost orders.
• Experiments get cheap. The cost of trying something becomes hours of compute rather than a procurement cycle.
• Growth stops being a project. Adding capacity is a configuration change, not a quarter.

The discipline elasticity requires: it scales up automatically and only scales down if you configure it to. A great many surprising bills are elasticity that only ever went one way.

The sequence

1. Assess. Inventory workloads, not servers. Per workload: usage pattern, data sensitivity, dependencies, cost of an hour of downtime, and the current fully-loaded cost. Assign a disposition — retire, retain, rehost, replatform, refactor, replace. Retire is the highest-value and least-used option.

2. Decide the regulatory questions. For European SMEs this precedes architecture. GDPR wherever EU personal data is involved, revDSG/nDSG for Swiss data. Both require knowing where data sits and who can reach it — separate questions, and the second is the one that gets audited. Answer them before choosing a region, not after.

3. Build the landing zone. Network, identity, logging, backup, cost tagging, guardrails. The step most often shortened under time pressure and the one that determines the next three years.

4. Migrate in waves. Start with something that matters but whose failure is survivable. Validate against the baseline from step 1. Test the rollback on the first wave, while the stakes are low.

5. Optimise, with an owner. Right-size, schedule non-production environments off, clear orphaned resources, commit to capacity for what is genuinely steady — in that order. Commit last, after right-sizing.

What to measure

Not “cloud adoption”. Four numbers that tell you whether it worked:

• Fully-loaded cost per workload, against the step-1 baseline
• Time to provision a new environment
• Number of manual steps in a release
• Hours spent on recurring incidents

If those are not moving, the programme migrated rather than modernised.

Related reading

• A cost-effective cloud migration strategy in five steps
• Cloud vs on-premises: what makes sense for SMEs
• Ten cloud migration mistakes mid-market companies still make

If you want the TCO comparison done properly for your own estate, book a call. No obligation.