Sovereign Infrastructure Retrospective: What SMEs Actually Learn After Migration

The month after the migration

Eva is not opening the old hyperscaler invoice. Six months earlier, that invoice had become the symbol of the problem. The illustrative DACH company, a 58-employee industrial services provider, has moved its customer portal, document exchange, and internal automation runner from accumulated cloud rental into a more controlled DACH-hosted operating layer. Jonas, the part-time technical owner, brings Git merge requests, Kubernetes manifests, backup records, and the first monitoring signals into the review. Lena from Finance brings the capacity numbers. Markus from Operations wants to know whether the portal is actually more reliable for customers.

This meeting feels different from a migration kickoff. Before the move, the questions were easy to name: why are costs rising, where is the data, and how dependent are we on the provider? After the move, the questions become more specific and less comfortable. Which capacity is oversized? Which restore test proves the portal can be rebuilt, not just observed while it is running? Who owns the credentials? Which workflows were really decoupled? Which dependencies stayed because moving them would have created more risk than control?

The market context makes those questions urgent. dpa reporting on the Bitkom Cloud Report 2026 described a strong concern among German companies about dependency on US cloud providers, while actual provider use and perceived capability gaps still keep many firms tied to those platforms (WELT/dpa, 2026). That is not a case for a blanket cloud retreat. It is a signal that sovereignty cannot be reduced to a provider label. It has to show up in operations.

A sovereign infrastructure migration is therefore not complete when DNS has changed and data has been copied. It becomes credible when the company can explain, 30 days later, what actually improved in cost shape, data location, recovery evidence, ownership, and negotiating position. That is the job of the retrospective.

Why cloud exit does not end with the move

The common mistake is saying: "We moved, so we are sovereign now." The move only changes the starting point. It does not replace architecture decisions, runbooks, access policy, cost reviews, or tested recovery paths. A company can leave a hyperscaler and still build a new black box if operations, documentation, and responsibility do not move with the workload.

The Flexera 2026 State of the Cloud gives broader context: cloud estates are often hybrid, wasted spend remains a visible issue, and many organizations arrive at complex multi-cloud or hybrid environments by accumulation rather than by deliberate design. For an SME, the lesson is direct: cost control does not come from "cloud" or "self-hosted" as slogans. It comes from workload placement, measurement, capacity planning, and ownership.

Cost shape: from variable bill to planned operations

After a migration, the old variable bill rarely disappears cleanly. It changes shape. Usage-based cloud rental becomes planned server capacity, backup storage, monitoring, support time, maintenance windows, operations partners, and internal responsibility. That can be more controllable. It can also become opaque differently if nobody checks whether CPU, memory, storage, network, and retention match real workload behavior.

For this DACH industrial services provider, the first lesson is both financial and technical. Lena does not compare "cloud before" with "DACH operations after" as two single numbers. She reviews forecast against real usage, backup growth against retention goals, and support effort against incident records. Jonas adds which reserves are deliberate and which are simply cautious overprovisioning. Only then does the move become a business decision rather than a hosting swap.

Data location: residency is not an operating model

DACH hosting can be an important answer when customers ask about data location, access paths, or provider dependency. But data location alone does not answer who may read the data, how exports work, which metadata stays attached to a workflow, how backups are tested, or how a provider switch is documented. Location improves the starting position. The operating model decides whether that position remains defensible.

The EU Data Act also raises expectations around switching between data processing services. But policy does not document your field lists, credentials, provider-specific APIs, runbooks, or restore tests. This article is architecture and marketing information, not legal advice. The practical lesson remains: switching rights become useful only when your own infrastructure is designed and rehearsed for switching.

Ownership: who owns the next incident?

Before the migration, the provider was often the convenient place to point. After the migration, responsibility sits closer to the company. That is the point of sovereignty, but also the discipline it requires. If the portal fails at night, Markus needs to know which process starts. Jonas needs logs, deployment history, and rollback paths. Eva needs to decide whether customer communication is required. Lena needs to know whether an emergency creates extra capacity, external support, or a contract escalation.

Sovereignty does not mean doing everything yourself. It means responsibility is visible and allocated across contract, technology, and organization. A full-service partner can operate the environment. A DACH provider can host it. Planfold can build architecture, Kubernetes operations, n8n workflows, GitOps, and documentation. The company still needs a named owner, an evidence path, and an exit key.

What worked in hindsight

A useful retrospective does not only look for failure. It records which decisions made the migration worth doing. For this DACH industrial services provider, the full stack was never the candidate. The customer portal, document exchange, and automation runner were close to customer trust, data location, continuity, and integration logic. Other systems intentionally stayed managed because moving them would have added operating work without adding meaningful control.

That selectivity matters. An SME without a dedicated platform department gains nothing by self-hosting commodity tools on principle. The better question is: which workload is strategic, data-sensitive, cost-sensitive, or dependency-sensitive enough that more ownership justifies the extra operating model? That is where sovereign infrastructure starts.

Workload selection before ideology

This DACH industrial services provider first selected the workloads where operational control had a clear purpose. The customer portal serves about 260 active portal users per month. The document exchange holds 620 GB of project files in this illustrative scenario. The CRM connector and nine daily n8n workflow runs move information between service, finance, and operations. These are not customer metrics and not a benchmark. They simply show the scale at which a Mittelstand workflow can become critical long before anyone has a platform team.

At the same time, part of the SaaS landscape stayed where it made sense. Email, accounting, and specialist business applications do not automatically need to move. Progress does not come from removing every external dependency. It comes from naming each important dependency, knowing the exit path, and weighing its value against operating risk.

Git, IaC, and containers as rebuild path

The strongest lesson in hindsight was not a single tool. It was repeatability. Infrastructure definitions lived in Git. Changes went through merge requests. Kubernetes manifests, Helm or Kustomize configuration, and CI/CD paths made the intended state visible. Backup and restore notes were not treated as a project-closing folder. They became part of operations.

The Kubernetes documentation describes Kubernetes as a portable, extensible, open source platform for containerized workloads with declarative configuration and automation. That is valuable for suitable workloads. It is not a complete PaaS, a database, a monitoring strategy, or an automatic escape from lock-in. The value appears only when containers, data, secrets, networking, logs, and delivery paths are operated together.

DACH operations where data and customer trust matter

DACH operations helped this DACH industrial services provider not as a slogan, but as a clearer conversation. Eva could explain where relevant operational data sits, who can access it, and how evidence is maintained. Markus could connect support and escalation paths to the actual runtime. Jonas could operate a target environment that was not only visible through provider consoles, but through Git, runbooks, and monitoring.

The lesson is sober: data location is a building block. It works only with access control, recovery, logs, export paths, contract review, and operating signals. Buying DACH hosting without that layer may improve the location question while leaving the sovereignty question open.

What hurt: hidden migration costs

The most painful migration costs did not all sit on the provider invoice. Some appeared as parallel operations. Some as test effort. Some as missing documentation. Some as decision fatigue because nobody could say, before the move, which integrations were truly production-critical.

This DACH industrial services provider had to review 14 external integrations. Three were business-critical but less documented than expected. Two workflows contained exceptions only Markus in Operations knew well. One service account still traced back to a former delivery partner. Details like these look small until they define the migration calendar.

Egress, synchronization, and parallel run

Data rarely moves once. For the portal, documents had to be copied, checksums reviewed, database states synchronized, search indexes rebuilt, and user permissions compared. During that period, the old stack kept running because customers do not wait for a clean architecture diagram. Parallel run is not a side note. It is a cost category.

The better plan treats egress, synchronization, and parallel operations as explicit categories. Not every number can be known in advance. But every category should be visible in the plan so Finance does not learn only after migration why the old provider still generates weeks of cost.

Unclear dependencies in old workflows

The second pain point sat inside workflows. One n8n flow was exportable, but its credentials, environment variables, and error paths were not fully described. A CRM connector used fields that Operations interpreted differently from Finance. A customer notification depended on a webhook whose retry behavior had never been tested.

These are not arguments against automation. They are arguments for operating discipline. Every critical workflow needs an owner, test data, an error path, a review gate, and a log trail. Otherwise, the migration becomes archaeology.

Runbooks written during the incident

The third pain point was organizational. Some runbooks were written only after something got stuck. That is human, but expensive. A runbook written during an incident competes with customer pressure, fatigue, and lost time. A good migration program writes first runbooks before the move, updates them during parallel run, and tests them during the first real restore or rollback exercise.

The lesson is uncomfortable: sovereignty initially makes work visible that a provider had hidden or an individual had carried. That is not failure. It is the moment when operations become honest.

The retrospective model for SMEs

A 30-day retrospective should be short enough to happen and concrete enough to change decisions. For SMEs with 10 to 100 employees, five questions are enough to start: which workload moved, how did the cost shape change, what do we now know about data location and access, what recovery evidence exists, and who owns operations?

The answer does not always have to be "more sovereignty". Sometimes the right decision is to keep a workload managed. Sometimes it should move because cost, data, or customer requirements justify it. Sometimes it needs to be rebuilt because the old stack is too tightly bound to proprietary services. Sometimes it should be deferred because dependencies are still unclear.

Dimension	Retrospective question	Good evidence	Possible decision
Workload	Why did this exact workload move?	Criticality, data type, integrations, and users are documented	keep managed, move, rebuild, or defer
Cost shape	Which costs disappeared, and which appeared?	Forecast, actual usage, capacity, backup, support time	tune capacity or change operations
Data location	Can we explain location, access, and export?	Data-flow map, access list, export test	clarify data model or provider path
Recovery	Can the workload be restored?	Restore test with time, data scope, and reviewer	adjust RTO/RPO or improve runbook
Operations	Who responds to signal, incident, and change?	Owner, runbook, alert, escalation path	name owner or stop moving more workloads

This model prevents two extremes. It prevents the shallow success report that says "everything runs". It also prevents the technical loop where one more diagram, one more tool, or one more cluster is always missing. The retrospective asks for evidence that supports a decision.

A realistic scenario: portal, files, automation

This DACH industrial services provider is an illustrative scenario, not a Planfold customer case. That makes it useful for a sober review. In this model, the company operates a customer portal, document exchange, CRM connector, and operations automation. It has 620 GB of project documents, 120 GB of PostgreSQL data, 2 TB of backup retention, 32 containers across five services, 14 external integrations, nine n8n workflow runs per day, 260 portal users per month, and three release windows per month. All numbers are model values, not promised outcomes.

The roles matter as much as the technology. Eva owns customer commitments, contracts, and budget decisions. Markus owns service workflows, handoff quality, and continuity expectations. Jonas owns manifests, CI/CD, backups, access, logs, and restore evidence as a part-time technical owner. Lena owns cost allocation, capacity reviews, and renewal decisions. Without these roles, the migration would be only a technical project.

Before: fast cloud, unclear ownership boundaries

Before the migration, the stack had grown quickly. The portal was reliable enough, but nobody could fully explain in a review which integrations would be hit first during an outage. Documents sat in several stores. The CRM connector worked, but field meaning and error paths were not fully documented. An external delivery partner remembered parts of the deployment history better than the internal team.

The key finding was not that the old cloud was bad. The key finding was that this DACH industrial services provider did not know its operating boundaries well enough. The company had bought speed and blurred part of the title deed along the way.

After: portable runtime, restore test, review rhythm

After migration, not everything is perfect. But the open questions are visible. Containers run on a more portable runtime layer. Git shows the desired state. A restore test records data scope, timestamp, reviewer, and deviations. n8n workflows have owners, error paths, and human review where customer impact or contractual data is involved. Lena reviews forecast, actual usage, and reserve capacity each month. Eva no longer decides from instinct whether the next workload should move.

The retrospective ends with four decisions. The portal stays in the new environment and receives a tighter restore schedule. A reporting workload stays managed because migration effort would outweigh control. An old CRM connector is rebuilt because its dependencies are too unclear. An archive workload is deferred until data classification and retention are cleaner. That is sovereign infrastructure in practice: not moving everything, but deciding better.

How Planfold makes sovereign infrastructure operable

Planfold does not treat sovereign infrastructure as an anti-cloud position. The operating question is: which digital machine should your company own, which convenience should you buy deliberately, and which exit key stays in your hands? That creates a care-free package with a title deed: operations, maintenance, and hosting can reduce burden, while code, data flows, documentation, credentials, runbooks, and review trails remain traceable.

Plan means auditing technical debt, workload criticality, data flows, provider dependencies, contracts, credentials, recovery expectations, and cost drivers. The output is not an abstract cloud strategy. It is a prioritized map: what stays managed, what moves, what gets rebuilt, and what waits.

Unfold means building the right operating layer. For some workloads, that means APIs, documentation, and export tests. For others, it means Kubernetes operations, GitOps, Infrastructure as Code, CI/CD, DACH hosting options, backup and restore routines, observability, and n8n workflows with human review gates. CKA, CKAD, and LFCS are capability signals for Kubernetes, cloud-native delivery, and Linux operations, not compliance badges.

Resonate means operating infrastructure through signals. Release notes, incident reviews, restore tests, cost reviews, capacity decisions, runbook changes, and owner handoffs keep the exit key current. A one-time migration ages. A maintained operating model keeps decisions open.

Planfold's infrastructure and Kubernetes proof pages are capability evidence, not promises of identical client outcomes. The work stays concrete: Git as source of truth, CI/CD as a traceable delivery path, Kubernetes where runtime portability justifies the operating layer, and n8n where operations workflows need visibility, review, and error paths.

The 30-day retrospective after every migration

The most practical starting point is not another large architecture workshop. It is a 30-day rhythm after every migration wave. Small enough for a Mittelstand team, concrete enough for management and engineering, and repeatable enough for the next workload.

Week 1: cost and capacity review. Compare forecast, actual usage, reserves, backup growth, monitoring cost, and support effort. Mark deliberate reserves differently from unclear overprovisioning.

Week 2: restore and rollback test. Test a real recovery path. Record timestamp, data scope, people involved, deviations, and open gaps. If RTO or RPO is still aspirational, write that down and make the next test narrower.

Week 3: runbooks and owners. Every critical signal needs an owner, runbook, escalation path, and review trail. If operations only works because Jonas remembers it, the exit key has not reached the organization.

Week 4: contract, exit key, and next workload. Review notice periods, export paths, credential ownership, provider dependencies, and the next decision point. Then decide by workload, not ideology: keep managed, move, rebuild, or defer.

The result is not a perfect platform. It is better decision-making. You see which control was actually gained, which work became newly visible, and which dependency remains intentional.

Plan. Unfold. Stay Sovereign.