Multi-Cloud Strategy 2026: Exit Lock-in, Enter Flexibility

Vendor lock-in was the price companies paid for cloud convenience – for years. In 2026, that balance of power shifts: The EU Data Act introduces regulatory levers, Kubernetes delivers technical abstraction – and an increasing number of German enterprises are deliberately building infrastructure across multiple providers.

TL;DR

• The EU Data Act, in force since January 2024, obliges cloud providers – starting September 2025 – to ensure data portability and interoperable interfaces – a milestone for cloud sovereignty and a paradigm shift for vendor lock-in.
• Kubernetes has become the de facto standard for cloud abstraction: According to the CNCF, 84 percent of companies worldwide run containers in production.
• German enterprises such as Zalando, Deutsche Bahn, and Otto Group are adopting multi-cloud architectures to reduce dependency on individual hyperscalers.
• Multi-cloud can open up negotiation leverage on pricing – but it also increases operational complexity. Overall cost effects depend heavily on governance maturity and FinOps expertise.
• The biggest hurdle isn’t technology – it’s organization: Multi-cloud demands unified governance, cross-platform skill management, and a centralized FinOps team.

The math is simple: Running your entire infrastructure with a single hyperscaler delivers integration and convenience – but at the cost of bargaining power, portability, and, in extreme cases, access to your own data. According to the Flexera State of the Cloud 2025 Report, 70 percent of surveyed IT decision-makers list vendor lock-in among their top three cloud risks. Yet many companies still struggle to exit – because proprietary services, provider-specific APIs, and entrenched dependencies make migration expensive and complex.

The EU Data Act: Regulatory Tailwind

The EU Data Act, effective since January 2024, will fully apply to cloud services starting September 2025. Its core requirements:

Cloud providers must guarantee functional equivalence – meaning customers must be able to migrate workloads to another provider without fundamental re-engineering. Switching charges – the fees incurred when changing providers – are being phased out: As of September 2025, only direct costs associated with the switching process may be charged; by January 2027, all switching charges will be abolished entirely. Providers must also offer open interfaces enabling export of both data and configurations.

For German companies, this represents a strategic opportunity. Those who previously shied away from the effort of a multi-cloud migration now gain regulatory levers to increase pressure on hyperscalers during negotiations. At the same time, the ban on switching charges lowers the economic barrier to partial migration.

However, the Data Act is no silver bullet. The definition of “functional equivalence” is intentionally vague – and it will take years before implementing regulations clarify every detail. Companies acting now gain a competitive edge – but they shouldn’t wait for regulation alone. They must simultaneously build the necessary technical foundations.

Kubernetes as the Abstraction Layer

The technical answer to lock-in is abstraction – and Kubernetes is the tool delivering that abstraction in practice. This container orchestration platform enables deployment and operation of workloads independently of the underlying infrastructure provider.

According to the CNCF Annual Survey 2024, 84 percent of surveyed companies run containers in production. In Germany, adoption stands at 67 percent among companies with more than 500 employees (Bitkom), up 15 percentage points year-on-year.

Kubernetes alone, however, does not fully solve the lock-in problem. Managed Kubernetes services – such as EKS (AWS), AKS (Azure), or GKE (Google) – often integrate provider-specific features – load balancers, storage classes, identity management – that partially erode portability benefits.

The key therefore lies in deliberate architectural decisions: Which Kubernetes features do I use cross-platform? Which proprietary services am I willing to accept – and where do I draw the line? Companies like Zalando have made these decisions systematically, running their e-commerce platform on a Kubernetes architecture portable between AWS and their own data center.

In Practice: German Enterprises Embrace Multi-Cloud

Zalando: The Berlin-based e-commerce group adopted an infrastructure-agnostic Kubernetes platform early on. Its infrastructure runs primarily on AWS – but is abstracted so that individual services could theoretically operate on other platforms. The strategic value? Bargaining power over AWS during pricing negotiations.

Deutsche Bahn: DB Systel, the IT subsidiary of Deutsche Bahn, operates a multi-cloud platform built on AWS and Azure. Passenger-facing apps run on AWS, while internal SAP workloads have migrated to Azure. A central platform team ensures security policies and compliance requirements are uniformly enforced across both clouds.

Otto Group: The Hamburg-based retail conglomerate uses Google Cloud as its primary platform, supplemented by on-premises infrastructure for legacy systems. Here, the multi-cloud strategy is less technically driven than organizationally motivated: Different group companies may select their preferred cloud platform – as long as they comply with central governance standards.

The Organizational Foundation

Multi-cloud is first and foremost an organizational decision. Technology alone is insufficient – companies need three things:

Unified Governance: Who decides which workload runs on which platform? Which services may be proprietary – and which must remain portable? Without a central governance body – be it a Cloud Center of Excellence or an Architecture Board – multi-cloud chaos replaces multi-cloud strategy.

Cross-Platform FinOps: Multi-cloud without centralized cost monitoring is a recipe for budget explosions. Each provider has its own pricing models, discount structures (Reserved Instances, Committed Use Discounts, Savings Plans), and billing logic. A FinOps team, with visibility across all platforms, isn’t optional – it’s mandatory.

Skills Management: AWS, Azure, and Google Cloud are three distinct ecosystems – each with its own certifications, best practices, and mental models. The skills shortage intensifies this challenge. Companies must decide whether to build T-shaped teams – broadly skilled with deep expertise in one platform – or deploy specialized teams per cloud and centrally orchestrate integration.

Companies successfully operating multi-cloud share one trait: They treat cloud strategy not as an IT project – but as an enterprise-wide decision. The CIO level defines guardrails; engineering teams execute them.

Frequently Asked Questions

Header Image Source: Pexels / Panumas Nikhomkhai