Ten cloud migration mistakes Mid-Market companies still make

Cloud migration has been routine for a decade, which is precisely why the same mistakes keep recurring: the pattern is familiar enough that nobody stops to check whether it fits.

Ten that we see most often in mid-market migrations across Switzerland and the DACH region, and what each one costs.

1 · No baseline

The most consequential and the cheapest to avoid. If you do not record current cost, current release cadence and current recovery time before you move, you cannot demonstrate improvement afterwards — and you will be asked.

Instead: capture three numbers before anything moves. They take a day to gather and they are the only evidence you will have.

2 · Lift and shift, then stop

Moving a workload unchanged is a legitimate first step. Treating it as the last step is where the cost problem starts: you have kept every on-premises sizing assumption and started paying for it monthly.

Instead: plan lift-and-shift as phase one of two, with the optimisation phase scheduled and owned. If it is not in the plan it will not happen.

3 · Sizing inherited from the data centre

On-premises capacity is bought for peak plus growth plus margin, because adding more takes months. Cloud capacity does not work that way, but the sizing habit persists.

Instead: size from measured utilisation, not from the old spec sheet. Most workloads need far less than their on-premises footprint suggests.

4 · Non-production environments running 24/7

Development, test and staging kept running around the clock for a team working Swiss business hours. Roughly 70% of those hours are idle and billed.

Instead: schedule them off outside working hours. It is a small piece of automation with an immediate, permanent return.

5 · Egress discovered after the fact

Data transfer is rarely modelled before a migration and occasionally dominates the bill after one — especially with hybrid architectures where data crosses between on-premises and cloud repeatedly.

Instead: trace the data flows before choosing an architecture. Where data lives relative to what processes it is a cost decision, not only a design one.

6 · Region mistaken for residency

Selecting a Swiss or EU region determines where data rests. It does not determine who can access it, from where, or under which jurisdiction — and under revDSG and GDPR, access is the question that matters.

Instead: ask the vendor where support staff can access your systems from, which subprocessors are involved, and what notice you get when that changes. Write the answers into the contract.

7 · Nobody owns the bill

Cloud cost grows quietly when it is nobody’s explicit job. There is no failure, no alert — just a number that is larger each quarter.

Instead: name one person whose responsibilities include the monthly bill, with the authority to act on it. This single change outperforms most technical optimisation.

8 · Security posture assumed rather than configured

Cloud providers secure the platform. What runs on it is yours: identity, network boundaries, key management, logging. Defaults are rarely what a regulated Swiss company needs.

Instead: treat the security baseline as a deliverable of the migration with its own acceptance criteria, not as something that arrives with the platform.

9 · No exit path

Deep use of managed services makes systems cheaper to run and harder to move. That is often the right trade — but only if it is a decision rather than a discovery.

Instead: know, per workload, what leaving would cost. You may never exercise it. Knowing changes how you negotiate.

10 · Migrating everything

Not every workload should move. Something stable, cheap to run and near end of life may be best left alone until it is retired.

Instead: rank workloads by return. Migrate the ones that pay, leave the ones that do not, and be explicit about which is which.

The pattern underneath

Nine of these ten are planning failures, not technical ones. The technical part of a cloud migration is well understood and reliably executed. What goes wrong is the decisions taken before the technical work starts — and those are recoverable only at much higher cost afterwards.

A migration that begins with a baseline, a ranked workload list and a named cost owner avoids most of this list by construction.

---

If a migration is planned or already underway and the cost picture is not what was promised, that is usually sizing and ownership rather than architecture. Our cloud and DevOps work starts with the baseline. A conversation is non-binding.