A Cost-Effective cloud migration strategy in five steps

A migration plan mid-size DACH companies can actually execute: assess, sequence, prove the landing zone, migrate in waves, then optimise — with costs owned.

25 March 2026 9 min read Updated 24 September 2026

A Cost-Effective cloud migration strategy in five steps

Most migration advice is written for enterprises with a dedicated cloud team and a multi-year budget. Mid-size companies in Switzerland, Germany and Austria have neither. They have an existing estate, a small team that already has a day job, and a board that wants a number.

This is the version that fits those constraints: five steps, in order, each with something you can show at the end of it.

Know the route before you plan the journey

One principle underneath all five steps. A migration is not a technology project with a business justification bolted on — it is a business change that happens to be delivered with technology.

That distinction decides what “done” means. A technology project is done when the workloads run in the new place. A business change is done when the cost, speed or risk position has measurably moved. Only the second one survives the question “what did we get for it?”

Five challenges that derail mid-size migrations

Worth naming before the steps, because each step exists to defuse one:

Underestimating how connected the systems are. The dependency nobody documented is discovered during cutover.
Cost overruns that arrive after go-live, not during the project, when the team has already disbanded.
Compliance complexity that generic migration guides skip entirely — and that a Swiss or German company cannot skip.
A skills gap discovered mid-project, usually around networking, identity or infrastructure-as-code.
No owner after go-live, so the environment freezes in its migration-day shape.

Step 1 — Assess, and produce numbers

Not an inventory of servers. An inventory of workloads, each with the facts that determine how it moves:

Who uses it, how often, and what the load profile looks like across a year
What data it holds and what protection that data requires
What it depends on, and what depends on it
What an hour of downtime costs
What it costs today — hardware depreciation, hosting, licences, and the operations hours it consumes

That last line is the one most often skipped, and without it you can never answer whether the migration paid off. A before-figure cannot be reconstructed afterwards, so it has to exist before anything moves.

Output of this step: a list of workloads with a disposition each — retire, retain, rehost, replatform, refactor, replace.

Retire is the highest-value disposition and the most overlooked. Most estates contain systems nobody has used in years. Finding them is the cheapest win in the whole programme.

Step 2 — Sequence by business impact

The instinct is to start with the easiest workload. It feels productive and it moves nothing.

Sequence instead by a combination of impact and risk: something that matters to the business, but whose failure is survivable. That gives a first wave with a real result and a safe rehearsal of the process.

Two rules that keep the sequence honest:

Nothing regulated goes first. You want the process proven before you migrate the workload that carries the compliance burden.
Tightly-coupled systems move together. Splitting a dependency across waves means running a temporary integration you will throw away — that cost belongs in the plan or the split does not happen.

Step 3 — Build and prove the landing zone

The landing zone is the environment everything lands in: network layout, identity and access model, logging, monitoring, backup, cost tagging, and the guardrails that stop the estate drifting.

This is the step under time pressure most often shortened, and it is the one that determines what the next three years look like. A weak landing zone is where the recurring problems come from — over-broad permissions, storage that ended up public, logging disabled to save money, costs nobody can attribute.

Two things to settle here, both regulatory:

Data residency AND data access. Storing data in a Swiss or EU region does not answer who can reach it from where, including your provider’s support staff. Under revDSG/nDSG and GDPR the access question is the one that gets audited.
A documented exit path. For FINMA-supervised businesses this is a requirement, not a precaution.

Also settle cost attribution now. Tag by team or product from day one. A bill that arrives addressed to “IT” gives nobody an incentive to reduce it, and retro-fitting tags across a live estate is miserable work.

Step 4 — Migrate in waves, with a tested way back

Each wave runs the same loop: migrate, validate against the baseline from step 1, run in parallel where you can, then cut over.

The part that gets skipped is the way back. A rollback plan that has never been executed is an assumption, not a plan. Test it on the first wave, when the stakes are lowest and you still have the appetite.

What to validate on each wave — beyond “it starts”:

Behaviour under realistic load, not smoke-test load
Restore from backup, actually performed
Loss of an availability zone
The rollback itself

Step 5 — Optimise, with a named owner

The savings do not come from the migration. They come from what you change afterwards: right-sizing to real usage, shutting non-production environments outside working hours, clearing orphaned volumes and snapshots, committing to reserved capacity for stable workloads.

None of it happens if the programme ends at go-live and the team disbands. So this step needs three things in the plan from the beginning: its own budget, its own timeline, and one named person — not a committee — who reports on cost variance monthly.

What this looks like as a number

A mid-size migration planned this way typically shows its return in three places rather than one: infrastructure cost after the optimisation step, engineering time recovered from manual environment work, and time-to-change for the business.

The third is usually the largest and the least measured. If provisioning a test environment drops from three days to two hours, that changes what the business is willing to attempt — and that effect does not appear on an infrastructure invoice.