Swiss cloud adoption: five lessons on getting to real ROI

Cloud adoption in Switzerland is no longer the question. Most mid-market companies have migrated something, many have migrated most things. The question that has replaced it is harder to answer: what did it return?

Five lessons, drawn from cloud work with Swiss and DACH companies.

Lesson 1 · Adoption and return are different projects

The gap

A migration that finishes on time and on budget can still return nothing. Lifting a workload from a data centre to a hyperscaler changes where it runs. It does not, by itself, change what it costs, how fast it ships, or how reliably it recovers.

The return comes from the second project — the one that is often never scoped, because the first one was declared a success.

Closing it

Name the return before the migration, in terms someone outside IT recognises: a release cadence, a recovery time, a cost per transaction. Then measure it before and after. A migration with no baseline cannot demonstrate a return even when it produced one.

Lesson 2 · Where Swiss mid-market companies overspend

Four patterns account for most of it:

Over-provisioning inherited from on-premises. A server sized for peak load, three years of growth and a safety margin becomes an instance sized the same way — except now you pay for that headroom monthly rather than once.

Environments that never sleep. Development, test and staging running 24/7 for a team that works Swiss business hours. That is roughly 70% of their hours idle and billed.

Storage nobody owns. Snapshots, old backups, logs with no retention policy. Individually trivial, collectively material, and invisible because nothing fails.

Egress. Rarely modelled before migration, occasionally large afterwards — particularly with multi-region or hybrid architectures moving data between zones.

What it looks like

A workload sized for its actual profile rather than its inherited one commonly runs at a fraction of the lifted-and-shifted cost. The saving is not clever architecture. It is measuring first.

Lesson 3 · Regulatory traps specific to Switzerland

The maze

Swiss companies navigate revDSG, and GDPR wherever EU personal data is involved. Finance-adjacent organisations add FINMA expectations around outsourcing and data location. Healthcare adds its own.

The traps are consistent:

• Region is not residency. Selecting a Swiss or EU region places the data. It does not, on its own, determine who can access it, from where, under which jurisdiction.
• Support paths cross borders. A vendor’s support organisation may be able to access systems from outside the region your data sits in. That is an access question your region setting does not answer.
• Subprocessors change. A compliant vendor today may add a subprocessor tomorrow. Whether you are told depends on the contract you signed.

The balance

The answer is rarely “keep everything in Switzerland”. It is knowing, per workload, where the data rests, who can reach it, and under what terms — and writing that into the contract rather than assuming it from the region dropdown.

Lesson 4 · A roadmap ROI can follow

A roadmap that survives contact with a budget has five elements:

1. A baseline. Current cost, current release cadence, current recovery time. Without it, everything after is assertion.
2. Workloads ranked by return, not by ease. The easiest workload to migrate is rarely the one that pays.
3. Waves, not a big bang. Each wave ships, is measured, and informs the next.
4. Cost ownership from day one. Someone whose job includes the bill, looking at it monthly. Unowned cloud spend grows.
5. An exit path. What it would take to move a workload elsewhere. You may never use it; knowing it changes your negotiating position.

The Swiss advantage

Swiss and EU regions are mature across the major providers, and data residency is genuinely achievable rather than aspirational. That is a real advantage for companies whose customers ask where the data sits — provided the access question in Lesson 3 is answered too.

Lesson 5 · What is actually changing

Three shifts worth planning for rather than reacting to:

Cost discipline has become a first-class concern. FinOps practices that were hyperscaler-sized are now normal at mid-market scale, because the bills got big enough to notice.

Sovereignty requirements are hardening. Customer questionnaires ask where data sits and who can access it, with increasing specificity. Answering well is becoming a sales asset.

AI workloads change the cost profile. GPU-backed inference does not behave like web hosting. Companies adding AI to an existing cloud estate frequently discover their cost model no longer predicts anything.

The short version

Cloud returns come from measurement, right-sizing, and knowing your regulatory position precisely rather than approximately. None of that is a migration activity, which is why so many finished migrations have not returned much yet.

---

If the bill is growing faster than the benefit, that is usually a sizing and ownership problem rather than an architecture one. Our cloud and DevOps work generally starts with the baseline. A conversation is non-binding.