Platform Ownership Playbook for SMEs: From Rented Cloud Silos to an Owned, Portable Stack
More than half of EU enterprises now use paid cloud services. Here is how SMEs can selectively own critical platform layers without building a 24/7 platform team.
Contents
More than half of EU enterprises now use paid cloud services. Here is how SMEs can selectively own critical platform layers without building a 24/7 platform team.
Share this article
The renewal that suddenly doubles
It is Tuesday morning. The managing director of a 42-person industrial services company in southern Germany opens the renewal quote for the managed customer-portal platform. The price has risen by 35 percent. The explanation sounds technical: new security features, expanded data-residency options, higher API limits.
That alone would be annoying, but it is not the real problem. The problem is the sentence in the fine print: data exports above a certain volume will now incur extra charges, the previous standard SLA moves into a higher price tier, and any company that wants to switch before the next renewal must give six months' notice.
The managing director calls in the operations lead and the software engineer for a short meeting. The central question is asked quickly: could we run this somewhere else? The answer is harder than expected. Nobody has a complete list of dependencies. The data is "in the EU", but the contract permits subcontractors outside the DACH region. The backup procedure has never been tested. The interfaces that move customer data in and out are documented, but only as screenshots in the external provider's wiki.
This is the classic rented-silo moment: the company runs a business-critical system without really controlling it. According to the latest Eurostat enterprise survey on cloud computing, 52.74 percent of EU enterprises now use paid cloud services; among small enterprises with 10 to 49 employees the figure is 49.3 percent. Even more telling is the dependency figure: 77.53 percent of these cloud users are classified as "highly dependent" because they buy sophisticated services such as security software, hosted databases, or application platforms. In short, when the contract changes, the business is in a weak negotiating position.
The price increase is only the trigger. The real burden is the realisation that the infrastructure is no longer movable.
Why rented platforms cost more than they appear
The visible price of a managed platform is only the tip. Beneath it sits a stack of costs that are rarely visible day-to-day, because they grow across many months and several teams.
The subscription price is only the first layer. On top come egress-based data-export fees that can become a surprise as customer volumes grow. Then there are forced upgrades when the provider retires older plans, and expensive integration work because the proprietary interfaces do not match the new tools the company actually wants to introduce.
The second layer is operational. When no one in the house fully understands a system, decisions disappear into external tickets. Every error becomes a vendor ticket, every adjustment becomes a project quote. The apparent convenience of a managed platform turns into administrative dependency.
The third layer is strategic. If you cannot leave your workloads, you lose bargaining power. Seat prices rise, features move into higher tiers, and the willingness to switch providers falls because the exit looks unclear. A CloudComputing-News report citing Omdia forecasts that global cloud infrastructure spending will grow by a further 27 percent in 2026, exceeding US$500 billion annually. A growing market does not automatically mean higher bills for every SME, but it signals that price pressure and resource scarcity will also reach smaller contracts.
This dynamic makes one thing clear: in the cloud era, ownership does not mean "self-host everything". Ownership means operational control over the layers that differentiate the business, plus a maintained exit key for the day the contract or provider no longer fits.
The three warning signs that ownership is missing
Many companies do not notice the loss of ownership while everything is running. It only becomes visible when something changes. Three signals indicate that control over the platform is slipping.
1. Price spiral without leverage
The renewal arrives with a sharp increase, but the company has no realistic alternative. Switching looks more expensive than staying because no one in the house understands the full stack. This is where it becomes clear that the infrastructure is no longer interchangeable. The provider can raise prices because the exit was never made practical.
2. Data location built on subcontractors
The contract says "EU", but for a regional customer that is not enough. DACH data residency is claimed but cannot be reliably proven, because subcontracts, content-delivery networks, or backup locations are missing. This is a typical warning signal for companies handling sensitive customer data or meeting regulatory requirements.
3. Exit that costs more than staying
Data exports cost money, the format is proprietary, and the runbooks for recovery exist only with the provider. The EU Data Act requires switching charges, including data-egress fees, to be removed entirely from 12 January 2027. That is an important planning horizon, but not an automatic migration assistant. Without your own operating documentation, switching remains risky even as fees fall.
If you recognise any of these three signals, the response should not be a panicked move of everything. It should be a repositioning of platform strategy around ownership.
What SMEs can realistically own
Not every layer of a platform has to run in your own data centre. The goal is selective ownership: own the layers that carry the most business value and control needs, and consciously leave the rest managed.
Layer 1: Data and application logic
For most SMEs this is the most important ownership area. It is where customer data, business rules, and competitive differentiation live. If this layer stays on a proprietary platform, it binds not only cost but knowledge. A portable application layer can run in containers, be versioned, and be restored in another location.
Layer 2: Runtime and platform
Kubernetes is now a realistic option for smaller teams. According to the CNCF 2025 Annual Survey, 82 percent of container users now run Kubernetes in production, up from 66 percent in 2023. That does not mean every SME needs a cluster. It means the technology is established, documented, and portable. Operating this layer yourself gives control over releases, resource utilisation, and recovery. Introducing it without operating discipline turns it into a new black box.
Layer 3: Network, storage, and identity
This layer is often the last candidate for ownership. Storage and networking are close to commodities; identity providers require strong security discipline. Many SMEs continue to rent these services deliberately until a concrete residency or compliance reason justifies self-hosting. The important thing is that the contract specifies open interfaces and clear data formats so a switch remains possible.
The order is intentional: ownership starts where business value is highest and portability is easiest to implement.
The platform ownership playbook in five phases
Ownership approached as an iterative operating model, rather than a big bang, avoids the usual failure modes: unmaintained islands, cluster-as-black-box, and untested exit plans. The playbook has five phases.
Phase 1: Audit inventory and dependencies
First, map what is running today. That includes not just workloads but contracts, data flows, interfaces, egress costs, backup rules, and responsibilities. The goal is a ranked list by business criticality, dependency, and portability. Without this map, every later decision is guesswork.
Phase 2: Choose what to own first
The first candidate should have high business value but low dependencies. An internal customer portal, an internal reporting service, or a batch-processing job is often a better fit than the primary e-commerce system. The rest stays with the existing provider for now. Selective ownership means conscious retention as much as conscious relocation.
Phase 3: Build portable
The selected layer is containerised, described with Helm or Kustomize, and managed through GitOps. Infrastructure as Code ensures the environment is reproducible. Open interfaces and machine-readable data formats are not nice-to-haves; they are the technical foundation of the exit key. The EU Data Act demands exactly such open formats for cloud services, a regulation that eases migration but does not automate it.
Phase 4: Establish operations and evidence
An owned platform without an operating routine is riskier than a managed one. Backups must be tested, patches applied on a cycle, incidents documented and reviewed regularly. Observability, runbooks, and a clear incident-response process are not optional; they are prerequisites for the team to trust the owned layer. The CNCF survey notes that "cultural changes with the development team" are now the top cloud-native adoption challenge. The technology is solvable; the organisation is the critical factor.
Phase 5: Maintain the exit key
The exit key is the documented ability to move the workload elsewhere. It contains data formats, API documentation, rollback steps, contacts, and the results of the latest restore tests. It must be reviewed at least quarterly, or it ages faster than expected.
A realistic SME case
A 42-person industrial services company in southern Germany runs an internal customer portal for maintenance contracts, documents, and service requests. The numbers are illustrative; the scenario is typical for the Mittelstand.
Starting position: About 180 monthly users work in the portal. Application data totals 12 to 15 terabytes. Six productive workloads run on a managed platform. Three regional customers explicitly require DACH data residency. There are two to three platform releases per month and one to two vendor tickets for non-reproducible errors.
Roles in the company:
- The managing director owns budget and customer commitments.
- The operations lead runs the current platform and evaluates alternatives.
- The software engineer maintains the application and its dependencies.
- An external Kubernetes/DevOps consultant supports migration and platform design part-time.
Decision points:
- Which workloads are critical enough to justify ownership?
- Which dependencies can be replaced with open standards or self-hosted components?
- Where is DACH hosting needed, and where is a geo-redundant EU location sufficient?
- Can the team sustain patch cycles, backups, and incident response without 24/7 on-call?
- Which exit key must be documented and tested before the next renewal?
Review gates: The managing director approves criticality and data-residency requirements before any migration. The operations lead documents every dependency and test; no workload moves without a rollback plan. The software engineer checks the portability of application dependencies. The external consultant validates Kubernetes design and backup/restore tests. A monthly review covers costs, incidents, restore-test results, open tickets, and the next ownership candidate.
Illustrative outcome: The team decides to migrate the customer portal first to an owned Kubernetes layer with DACH hosting. Pricing becomes more predictable, data residency demonstrable, and dependence on a single provider falls. After 90 days there are documented restore tests, an incident-review format, and a ranked list of the next workloads to own.
This is not a customer case study; it is a planning model. But it shows that ownership is not one large investment. It is a sequence of clear decisions and review gates.
How Planfold turns ownership into an operating model
Planfold separates the work into three phases that must work together for platform ownership. Each phase has a technical meaning, not just a marketing label.
Plan means auditing by criticality, cost, and dependency.
Together with the company we build a map of existing workloads, contracts, data flows, cost drivers, and team capabilities. The result is not a generic recommendation but a ranked list: which layer first, which later, and which deliberately stays with the current provider. The Planfold Sovereignty review is the entry point to this phase.
Unfold means building the owned layer so it is sustainable.
That includes portable Kubernetes operations, Git-controlled infrastructure, DACH hosting options where required, and the deliberate use of self-hosted or open-source components where they are operable. n8n workflows take over recurring operational routines, from ticket handling to monitoring. Backup and restore routines and observability belong to the delivery, not to afterthoughts.
Resonate means running the system with review evidence.
Ownership only becomes sustainable if it is reviewed regularly: cost reviews, restore tests, incident reviews, and maintenance of the exit key. This evidence is both the trust foundation for management and the operational basis for audits or customer questions.
The first 90-day plan: from rented silo to owned layer
Ownership is not created in a strategy offsite; it is created through 90 days of concrete work. The plan is deliberately narrow.
Weeks 1-2: Inventory and exit costs
Inventory all productive workloads, contracts, interfaces, and data flows. Estimate egress costs, notice periods, and migration effort. Define the first workload to move and justify the choice by business value, dependency, and team capability.
Weeks 3-6: Pilot workload and viable platform
Build the target environment for the pilot. Containerise the application, describe it with Helm or Kustomize, and introduce GitOps. Run at least one successful restore test before any data goes live. Keep the old system running in parallel until the team trusts the new layer.
Weeks 7-12: Operating routine and review evidence
Establish the patch cycle, monitoring, alerting, and runbooks. Hold a monthly review covering costs, incidents, restore tests, and open tickets. Document the exit key and identify the next ownership candidate.
The goal after 90 days is not complete independence. The goal is a proven operating mode for one owned layer and a clear decision basis for the next step.
