Last quarter, a platform director we work with got blindsided in a board meeting. The CEO had read about the CLOUD Act over the weekend. "Can Microsoft access our customer data?" Silence. "What's our exposure?" More silence. The meeting moved on, but the follow-up email was clear: I need a plan on my desk before the next board meeting.
If you are in a similar position — responsible for platform infrastructure at a European company, fielding questions from leadership about sovereignty, cost, and risk — this article is for you. Not a political argument. A practical framework for building a business case your board will approve.
Why now
Three forces are converging in 2026 that make this conversation unavoidable.
The legal reality is settled. In June 2025, Microsoft France's CEO testified before the French Senate commission on digital sovereignty. Asked whether he could guarantee that European customer data would never be transmitted to US authorities, his answer was unequivocal: "No, I cannot guarantee it." This is not speculation — it is a formal admission under oath. The US CLOUD Act requires US companies to comply with US government data requests regardless of where that data is stored. No contractual clause overrides this.
NIS2 is enforced. The NIS2 Directive required EU member states to transpose into national law by October 2024. Enforcement is now active, and companies in essential sectors — energy, healthcare, transport, digital infrastructure, education — face the first compliance audit deadline of June 2026. The EU Cloud Sovereignty Framework, published in October 2025, adds eight specific requirements for sovereign cloud services, including exposure to foreign legislation.
The economics are visible. European cloud infrastructure services reached EUR 75 billion in 2025, growing 24% year-on-year. US providers control 70% of this market. European providers hold 15% — down from 29% in 2017. Every euro spent deepens the dependency. Meanwhile, SaaS costs keep climbing: Datadog renewals arriving with 20–30% increases, GitHub Enterprise pricing ratcheting up annually.
Any one of these would justify a conversation. All three together mean the question is no longer whether to act, but when and how.
The three arguments that work
Sovereignty alone does not win budget. We have seen this in dozens of board conversations across European enterprises. The political argument opens the door, but the business case closes it.
Frame your case around three pillars:
1. Risk reduction
This is what gets the board's attention. Frame it as exposure, not ideology.
- CLOUD Act exposure: Any data held by a US company — AWS, Azure, Google, GitHub, Datadog, MongoDB Atlas — is legally accessible to US authorities, regardless of where it is stored. No contractual clause or EU regulation overrides this.
- Regulatory risk: NIS2 non-compliance penalties can reach EUR 10 million or 2% of global annual turnover — whichever is higher. The EU Cloud Sovereignty Framework specifically assesses exposure to foreign legislation.
- Operational risk: US policy increasingly uses technology access as leverage. In a sanctions scenario, service disruption is not theoretical — it is contractual.
Your board understands risk. Quantify the exposure: what data sits on US-controlled infrastructure, what regulations apply, what the penalties are.
2. Cost reduction
This is what gets the CFO on your side. Sovereignty and cost reduction are not opposing forces — they point the same direction.
The numbers we see consistently across enterprise platform organisations:
| Migration | Typical annual savings | |-----------|----------------------| | Datadog → Grafana Stack (self-hosted) | EUR 300K–1.8M | | GitHub Enterprise → GitLab (self-hosted) | EUR 200K–600K | | Auth0 / Okta → Keycloak | EUR 30K–150K | | Terraform Cloud → OpenTofu + Crossplane | License cost eliminated |
A 250-person engineering organisation replacing Datadog and GitHub alone saves EUR 500K–2.4M per year. The migration investment typically pays back within six to twelve months.
These are not projections. They are ranges from actual engagements.
3. Strategic flexibility
This is what gets the CTO on board. Independence means options.
- No single vendor controls your roadmap. Open source tools evolve based on community needs, not a vendor's quarterly targets.
- Portability across providers. Kubernetes on Scaleway, Hetzner, OVHcloud, STACKIT, or bare metal — your applications move without rewriting.
- Negotiating leverage. When you can leave, vendor conversations change. Prices come down. Feature requests get heard.
The strongest business cases we have seen combine all three: reduce risk, reduce cost, increase options. The board gets the risk story. The CFO gets the numbers. The CTO gets the architecture.
Building the numbers
Your board does not want a 60-page document. They want clarity: what does this cost, what does it save, and what is the risk of doing nothing?
The TCO framework
Model a 3-year total cost of ownership comparison for your top 3–5 SaaS dependencies:
Current state (per tool):
- Annual license cost (include overages and add-ons)
- Year-over-year price increase history (most SaaS vendors increase 15–30% annually)
- Hidden costs: integration maintenance, export limitations, compliance workarounds
Alternative state (open source, self-hosted):
- Infrastructure cost (compute, storage, networking)
- Operational cost (FTE allocation for running the service — typically 0.2–0.5 FTE per tool)
- Migration cost (one-time: engineering effort, parallel running, knowledge transfer)
- Opportunity cost of the migration period
What to include:
- Actual contract amounts, not list prices
- 3-year projection with historical price increase trends
- Migration timeline and resource allocation
- Risk-adjusted scenarios (optimistic, realistic, conservative)
What to exclude:
- Vague "productivity" benefits that cannot be measured
- Speculative future costs that assume worst-case vendor behaviour
- Anything you cannot defend in a board Q&A
The goal is a defensible comparison, not an advocacy document. If staying with a SaaS tool makes more financial sense, say so. Credibility matters more than the conclusion.
The migration is not what you think
The most common objection we hear from boards: "Won't this be massively disruptive and expensive?"
No. Because this is not a rip-and-replace.
European cloud independence is a generational migration — a 5–7 year strategic reorientation that aligns with natural technology refresh cycles. Here is how to sequence it:
Phase 1: Foundation (months 1–12)
- Complete infrastructure audit — map every SaaS dependency, cloud service, and data flow
- Identify pioneer workloads: new projects or upcoming refreshes that can start on European infrastructure
- Establish Kubernetes platform foundation on a European provider
- Success metric: first workload deployed on European infrastructure
Phase 2: Capability (years 1–3)
- All new projects default to European infrastructure
- Build internal platform expertise through embedded engineering and knowledge transfer
- Develop migration playbooks for each tool in your stack
- Success metric: 100% of new workloads on European cloud
Phase 3: Migration (years 3–6)
- Systematic migration of existing workloads during scheduled refresh cycles
- Transition DevOps tooling (observability, CI/CD, secrets management)
- Success metric: 80% of workloads on European infrastructure
Phase 4: Maturity (year 5+)
- Full operational independence
- Internal capability mature
- Success metric: strategic independence operational
The key insight for your board: the cost savings from early migrations fund the later phases. A Datadog-to-Grafana migration in Phase 1 that saves EUR 800K/year generates EUR 2.4M over three years — more than enough to fund the next two migrations.
What your board actually needs to see
One page. Not a slide deck. One page with four sections:
1. The risk (2–3 sentences) State the exposure: what data sits on US-controlled infrastructure, what the CLOUD Act means, what NIS2 requires. Factual, not alarmist.
2. The opportunity (3–4 bullet points) Quantify cost savings for the top 2–3 migrations. State the 3-year projection. Include the payback period.
3. The approach (3–4 bullet points) Phased migration over 5–7 years. New workloads first, legacy during refresh cycles. Early savings fund later phases. No disruption to current operations.
4. The recommendation (1–2 sentences) Start with an audit. Map the full dependency landscape, quantify the exposure, and build a detailed migration plan. Timeline: 2–3 weeks. Investment: defined scope, defined outcome.
That is the document. Everything else — the detailed TCO models, the provider comparisons, the technical architecture — lives in appendices that your platform team can present if the board asks for depth.
Start here
If you recognise this situation — board asking questions, CFO watching cloud spend, no clear plan yet — the first step is understanding what you are actually dealing with.
A Freedom to Operate Audit maps every SaaS dependency, quantifies the lock-in risk across seven vectors (pricing, data, API, roadmap, sovereignty, licensing, contracts), and produces a 3-year cost comparison with a prioritised migration plan. Two to three weeks. The output is board-ready.
For the broader strategic context — the CLOUD Act mechanism, the European provider ecosystem, the migration framework — read Towards European Cloud Independence.
The business case is there. The numbers work. The question is whether you build it now, while you have time to plan — or later, when someone else is making the decision for you.