Cloud Migration is a Strategy Problem: Aligning Governance and Sovereignty

Cloud migrations fail because they’re treated as infrastructure projects. A CTO decides to move workloads to the cloud. Architecture teams design the infrastructure. Network teams plan the connectivity. Procurement auctions cloud vendors. Six months later, the first workloads are live, and then compliance calls with a list of problems: data residency violations, missing audit trails, no encryption key management, no supply chain visibility for regulatory purposes.

By then, the decision is made. The vendor is chosen. The architecture is locked. The migrations are underway. Retrofitting governance into a live migration can push the remediation phase to 2-4x the original plan or kill the project entirely.

The problem isn’t the cloud itself. It’s that migration planning skipped the strategy layer: the alignment between business objectives, regulatory requirements, and technical architecture. That alignment must happen before the RFP goes out.

The Data on Migration Failure

Start with one number: 52% of organizations fail to embed governance, risk, and compliance (GRC) strategy before migration begins. Only 7% update their GRC controls proactively. The consequence is predictable. 39% of organizations experience security or compliance incidents directly tied to governance gaps introduced during the migration itself. Those three numbers come from Pathlock’s 2025 Digital Transformation & Access Risk Report, a 620-respondent survey of enterprise IT, compliance, and security leaders.

Older survey work points the same direction. Unisys’s 2019 Cloud Success Barometer (1,000 respondents across 13 countries) found that 37% of organisations had failed to realise notable benefits from cloud adoption, largely because cloud wasn’t integrated into their broader business transformation strategy. A 2019 finding, yes. The pattern keeps reproducing anyway. These aren’t technical failures. They’re governance failures.

The industry treats this as normal. IT surveys shrug. Vendors move on to the next customer. But for a European financial services firm, migration failure is expensive. DORA (the Digital Operational Resilience Act, the EU’s operational resilience mandate for financial institutions) has enforcement timelines now. A failed migration means a delayed compliance program. Delayed compliance means regulatory friction, higher capital requirements, and customer confidence issues.

The pattern is consistent across EU fintech, banking, and payments contexts: migration planned as technical exercise, compliance retrofitted, project costs spiral, timelines slip, sovereignty goals are watered down to “EU-region infrastructure” (which is SEAL-1 at best, while the EU procurement framework and a growing share of public-sector and critical-infrastructure buyers are aligning on SEAL-3 or SEAL-4 as the bar for sensitive workloads). No EU regulation mandates a specific SEAL level today. The tender language is moving, though, which is how these things tend to start.

What Migration Strategy Actually Means

Strategy here means making four decisions together, not sequentially:

1. Business objective. What are you actually moving for? Cost reduction? Scale? Performance? Regulatory compliance? If compliance is secondary, you’ll compromise it when cost pressures hit. Name the primary objective. Make it visible.

2. Regulatory posture. Which regulations apply to your workloads? For European financial services, that’s DORA (Digital Operational Resilience Act), GDPR, NIS2 (Network and Information Security Directive 2), and increasingly the EU Cloud Sovereignty Framework. These regulations impose specific requirements on data residency, operational control, supply chain transparency, and key management. These requirements are not optional and cannot be retrofitted into architecture.

3. Data classification and residency. Not all your data is the same. Sensitive customer data (regulated data, PII, key cryptographic material) has strict residency requirements. Non-sensitive data (logs, non-regulated metadata, third-party analytics) can live anywhere. If you classify data after choosing your cloud vendor, you’re left with expensive options: move some data back on-premises, duplicate data infrastructure for compliance isolation, or change vendors. Classify first. Then choose the vendor that handles each classification tier.

4. Governance context. This is the part most migrations skip. Every resource in your cloud needs metadata: owner, cost center, environment (production/staging/development), classification (sensitive/commodity), compliance standard (GDPR/DORA/none). This metadata is not a tagging exercise. It’s your governance surface. Without it, you can’t attribute costs to teams, can’t enforce compliance policy, can’t spot configuration drift, can’t audit who accessed what. The metadata must be designed into the migration plan from day one.

These four decisions should be locked before RFP. RFP is not a time to explore options on governance. RFP is where you verify that vendors can meet the governance, residency, and SEAL-level requirements you’ve already defined.

The RFP as Gateway Control

Think of the RFP as a governance checkpoint. If you haven’t made the four decisions above, the RFP becomes a wish list, and vendors will sell you the path of least resistance (which is usually the lowest SEAL level and the least governance overhead).

A governance-first RFP looks different. It specifies:

• Minimum SEAL level per workload type. If you’re moving regulated data, specify SEAL-3 minimum (which requires operational control and supply chain visibility). If you’re moving non-sensitive data, SEAL-1 (EU jurisdiction) may be sufficient. Make this explicit per workload.
• Data residency boundaries. Specify which data must stay in which geography. “All customer PII must remain in the EU” is clear. “Observability data can be replicated to non-EU locations for backup” is also clear. A vendor can then confirm whether their architecture supports this.
• Encryption key management. Who holds the keys? Does the vendor manage them (vendor-managed keys, higher convenience, lower control), or do you (customer-managed keys, lower convenience, higher control)? For SEAL-3+ and regulated workloads, customer-managed keys are typically required.
• Supply chain transparency. Ask vendors to document their supply chain for critical components: hypervisor, storage, networking, and observability systems. Which are EU-controlled? Which involve third parties? This isn’t binary—it’s a spectrum. But you need the data to assess SEAL impact.

A well-designed RFP isn’t a commodity request for “cloud compute.” It’s a compliance document. Vendors either meet your requirements or they don’t.

Case Study: OVHcloud and the Sovereign Stack

A concrete example: a European fintech wants to deploy large language models (LLMs) for customer analytics. Regulated data, EU requirements, SEAL-3+ target.

OVHcloud’s Managed Kubernetes Service (MKS), combined with their reference architecture for LLM inference, shows what a SEAL-aware migration can look like. The architecture uses NVIDIA L40S GPUs for inference, deployed on Kubernetes with automatic scaling. For observability, it integrates Prometheus (EU-controlled, can be hosted on OVHcloud infrastructure) and Grafana (same). The workload stays within EU infrastructure. Key management uses customer-controlled secrets in Kubernetes.

Now the sovereignty fine print, because this is exactly where sovereignty-washing usually sneaks in. OVHcloud’s Bare Metal Pod platform holds SecNumCloud 3.2 qualification from ANSSI (the French Cybersecurity Agency), announced 31 March 2025. Early-2026 qualifications extend to specific IaaS building blocks: VM instances, dedicated servers, block and object storage. Managed Kubernetes Service is not yet SecNumCloud-qualified. OVHcloud’s Public Cloud qualification is being rolled out product by product under its SecNumCloud strategy. So if you want SecNumCloud coverage today for the architecture above, you run the workload on Bare Metal Pod or on the qualified IaaS primitives, not on MKS. For a forward-looking SEAL-3 target, the MKS roadmap is plausible. At publication it’s a roadmap, not a certification.

One more qualifier on the mapping. Analysts reading the Cloud Sovereignty Framework alongside SecNumCloud 3.2 generally place SecNumCloud-qualified services in the SEAL-3 to SEAL-4 range, but the European Commission has not published an official mapping between external certifications and SEAL levels. Treat SEAL scoring as an assessment you do per workload, against the 8 Sovereignty Objectives, not as a badge inherited from a certification.

The point: this vendor has designed an architecture that doesn’t require you to compromise SEAL levels to get performance. The migration plan can specify “SEAL-3 minimum, GPU-accelerated inference, EU-only data residency,” and the RFP response confirms the architecture meets all three.

Without this upfront alignment, teams often end up with: “We need to run the LLM on AWS for performance, but move the results back to EU infrastructure for compliance storage.” That architecture is more complex (two pipelines instead of one), more expensive (data transfer costs), and still doesn’t achieve SEAL-3 (the LLM workload is SEAL-0 on AWS, the compliance storage is SEAL-2 or higher). Governance-first planning avoids this.

Governance Context Versus Tagging

A common misconception: governance is a tagging problem. Tag everything with “owner”, “environment”, “cost-center”, and you’re done.

Tags are the mechanism, not the strategy. Without strategy, tagging collapses. A team creates tags, but inconsistently. “Prod” vs “production” vs “p”. “FinanceTeam” vs “Finance_Team” vs “finance-ops”. Six months in, you try to run a cost report and can’t: the tag values are too fragmented to group sensibly. Cost allocation fails. Compliance audit fails. Tagging was useless because no governance context made it stick.

Governance context means governance rules enforced at the infrastructure level. Every resource must have specific tags before it can be created (policy-as-code). The tags must follow a standard format (enums, not free text). The tags must be auditable (who changed what, when). The tags feed into downstream controls: cost allocation, compliance scanning, access control.

This matters for migration because if you migrate 50 applications and then try to retrofit governance context, you’re doing 50 audits and 50 remediation efforts. If you embed governance context into the migration plan from day one, you configure it once, and every workload that lands in the cloud is automatically compliant.

Secondary analyses (IT Convergence, OvalEdge) attribute to Gartner research that organisations with integrated compliance automation and policy-as-code achieve roughly 40% faster compliance audits and 30% fewer violations than those managing governance manually. The primary Gartner publication behind the figure isn’t openly accessible, so treat the ratio as directionally supportive rather than bulletproof. Even halved, the saving scales to thousands of hours and millions in avoided remediation cost over the lifetime of the cloud footprint.

SEAL Levels and the Migration Decision Tree

The EU Cloud Sovereignty Framework (published October 2025 by the European Commission) defines SEAL (Sovereignty Effectiveness Assurance Level) as a 0-4 rating scale:

• SEAL-0: No sovereignty. Non-EU control, or no meaningful governance.
• SEAL-1: Jurisdictional sovereignty. Data is subject to EU law, and the vendor is subject to EU jurisdiction.
• SEAL-2: Data sovereignty. Data is physically resident in the EU, and subject to EU law.
• SEAL-3: Digital resilience. Operational control (who operates the infrastructure) is EU-based, and supply chain dependencies are transparent.
• SEAL-4: Full digital sovereignty. All elements (jurisdiction, residency, operations, supply chain) are EU-controlled.

For a European financial services firm, SEAL levels map to workload types:

The decision tree is straightforward:

1. Classify your workloads (regulated vs non-regulated, sensitive vs commodity).
2. Assign SEAL targets per class.
3. Design the migration to place each workload on infrastructure that meets (or exceeds) the SEAL target.
4. Build compliance context into the migration plan so SEAL levels are auditable post-migration.

Most teams skip steps 1-2, run the migration without clear SEAL targets, and then discover (during compliance audit) that sensitive workloads are on SEAL-1 or SEAL-2 infrastructure when SEAL-3 was required. Retrofitting is expensive. Preventing it is straightforward.

The Cost of Retrofitting

Here’s a rough cost model for a 100-application migration (typical for a mid-size bank):

Scenario A: Governance-first planning (3-month planning + 12-month migration)

• Planning phase: Data classification, RFP design, vendor evaluation. Cost: 3-5 FTE months of architecture + compliance team time.
• Migration: Workloads land pre-configured with governance context. Compliance validation is automated. Cost: standard migration cost (network, application re-platforming, testing).
• Total: Planning + standard migration.

Scenario B: Technical-first, governance retrofit (2-month planning + 12-month migration + 6-month remediation)

• Planning: Infrastructure evaluation, vendor selection. Cost: lower upfront because governance is deferred.
• Migration: Workloads land without governance context. First 100 days are fire-fighting. Cost: standard migration + unplanned remediation.
• Remediation: Classify data retroactively, audit workload placement against regulatory requirements, move sensitive workloads to higher-SEAL infrastructure, implement governance context. Cost: 5-8 FTE months of rework.
• Total: Planning + standard migration + 5-8 months of unplanned rework.

The difference is often 6-12 months of delay and 2-4x cost on the remediation phase. For a financial services firm with regulatory timelines (DORA compliance deadlines, for instance), delay can be a business blocker.

Next Steps

If you’re planning a cloud migration, lock this decision checklist before RFP:

1. Name your primary objective. Cost? Compliance? Scale? Make it visible to leadership.
2. Map regulations to workloads. Which workloads are subject to DORA, GDPR, NIS2? Which are not? Be explicit.
3. Classify your data. Sensitive (customer PII, regulated data, cryptographic material) vs commodity (logs, non-regulated metadata). Map each class to residency and SEAL requirements.
4. Design governance context. Metadata model: owner, cost-center, environment, classification, compliance-standard. Decide which tags are required (policy-enforced), which are optional (informational).
5. Write the RFP from strategy. Specify minimum SEAL per workload, residency boundaries, encryption key management, supply chain transparency. Don’t leave these to vendor options.
6. Assign a governance owner. Not IT infrastructure, not compliance, not business. Governance owner for the migration, accountable for integrating these four decisions.

This adds 4-8 weeks to your planning cycle. It saves 4-8 months on the remediation cycle. The trade-off is clear.