--- title: "Exit Strategy & Portability" description: "How organisations avoid cloud lock-in on STACKIT: open-standards architecture, data portability, contractual protection clauses and the strategic advantages of STACKIT's open ecosystem." sidebar: order: 7 label: "Exit Strategy" source_url: "https://framework.stackit.cloud/advisory/cloud-vision-and-strategy/exit-strategy/" source_file: "docs/advisory/cloud-vision-and-strategy/exit-strategy.mdx" --- ## Open standards create genuine freedom of choice The strongest attribute of a cloud provider is not the depth of its product portfolio but the freedom it leaves its customers. STACKIT is built on open standards — OpenStack, Kubernetes, S3 — not because it is technically obligatory, but because it is the only architecture that guarantees long-term independence. This independence is not a theoretical promise. It is concretely anchored in every line of infrastructure code, in every container, in every backup. Whoever builds on STACKIT builds on standards that no single provider controls — and that therefore no single provider can unilaterally change. Documenting an exit strategy is not preparation for distrust. It is proof that your architecture decisions are sound. An organisation that cannot explain how it would execute a provider change has a lock-in it has not yet noticed. ## What lock-in actually means Lock-in is not a binary decision. It arises gradually across multiple dimensions. **Technical lock-in** arises when applications use proprietary APIs, data formats, or services that are not portable. **Data-related lock-in** arises through volume. An organisation with several petabytes of data at one provider pays substantial egress fees to move it. Some providers charge 8–12 cents per GB for data egress — at 100 TB that amounts to EUR 8,000–12,000 for a single transfer. **Contractual lock-in** arises through term contracts, discount structures (committed-use discounts tied to minimum consumption), and notice periods. **Competency lock-in** arises when the internal team only knows one platform. A move would be technically possible but organisationally too painful. ## Why STACKIT performs structurally better STACKIT is built on open standards — not for marketing reasons, but because the platform is based on OpenStack, Kubernetes, and S3-compatible interfaces. This decision has direct consequences for portability. STACKIT instances, networks and storage are managed via OpenStack APIs. Terraform modules written for STACKIT can be transferred to any other OpenStack environment with minimal adjustment effort. STACKIT SKE (Managed Kubernetes) implements upstream Kubernetes without proprietary extensions. Kubernetes workloads run on STACKIT without vendor extensions and are portable to any other CNCF-certified cluster. STACKIT Object Storage fully implements the S3 API. Applications using S3-compatible storage can be migrated to STACKIT without code changes — and back again. STACKIT data transfer pricing is transparent and regulatorily compatible. No hidden pricing model that artificially raises exit costs. ## What an exit strategy concretely contains An exit strategy is not a cancellation plan. It is a document that gives the organisation clarity on what a provider change would mean — and whether the current architecture enables it. **Components of a complete exit strategy:** **1. Architecture audit for portability** Which services use STACKIT-specific APIs? Which are open-standards-based and immediately portable? The result is a portability matrix that shows, for each component, how much effort a change would require. **2. Data inventory with egress calculation** How much data is held on STACKIT? What would transfer costs be in a migration? This figure should be known to every executive team — not because a move is planned, but because it determines the actual negotiating position. **3. Contractual protection clauses** What has been agreed contractually? Are there term commitments? What are the notice periods? Is data handover process contractually guaranteed? **4. Migration runbook (high level)** A rough plan showing what migration to an alternative provider would look like. Not worked out in detail, but far enough that executives can assess the complexity. **5. Regular review** The exit strategy should be updated annually — architectures evolve, new services are added, and the portability matrix changes. ## Contractual safeguards Regardless of technical design, there are contractual points that should be addressed in every cloud agreement. **Data return:** The provider must contractually commit to returning all data in a standardised format upon termination. Typical formats: SQL dumps, CSV export, S3 bucket transfer. **Migration support:** Does the provider offer active assistance with data extraction? STACKIT provides documentation and technical support for this. **Data deletion:** After data export the provider must confirm deletion of all data — in writing and verifiably. This is relevant for GDPR compliance (Art. 17). **Term and termination:** Prefer flexible monthly contracts or short annual contracts over multi-year commitments with high discount incentives. Long-term commitments should only be made for capacity that is genuinely and reliably planned. ## Architecture decisions that secure portability The following principles, implemented from the outset, minimise lock-in without additional effort. **Open-source-first for middleware:** Kafka instead of a proprietary message queue. PostgreSQL instead of a cloud-only database service. Redis instead of a proprietary cache. All run on STACKIT, all run elsewhere. **Infrastructure-as-code from day one:** An organisation that describes its infrastructure in Terraform has a portable description — not a set of manual configurations that cannot be reproduced anywhere else. **Container-first for applications:** Containerised applications are portable by definition. They run on any Kubernetes cluster, on any container host. **12-factor application design:** Applications that read configuration from environment variables and are stateless can be transferred to new infrastructure without rewriting. ## STACKIT and portability — an honest assessment STACKIT offers some managed services that are not directly available 1:1 on other platforms. That is not unique to STACKIT — it applies to every managed database or managed Kubernetes service. The difference: the interfaces are open. A Managed PostgreSQL on STACKIT is not the same as a self-hosted PostgreSQL cluster — but the data and schemas are fully portable because PostgreSQL is an open standard. A Managed Kubernetes on STACKIT is not the same as a self-operated cluster — but every application running on it is, because Kubernetes is an open standard. **The exit strategy for STACKIT customers is structurally better than for customers of proprietary US Hyperscalers.** This is not a promise but a technical consequence of the architectural decisions on which STACKIT is built.