Step 1: Defining a workload placement strategy
The heart of a cloud strategy isn’t choosing a provider, but the placement strategy: deciding where to run each workload according to its characteristics. A workload is described by several criteria—the sensitivity of data, performance and latency requirements, cost, regulatory constraints, and business criticality.
This qualification leads to a zoned logic. The most sensitive data (health information, regulated data, industrial secrets) are directed toward a sovereign or private environment; workloads requiring elasticity and innovation go to the public cloud; processes demanding minimal latency or local operation go to the edge. The right placement is not “all public” nor “all sovereign,” but a reasoned distribution.
A formalized and shared placement grid helps avoid ad hoc decisions that recreate fragmentation. It serves as a reference for every new application: before deploying, one first determines where and why, rather than choosing by habit or convenience.
This grid benefits from integrating edge computing as a standalone option. For workloads requiring ultra-low latency (industry 4.0, connected vehicles, retail) or local processing of sensitive data, handling data as close as possible to its source—without sending it to a central data center—becomes relevant. According to IDC (2025), an increasing share of enterprise data is generated and processed outside traditional data centers, making edge a natural complement to centralized cloud in any placement strategy.
Step 2: Managing reversibility
Reversibility—the ability to switch providers or to repatriate workloads—is a strategic concern often neglected at the initial choice. Lock-in comes at a price: price dependency, erosion of negotiating margins, vulnerability in the event of vendor failure or geopolitical decisions by the provider.
Preserving reversibility depends on concrete architectural choices: favor open standards and portable technologies (containers, open data formats), avoid as much as possible non-substitutable proprietary services, document dependencies and contractually plan exit conditions (data retrieval, timelines, formats). Reversibility isn’t improvised when leaving: it is built from the design stage.
This imperative creates a tension to be managed. The hyperscaler’s owned managed services (databases, AI, analytics) are precisely those that deliver the most value and accelerate development—but they are also those that trap you the most. The trade-off isn’t binary: it means using these services where the gain justifies the dependency, while keeping critical components on portable foundations. Complete reversibility is rarely realistic; a controlled reversibility, which knows where its points of dependency lie, is.
Step 3: Securing and orchestrating
Security in a hybrid and multi-cloud environment is more complex than in a single cloud, because the attack surface spans multiple perimeters with different logics. A few principles structure the approach.
End-to-end security
The goal is to unify as much as possible the identity and access management (IAM) across all environments, to encrypt data at rest and in transit, and to maintain control of the encryption keys—ideally under European control for sensitive data (HYOK/HSM approach). A Zero Trust approach, which makes no implicit trust, is essential in this distributed context.
Orchestrating with Kubernetes
Container orchestration, with Kubernetes having become the de facto standard, is the technical backbone of multi-cloud. It enables deploying and managing applications in a consistent way across different clouds, abstracting away each provider’s specifics. It’s one of the major levers for portability and therefore for reversibility.
Step 4: Governing and controlling costs
Without governance, multi-cloud becomes an intractable maze: opaque costs, heterogeneous security, drift in usage. Multicloud governance aims to reclaim command of a landscape that is inherently scattered.
It revolves around several levers: unified visibility into resources and spending across all environments, common security and compliance policies applied everywhere, and a standardization of deployment practices (infrastructure as code). The aim is to restore overall coherence despite the diversity of providers.
Dedicated tools help this unification. Multicloud orchestration and abstraction platforms—Red Hat OpenShift, Terraform, or hyperscaler solutions like Anthos—enable managing several clouds from a single layer. But a tool alone does not govern: governance rests first on clear rules and a responsible organization (who decides placements, who approves expenditures, who audits compliance). Technology enforces policy; it does not define it.
The FinOps dimension
Cost management deserves special attention: pay-as-you-go billing, multiplied by the number of providers, makes spending hard to forecast. A FinOps approach—visibility, allocation, continuous optimization—is the indispensable complement to a multicloud strategy. It holds teams responsible for their consumption and tracks waste, common in environments where provisioning a resource costs only a click.
Ultimately, a successful hybrid and multicloud strategy is measured not by the number of providers used, but by the coherence of governance. Placing each workload in the right place, preserving freedom to move, securing it uniformly, and controlling costs: these four disciplines transform a landscape imposed on you into an architecture you can master. It is ongoing work that requires dedicated skills and governance—but it is the price of a cloud that serves the business rather than constraining it.
This content is published by Mentioned
