Zurück aus der Wolke: Wann Cloud Repatriation für den Mittelstand wirklich rechnet – und wann sie zur Falle wird

Im April 2026 berichten Marktbeobachter und CIO-Umfragen mit auffälliger Konsistenz von einem Trend, der vor drei Jahren noch als ketzerisch galt: Cloud Repatriation, die geplante Rückverlagerung von Workloads aus der Public Cloud in eigene oder co-lokierte Infrastruktur. IDC zählt 71 Prozent der befragten Unternehmen zu den Repatriierern, eine Barclays-Umfrage spricht von 86 Prozent der CIOs, die zumindest Teile ihrer Workloads zurückholen wollen. Diese Zahlen sind eindrucksvoll – und gleichzeitig gefährlich, weil sie ein einfaches Narrativ nahelegen: „Cloud raus, Hardware rein, Geld gespart."

Die Realität in deutschen Mittelstandsunternehmen ist komplizierter. Sie ist auch interessanter. Dieser Beitrag rekonstruiert anhand eines realistischen Szenarios, wann sich der Rückweg tatsächlich rechnet, welche Fallen auf dem Weg lauern, und welche strategische Architektur 2026 wirklich tragfähig ist. Spoiler: Das Endspiel heißt nicht „Cloud raus", sondern „Cloud sortieren".

Der Aufhänger: Was sich seit 2023 geändert hat

Bis vor wenigen Jahren war Cloud-First in vielen IT-Strategien gesetzt. Public-Cloud-Rechnungen wurden als variable Kosten verbucht, Skalierung als Versprechen behandelt, Lock-in als hinnehmbarer Preis für Geschwindigkeit. Drei Entwicklungen haben dieses Bild seit 2024 grundlegend verändert.

Erstens die Egress-Realität. Wer Daten aus AWS, Azure oder Google Cloud nach außen bewegt – sei es zu einem anderen Provider, in ein eigenes Rechenzentrum oder in ein KI-Trainingscluster – zahlt dafür substanziell. AWS berechnet aktuell 0,09 US-Dollar pro Gigabyte für die ersten 10 TB Datentransfer pro Monat, bei Petabyte-Volumina entspricht das fünf- bis sechsstelligen Beträgen jährlich. Diese Kosten waren in TCO-Modellen aus den frühen 2020ern systematisch unterschätzt.

Zweitens der regulatorische Druck. Der EU AI Act mit seinen Hochrisiko-Bestimmungen, der Data Act, NIS2 und branchenspezifische Vorgaben wie DORA verlangen Nachweisbarkeit, Datenstandort, Auditierbarkeit. „Wir betreiben das in einer EU-Region eines US-Hyperscalers" reicht in vielen Audit-Gesprächen nicht mehr als Antwort. Hinzu kommt der EU Data Act, der pauschale Egress-Gebühren ab dem 12. Januar 2027 verbieten wird – ein Zeichen, wie ernst die Politik den Lock-in mittlerweile nimmt.

Drittens die ökonomische Schwerkraft von KI-Workloads. Wer 2026 ein Sprachmodell selbst trainiert, ein Vector-Embedding-Layer betreibt oder GPU-intensive Inferenz im Bereich Tausender Anfragen pro Sekunde fahren muss, stößt in der Public Cloud auf vier- bis fünffach höhere Stundenkosten als bei dedizierter Hardware – sofern überhaupt verfügbar. Die GPU-Knappheit hat den Mythos der „unbegrenzten Skalierung" zumindest für AI-Lasten zu Grabe getragen.

Die User Story: Ein Mittelstandsunternehmen entscheidet sich

Um die Mechanik konkret zu machen, folgen wir einem realistischen Szenario. Die Brunner Industriearmaturen GmbH ist ein erdachter, aber typischer pleXtec-Kundentypus: 380 Mitarbeitende, vier Werke in Süddeutschland und Österreich, IT-Leitung mit fünf festen Mitarbeitern, ein dedizierter ISMS-Verantwortlicher, ERP von SAP, klassische Office-Workloads in Microsoft 365, eine produktnahe Engineering-Plattform mit CAD-Datenhaltung und – seit 2023 – eine cloudbasierte IoT-Plattform für die Maschinenüberwachung in den eigenen Werken.

Der CIO, Frau Lehmann, hat sich Anfang 2026 vom Beirat den Auftrag geholt, die Cloud-Strategie ehrlich zu überprüfen. Auslöser war ein Cloud-Bill-Schock: Die monatliche AWS-Rechnung der IoT-Plattform war über 18 Monate von 14.000 auf 41.000 Euro gestiegen, ohne dass der zugrunde liegende Datendurchsatz proportional zugenommen hatte. Bei genauerem Hinsehen waren 62 Prozent der Kosten Egress, Cross-AZ-Traffic und Datenpersistenz in S3-Buckets, die längst eine Multi-Petabyte-Größe erreicht hatten – eine Zeitserie aus Sensordaten, die für Audit-Zwecke und Predictive Maintenance vorgehalten werden muss.

Frau Lehmann beauftragt eine Analyse, die nicht „Cloud ja oder nein" fragt, sondern die folgenden vier Fragen pro Workload beantworten soll:

Wie hoch ist die Vorhersagbarkeit der Last? Wie hoch ist die Datenmasse, die durch das System fließt oder darin gespeichert wird? Welche regulatorischen Anforderungen bestehen? Welche Souveränitätsanforderungen ergeben sich aus Geschäftsmodell und Kundenverträgen?

Das Ergebnis ist instruktiv. Microsoft 365 für Office-Arbeit bleibt unverändert in der Cloud – die Last ist diffus, die Datenmenge pro Nutzer überschaubar, der Lock-in akzeptiert. Das SAP-System wandert auf eine privat betriebene S/4HANA-Instanz auf eigener Hardware in einem deutschen Co-Location-Rechenzentrum, weil die Last extrem stabil ist (5 Jahre lineare Wachstumsprognose) und Datenresidenz für Audit-Zwecke vereinfachen soll. Die Engineering-Plattform mit CAD-Daten – früher in einer hybriden, aber mehrheitlich öffentlichen Variante betrieben – wandert vollständig auf eine eigene Kubernetes-Plattform mit MinIO-Objektspeicher, weil hier Datenmengen entstehen, die in der Public Cloud sechsstellig pro Monat kosten würden. Die IoT-Plattform wird geteilt: Die Stream-Verarbeitung am Werksrand bleibt edge-nah und cloudgestützt, die historische Datenhaltung wandert in den eigenen Petabyte-Speicher.

Das ist die zentrale Lehre der Brunner-Geschichte: Repatriation ist keine Architekturentscheidung – sie ist eine Workload-Entscheidung. Und sie wird nicht einmal fürs ganze Unternehmen getroffen, sondern für jeden einzelnen Workload separat.

Die ehrliche TCO-Rechnung

Der häufigste Fehler in Repatriation-Diskussionen ist eine vereinfachte Gegenüberstellung von „AWS pro Monat" gegen „eigener Server pro Monat". Eine seriöse Total-Cost-of-Ownership-Betrachtung muss mindestens neun Kostenpositionen umfassen, von denen mindestens vier in klassischen Cloud-Migrationsanalysen 2018–2021 systematisch unterschlagen wurden.

Auf der Cloud-Seite gehören dazu: Compute (Reserved und Spot), Storage in mehreren Klassen, Egress und Cross-Region-Traffic, Managed-Service-Aufschläge, Premium-Support, sowie die Personalkosten für Cloud-Architekten, FinOps-Spezialisten und Multi-Cloud-Tooling. Auf der eigenen Seite gehören dazu: Hardware-Abschreibung über 4–5 Jahre, Strom und Kühlung, Co-Location-Miete oder eigene RZ-Fläche, Netzanbindung mit Redundanz, Lifecycle-Management der Hardware sowie das gesamte Personal für Betrieb, Patch-Management, Backup und 24/7-Verfügbarkeit.

Wer beide Seiten ehrlich rechnet, kommt für Workloads mit hoher Vorhersagbarkeit und hoher Datenintensität typischerweise auf 30 bis 50 Prozent Einsparung in eigener Infrastruktur. Wer nur die Hardware kauft und das Personal vergisst, kommt zu einer scheinbaren Einsparung von 70 Prozent – und scheitert spätestens, wenn der erste GPU-Knoten 18 Monate nach Inbetriebnahme im Spätschicht-Backup ausfällt und niemand verfügbar ist, der das einschätzen kann.

Im Brunner-Szenario rechnet der CFO sechs Monate nach Migration vor: SAP auf eigener Hardware kostet rund 38 Prozent weniger als die vorherige IaaS-Lösung. Die CAD-Plattform liegt 51 Prozent unter den Cloud-Kosten. Die geteilte IoT-Plattform liegt nur 12 Prozent unter dem Vorzustand – der Vorteil entsteht hier weniger im Geld als in der Compliance-Vereinfachung, weil sensible Maschinendaten den Kunden gegenüber nun nachweislich in Deutschland verbleiben.

Die Souveränitätsfrage: Warum 2026 kein Jahr für Halbentscheidungen ist

Der zweite große Treiber neben Kosten ist digitale Souveränität. Diese Diskussion war lange diffus, in den letzten 18 Monaten ist sie konkreter geworden. Der EU AI Act etwa verlangt für Hochrisiko-KI-Systeme einen Auditpfad, der bei US-Hyperscalern technisch durchaus möglich, kontraktrechtlich aber regelmäßig Reibungspunkte erzeugt. NIS2 macht persönliche Geschäftsführungshaftung an die Beherrschbarkeit der eigenen IT fest. Sektorrecht für Energie, Gesundheit und Finanz schreibt zunehmend Datenstandorte und Backup-Strategien vor, die in einer reinen Public-Cloud-Lösung umständlich abzubilden sind.

Hinzu kommt eine geopolitische Komponente, die in CIO-Diskussionen offen ausgesprochen wird: Wer 2026 in Europa Industrieprodukte verkauft, bekommt von Großkunden zunehmend Fragen zu seiner Lieferkette der digitalen Infrastruktur. „Wo liegen Ihre Engineering-Daten?" ist im B2B-Geschäft eine Frage, die in Ausschreibungen erscheint. Eine Antwort wie „in einer EU-Region eines amerikanischen Anbieters" ist juristisch unproblematisch, kommerziell aber zunehmend ein Wettbewerbsnachteil.

Souveränität bedeutet nicht „Public Cloud raus". Es bedeutet, dass Unternehmen in der Lage sein müssen, kritische Workloads jederzeit zu portieren, ihre Datenflüsse vollständig zu beschreiben und ihre Schlüsselverwaltung selbst zu kontrollieren. Wer einen strukturierten Compliance- und Architektur-Prozess aufsetzt, kommt zu sinnvollen Antworten. Wer reflexartig „alles zurück" entscheidet, baut sich neue Abhängigkeiten – etwa von einem einzelnen deutschen Co-Location-Anbieter ohne Multi-Region-Konzept – und verschiebt das Souveränitätsproblem nur.

Die Architektur, die 2026 wirklich trägt

Wer Repatriation ernsthaft umsetzt, landet in nahezu allen Mittelstandsfällen bei einem dreistufigen Modell, das wir intern als „Souveräner Kern, hybrides Mittelfeld, opportunistische Cloud" bezeichnen.

Im souveränen Kern liegen die Workloads, die das Unternehmen aus regulatorischen, kommerziellen oder strategischen Gründen vollständig kontrollieren will. ERP, Konstruktionsdaten, Kunden-Stammdaten, KI-Trainingsdaten. Diese laufen auf eigener Hardware – entweder im eigenen Rechenzentrum oder in einer co-lokierten Umgebung mit dedizierten Racks. Plattformbasis ist meist ein selbst betriebenes Kubernetes-Cluster, ergänzt um Objektspeicher (MinIO, Ceph) und harte Verschlüsselungs- und Backup-Strategien.

Das hybride Mittelfeld umfasst Workloads, die teils in der Cloud laufen und teils nicht. Klassische Beispiele: ein E-Commerce-Frontend, das in der Public Cloud horizontal skaliert, gegen einen Produktkatalog spricht, der im souveränen Kern liegt. Oder eine KI-Inferenzschicht, die ihre Embeddings im eigenen Vector-Store hält, aber Anfragen weltweit von Cloud-Edge-Knoten entgegennimmt. Hier ist Architektur-Disziplin entscheidend, weil sich solche Systeme schnell zu unbeherrschbaren Spaghetti-Strukturen entwickeln, wenn sie nicht klar gekapselt werden. Wir begleiten solche Designs typischerweise mit harten Domain-Schnitten und API-Verträgen, die in unserer Softwareentwicklungs-Praxis systematisch verankert sind.

Die opportunistische Cloud ist alles, was sinnvoll dort bleibt: Microsoft 365 für Office-Workloads, ausgewählte SaaS-Lösungen für CRM oder Servicemanagement, dedizierte Cloud-Dienste für Lasten, die exotische Hardware oder weltweite Reichweite benötigen. Hier ist die Aufgabe nicht „weg davon", sondern bewusste, wirtschaftliche Nutzung mit klarer Exit-Strategie.

Was an Repatriation regelmäßig schiefgeht

Aus den Projekten, die wir 2025 und 2026 begleitet haben, wiederholen sich vier typische Fehler, die wir hier offen ansprechen wollen.

Erstens: Die Hardware wird vor dem Betriebskonzept gekauft. Wer einen sechsstelligen Hardware-Investitionsantrag durch den Vorstand bringt, hat oft das Gefühl, der schwere Teil sei erledigt. Ist er nicht. Der schwere Teil ist die Frage, wer das System ab Tag 1 betreibt, patcht, sichert, monitort und im Krisenfall um 03:42 Uhr morgens diagnostiziert. Repatriation ohne saubere Operations-Roadmap führt nach 12 bis 18 Monaten zur stillen Resignation.

Zweitens: Datenmigration wird unterschätzt. Drei Petabyte aus AWS S3 ins eigene Object-Storage zu schieben dauert je nach Anbindung Wochen, kostet Egress im fünfstelligen Bereich, erfordert Konsistenzkontrollen und fast immer eine Übergangsphase mit doppelter Datenhaltung. Wer das nicht in den Projektplan einrechnet, sprengt das Budget – nicht im Betrieb, sondern in der Migration.

Drittens: Cloud-native Vorteile werden auf der eigenen Plattform nicht repliziert. Eine eigene Kubernetes-Plattform ohne Selfservice für Entwicklungsteams, ohne Golden Paths für Deployment, ohne automatisiertes Provisioning ist eine teurere Version des on-prem-Stacks der 2010er. Erfolgreiches Platform Engineering ist 2026 das, was den Unterschied zwischen einem teuren Backup-RZ und einer echten internen Cloud-Plattform ausmacht. Wir flankieren solche Initiativen typischerweise mit klarem Projektmanagement, weil sie organisationsweite Veränderungen sind, nicht nur Infrastrukturthemen.

Viertens: Die KI-Strategie wird nachgelagert. Wer 2026 plant, in den nächsten 24 Monaten ernsthaft mit KI zu arbeiten – sei es interne Modelle, RAG-Systeme oder Agentenarchitekturen –, muss diese Anforderungen in das Repatriation-Design einbauen. GPUs, Vektordatenbanken, Modell-Hosting und Trainings-Pipelines bestimmen Hardware-Auswahl, Netzwerkarchitektur und Storage-Topologie maßgeblich. Wer eine reine „Klassik-IT-Plattform" zurückholt und ein Jahr später feststellt, dass darauf keine ernsthafte KI-Last passt, hat doppelt investiert. Eine integrierte Sicht haben wir in unserer Beratung zur KI-Strategie und -Integration beschrieben.

Handlungsempfehlungen für die nächsten 90 Tage

Wer das Thema Repatriation 2026 strukturiert angehen will, kann sich an einem dreimonatigen Sprint orientieren, der unabhängig vom konkreten Ergebnis Klarheit schafft.

In den ersten 30 Tagen geht es um Inventarisierung und Klassifikation: Welche Workloads existieren, wie hoch ist die Lastvorhersagbarkeit, wie groß sind die Datenmengen, welche regulatorischen Bindungen bestehen, welche Souveränitätsanforderungen ergeben sich aus Kundenverträgen? Das Ergebnis ist ein Workload-Portfolio mit klarer Bewertung pro Achse.

In den Tagen 30 bis 60 folgt die ehrliche TCO- und Risikoanalyse: Pro relevantem Workload werden mindestens drei Architekturoptionen durchgerechnet – „Status quo Cloud", „Repatriation in eigene Infrastruktur", „Hybrid mit klarer Schnittstelle". Die Rechnung muss alle neun TCO-Positionen enthalten und ein Risikoblatt pro Option mit operativer, regulatorischer und strategischer Sicht.

In den Tagen 60 bis 90 geht es um Strategie und Governance: Welche Workloads werden in welcher Reihenfolge migriert, wer betreibt sie, welche organisatorischen Konsequenzen ergeben sich, welche Verträge müssen ausgehandelt werden? Am Ende dieses Sprints liegt ein Vorstands-fähiges Papier vor, das die nächsten 18 bis 24 Monate strukturiert.

Ausblick: Was 2027 wahrscheinlich entscheiden wird

Drei Entwicklungen werden den Repatriation-Diskurs in den nächsten 12 bis 18 Monaten prägen. Erstens das Inkrafttreten des EU Data Act zum 12. Januar 2027, das Egress-Pauschalen verbietet und damit eine zentrale Cloud-Lock-in-Mechanik schwächt. Zweitens die zunehmende Verfügbarkeit europäischer souveräner Cloud-Angebote, die zwischen Hyperscaler-Komfort und vollständiger Eigenverwaltung positionieren. Drittens die KI-Realität: Die kommenden 24 Monate werden zeigen, ob die GPU-Knappheit bei Hyperscalern bestehen bleibt – und damit, ob KI-Workloads strukturell besser in eigener Hardware aufgehoben sind.

Was sicher gilt: Cloud-First als Reflex ist 2026 keine sinnvolle Strategie mehr. Cloud-Out als Reflex auch nicht. Wer im Mittelstand jetzt sauber inventarisiert, ehrlich rechnet und sich von Architektur-Disziplin statt von Trends leiten lässt, hat in zwei Jahren eine Infrastruktur, die zur Geschäftsstrategie passt – und nicht umgekehrt.

Wenn Sie diese Einordnung für Ihr Unternehmen konkret machen möchten, sprechen Sie uns an. Wir begleiten Mittelstandskunden bei genau diesen Fragen – von der Workload-Klassifikation über die TCO-Bewertung bis zur Migration. Den ersten Termin vereinbaren Sie über unser Kontaktformular.