Cloud exit strategy: prepare a provider switch
Export data, replace dependencies and rehearse the switch. A practical cloud migration plan for SMEs, including acceptance checks and rollback.
Contents
Export data, replace dependencies and rehearse the switch. A practical cloud migration plan for SMEs, including acceptance checks and rollback.
Share this article
The Moment Exit Becomes Unaffordable
An illustrative example: Claudia, managing director of a 35-employee engineering-services firm in Bavaria, receives a call that ruins her day. A strategic key account demands demonstrable EU data residency for all project data — effective next quarter. Until now, 800 GB of customer project data has lived on a US hyperscaler. Claudia asks her technical lead, Markus, to estimate the cost of moving it. Three days later, the result lands on her desk: The egress fees alone exceed the projected savings of an entire year. Add four to six months of development time, because three production workloads are bound to proprietary APIs.
The exit was never planned. The architecture assumed the provider was permanent. The convenience of managed Kubernetes, managed PostgreSQL, and serverless functions masked a creeping dependency that now — in the middle of a customer negotiation — has become a strategic problem.
Eurostat reports for 2025 that 52.74 percent of covered EU enterprises used paid cloud services. The survey covers enterprises with at least ten employees in the included economic sectors. This shows adoption, not whether an individual business can switch. Contracts, data, and technical dependencies require separate examination.
Why Cloud Exit Is Not a Later Problem
The mistake begins with the feeling that you can switch at any time. But exit costs do not crystallize on the day of termination. They accumulate in a thousand small architecture decisions made long before.
The API Sediment Layer
Every line of code tied to a proprietary API forms sediment. A serverless function here, a managed queue there — after two years, the integration stack is so densely baked together that re-platforming forces a rewrite of 40% of the code. That is not a theoretical figure: In practice at this engineering services firm, 12 SaaS integrations sit in this web. David, the developer, knows that a move means months of reverse engineering instead of productive work.
The Data Format Trap
A managed database product name is not a portability test. Aurora, for example, offers PostgreSQL- and MySQL-compatible variants, while extensions, operating features, and integrations may still depend on the provider. Check schema, SQL behavior, export, and recovery on the target. PostgreSQL alone does not guarantee an unchanged move.
The Documentation Gap
Who in your company owns the credentials, deployment procedures, and network configuration for a provider switch? In many SMEs with 10–100 employees, this knowledge is concentrated in one person. When that person leaves, the exit key leaves with them.
The Hidden Costs When the Door No Longer Opens
The true costs of a cloud exit divide into three layers. Each layer is threatening on its own; together they form a pyramid that blows up even planned budgets.
Egress Fees as an Exit Wall
Check whether transfer charges still apply to your switch and what the contract allows. The Data Act removes covered switching charges from 12 January 2027. Your own development work and parallel operations remain separate cost items.
Re-Platforming Costs Without Budget Reserve
A migration needs a workload-specific estimate covering interfaces, data volume, adaptations, tests, parallel operation, and training. Without these assumptions, figures such as €80,000–120,000 or four to six months are not a defensible estimate.
Lost Bargaining Power and Price Dictate
A credible switching path can help in contract discussions. Its effect depends on alternatives, contract terms, and migration cost. It does not establish a general price increase among hyperscalers or mean every customer without a formal criterion has surrendered bargaining power.
The 30-Day Test and Other Early Warning Signals
The best exit key is the one you hold in your hand regularly. Instead of waiting for an emergency, SMEs should test their stack portability systematically.
The EU Data Act Portability Check
Separate contract termination, the contractual switching period and technical execution. An internal trial can show whether a critical workload works at the destination. A self-imposed 30-day target is a planning assumption; it establishes neither a general notice period nor the feasibility of the complete migration.
The NIS2 Exit-Evidence Audit
NIS2 supply-chain requirements apply to entities within the relevant statutory scope. Smaller suppliers may also receive contractual evidence requirements from customers. That does not automatically transfer every NIS2 obligation to them. Establish which evidence your particular switch requires.
The Internal Switching Drill
Markus at this engineering services firm runs an annual 30-day switching drill: A critical workload is reprovisioned on an alternative target. The goal is not a full migration, but reproducibility. If Terraform or GitOps pipelines can rebuild the stack on a new environment in under a week, the exit key works. If not, Claudia and Markus know exactly where the stack sticks.
The Portable Architecture That Makes Exit Possible
Portability is not a product you buy. It is a property you build in. The portable architecture rests on four pillars that together prevent exit from becoming a disaster.
Kubernetes as the Abstraction Layer
Kubernetes standardizes parts of deployment. A move must still address storage, networking, ingress, identities, secrets, and external services. The StorageClass documentation, for example, describes provider-specific provisioners. Test a representative workload on the target before estimating effort and residual dependencies.
Open Data Formats and Open-Source Workloads
Open databases and protocols can make switching easier. Extensions, operating features, data volumes, and interfaces still need checking. Whether self-hosting costs less depends on capacity, staff, and maintenance. An open license alone makes a system neither fully portable nor more economical.
Infrastructure as Code for Reproducible Environments
Infrastructure as Code can document deployment and make it repeatable. Resources, provider modules, secrets, and data recovery still need validation on the target. A limited migration test would be a useful next step for the illustrative business. No particular reduction in migration time has been measured.
Sovereign DACH Hosting Options as Fallback
Evaluate a target provider using its contract, technical suitability, data flows, and jurisdiction. The CLOUD Act concerns covered providers subject to US jurisdiction and data in their possession, custody, or control; lacking a US parent alone is not a conclusive exclusion test. Location and corporate structure are inputs to the review, not blanket approval.
From the Lock-In Trap to Conscious Dependency
The difference between a trap and a conscious dependency lies in architecture. Here the contrast is visible in the example of this engineering services firm.
Before: An Architecture with No Exit Key
Three workloads on a US hyperscaler: Managed Kubernetes with provider-specific ingress controllers, a managed PostgreSQL instance with proprietary extensions, serverless functions tightly coupled to the provider's message-queue service. 12 SaaS integrations whose authentication runs through the hyperscaler's identity provider. No documented network topology, no IaC pipelines, no regular backup-restore test on alternative infrastructure. The exit key does not exist.
After: A Stack That Chooses Providers by Value
After a six-month standardization phase, the same functional scope runs on a Kubernetes cluster with Helm charts and GitOps. PostgreSQL as a StatefulSet with standardized backup jobs. n8n for automations on a self-hosted instance with local data execution. The SaaS integrations use OAuth2 with portable credentials instead of provider-specific IAM roles. A second, smaller cluster at a DACH provider serves as an active fallback. The annual switching drill confirms: A critical workload can be moved in under 30 days.
The result is not ideology. It is conscious dependency: This engineering services firm still uses the US hyperscaler for specialized AI workloads because it makes economic sense there. But the decision is now a choice — not a constraint.
How Planfold Builds Sovereignty into Architecture
At Planfold, we treat exit capability not as an emergency procedure, but as a continuous architecture property. Our methodology follows three phases that are technically defined and operationally traceable.
Plan — Audit Lock-In Risk and Design Portable Architecture
We begin with an audit of the existing stack: Which workloads are bound to proprietary APIs? Which data formats are portable, which are provider-specific? Which customer contracts require demonstrable exit capability or data localization? Who in the company owns the credentials, documentation, and deployment procedures for a provider switch? The result is not a theoretical risk list, but a prioritized roadmap with concrete steps.
Unfold — Roll Out Sovereign Infrastructure on Standardized Layers
We deploy the target architecture on Kubernetes, use Infrastructure as Code for reproducible deployments, and rely on open data formats. Every new managed-service decision passes through a 15-minute lock-in risk assessment — a review gate that Claudia and Markus at this engineering services firm have institutionalized for every architecture decision. The infrastructure runs in a DACH data center with documented data residency and ownership.
Resonate — Continuously Demonstrate Portability and Compliance
Agree when exports, recovery and documented dependencies should be checked again. A successful trial becomes less informative when the data model, infrastructure or permissions change. Review records can support customer and legal questions; they do not automatically establish compliance.
A Practical Starting Point for SMEs
You do not need an enterprise platform team to start with portability. You need five clear architecture decisions and a 90-day plan.
The Five Architecture Decisions That Secure Portability
- Containerization as standard: Every new workload is delivered as a container, not as a provider-specific serverless function or proprietary service. Kubernetes becomes the target platform.
- Open data formats: New data storage uses PostgreSQL, MySQL, or other open standards. Proprietary database services are retained only for existing workloads, not for new development.
- Infrastructure as Code: Every environment is versioned in code. Manual configuration through the provider's web interface is forbidden — even for quick tests.
- Decoupled integration layer: SaaS integrations use standardized APIs and portable authentication mechanisms. No tight coupling to provider-specific IAM roles or message queues.
- Documented ownership: For every workload there is a documented deployment procedure, a backup-restore test plan, and a named owner — regardless of who happens to be on vacation.
The 90-Day Exit-Readiness Plan
- Day 1–30: Lock-in risk audit. Identify your three most tightly bound workloads and estimate their migration costs. Document egress fees for the last 12 months.
- Day 31–60: Standardize one workload. Containerize, build an IaC pipeline, introduce open data formats. Run your first switching drill.
- Day 61–90: Institutionalize review gates. Every new managed-service decision passes the 15-minute lock-in check. Quarterly egress and portability reviews are anchored in the calendar.
Start with a representative data copy and one critical workflow. Record the changes needed at the destination, who accepts the result and how to fall back to the existing environment.
Plan. Unfold. Resonate.
