Cloud-Repatriation: Warum Unternehmen wieder on-prem ziehen

“Cloud first” war zwischen 2015 und 2022 die dominante IT-Strategie-Empfehlung im KMU-Markt. Seit etwa 2024 hat sich der Wind gedreht: Cloud bleibt wichtig, aber selektiv, und immer mehr Unternehmen ziehen einzelne Workloads zurück on-prem. Der Begriff dafür ist Cloud-Repatriation — und das ist kein Marketing-Schlagwort, sondern eine reale Entscheidung in vielen IT-Strategie-Runden.

Dieser Artikel ordnet ein: Was treibt die Repatriation, wann lohnt sich der Schritt, wann nicht, und welche Architekturen sind heute typisch. Wir verzichten bewusst auf erfundene Prozentzahlen — wer öffentliche Studien zitieren will, findet bei Gartner, IDC oder 451 Research entsprechende Veröffentlichungen.

Die vier Haupttreiber

Aus DATAZONE-Beratungspraxis, in der Reihenfolge der Häufigkeit:

1. Egress-Kosten höher als erwartet

Das ist der häufigste Auslöser. Bei der Cloud-Migration waren die monatlichen Storage- und Compute-Kosten kalkulierbar — was viele unterschätzt haben, sind die Egress-Kosten für Datentransfer aus der Cloud heraus.

Klassische Beispiele:

• Backup-Restore aus der Cloud: kleine monatliche Speicherkosten, aber im Recovery-Fall fallen mehrere Terabyte Egress an — und das ist plötzlich vierstellig.
• Daten-Analyse: BI-Tools, die regelmäßig große Datensätze aus Cloud-Storage in eigene Compute-Umgebungen ziehen.
• Multi-Cloud-Setups: Datenfluss zwischen verschiedenen Cloud-Anbietern kostet Egress auf beiden Seiten.
• Hybrid-Architekturen: Workloads, die zwischen Cloud und on-prem synchronisieren, produzieren laufenden Egress.

Die Hyperscaler haben die Egress-Preise zwar inzwischen teilweise reduziert (AWS, Google, Azure haben 2024/2025 entsprechende Anpassungen kommuniziert), aber das Grundproblem bleibt: stabile, predictable Egress-Kosten sind in Public Cloud schwer planbar, und genau das ist es, was CFOs nicht mögen.

2. Compliance und Datensouveränität

Mit NIS2, CER, DSGVO-Verschärfungen und der allgemeinen EU-Souveränitäts-Debatte ist die Frage “wo liegen unsere Daten physisch” wieder wichtig geworden.

Konkrete Anforderungen, die wir aus Beratungen kennen:

• Branchenregulierung (Finanzdienstleister, Gesundheit, kritische Infrastruktur) — manche Branchen haben explizite Vorgaben zu Datenstandort
• DSGVO-Stand-der-Technik und Schrems-II-Sensibilität bei US-Hyperscalern
• Behördliche Anforderungen an Datenstandort bei öffentlichen Aufträgen
• Kunden-Anforderungen in Branchen, in denen Datensouveränität ein Verkaufsargument ist (z.B. Maschinenbau mit IP-sensitiven Daten)

EU-Cloud-Anbieter (OVH, Ionos, Hetzner, Stack, Open Telekom Cloud) reduzieren das Problem nicht ganz, aber sie sind eine pragmatische Mittelposition. Wer maximale Souveränität will, geht on-prem.

3. Predictable Performance vs. Noisy Neighbor

In der Public Cloud ist Compute-Performance immer relativ — die VM teilt sich Host-Ressourcen mit anderen Tenants. Für die meisten Workloads ist das kein Problem; für latenz-sensitive Workloads sehr wohl.

Typische Beispiele aus Beratungspraxis:

• Datenbank-Workloads mit hoher IOPS-Anforderung — in Cloud-DB-Services teuer, on-prem mit ZFS-Hybrid-Pool budgetfreundlich
• CAD/BIM/Video-Rendering — Latenz-empfindlich, Cloud-Workstations ja, aber bei intensiver Nutzung wird’s teuer
• VoIP/Realtime-Communication — Round-Trip-Zeiten wollen klein sein
• Industrielle Steuerung — Latenz und Verfügbarkeit dominieren

On-prem mit ordentlicher Hardware liefert predictable Performance, weil keine Tenant-Konkurrenz existiert. Das ist nicht “Cloud ist schlecht”, das ist “die Architekturen haben unterschiedliche Stärken”.

4. Hybrid-Modelle gewinnen

Das ist weniger “Repatriation” als “Korrektur der All-or-Nothing-Strategie aus den frühen 2020ern”. Statt alles on-prem oder alles in der Cloud sehen wir zunehmend hybride Setups:

• Kritische Stamm-Workloads on-prem (ERP, Mail, Fileserver, Datenbanken)
• Burst-Workloads in der Cloud (saisonale Spitzen, ML-Training, Renderfarms)
• Backup-Replikation in die Cloud als Off-Site-Layer
• Disaster-Recovery-Site in der Cloud, normalerweise inaktiv

Das ist nicht “Cloud weg” — das ist “Cloud da, wo sie spielt”.

Wann lohnt sich Repatriation?

Aus Beratungspraxis: in folgenden Konstellationen rechnen wir Kunden eine Repatriation-Wirtschaftlichkeit vor.

Repatriation lohnt sich häufig:

• Stabile Workloads mit hoher Auslastung (24/7-ERP-Datenbanken, Mail-Server, Fileserver) — Cloud-Compute zahlt sich nur bei Variabilität aus. Stetige Last on-prem ist meistens günstiger.
• Egress-Heavy-Anwendungen — wenn die Workload viel Daten “rauspustet”, wird Cloud teuer.
• Storage-Lastige Setups mit langfristiger Archivierung — TrueNAS + Off-Site-Replikation schlägt Cloud-Storage über 5+ Jahre wirtschaftlich.
• Regulierte Branchen mit harten Datenstandort-Vorgaben.
• Workloads mit predictable Performance-Anforderung (Datenbanken, BI, CAD).
• Wenn IT-Team verfügbar ist — on-prem ist nicht “selbst-wartend”.

Repatriation lohnt sich selten:

• Spike-Traffic-Anwendungen (Web-Shops mit Saison, ML-Training-Burst) — Cloud-Elastizität ist hier ein echter Vorteil
• Kurzlebige Projekte (Pilots, MVP-Entwicklung) — der CapEx-Aufwand für on-prem rechnet sich nicht
• Globale, geo-verteilte Anwendungen — Cloud-CDN und Multi-Region sind komplex on-prem nachzubauen
• Kleinst-Workloads unter ein paar TB Storage / ein paar Cores Compute — die Hardware-Investitionsschwelle macht es nicht wirtschaftlich
• Wenn kein IT-Team da ist, das die on-prem-Infrastruktur betreut — Outsourcing/Managed-Service nochmal evaluieren

Drei typische Szenarien

Szenario 1: Mittelständischer Maschinenbauer (250 MA)

• Vorher: ERP in der Cloud, CAD-Daten in OneDrive für Business, VMs in AWS
• Treiber: Steigende Cloud-Kosten (vor allem Egress bei CAD-Datentransfer), Datenhoheit für Konstruktionsdaten
• Nachher: ERP auf Proxmox-Cluster on-prem, CAD-Daten auf TrueNAS H20 lokal mit Cloud-Replikation als Backup, AWS für gelegentliche Bauteilsimulationen (kurzer Compute-Burst)
• Resultat: Stetige Workload-Kosten gesenkt, Performance besser planbar, Compliance-Position verbessert

Szenario 2: Architekturbüro (15 MA)

• Vorher: Dropbox Business als zentraler Speicher, Microsoft 365 für Office, individuelle Workstations
• Treiber: Synchronisations-Probleme bei großen Revit-Modellen, DSGVO bei Bauherren-Daten, lokale Performance
• Nachher: TrueNAS H20 als zentraler Storage on-prem (siehe Architektur-Setup-Artikel), Microsoft 365 bleibt für Mail und Office, Backup-Replikation in Cloud
• Resultat: Großdatei-Workflows sauber, Versionierung via Snapshots, Cloud bleibt für das, wo sie hilft (Mail)

Szenario 3: Anwaltskanzlei (40 MA)

• Vorher: Alles in Office 365, Mandanten-Daten in SharePoint, Backup in Veeam Cloud Connect
• Treiber: DSGVO/Mandantenvertraulichkeit, US-Hyperscaler-Sensibilität, Anwaltskammer-Empfehlungen
• Nachher: On-prem Mailcow statt Exchange Online, Nextcloud Hub für Office und Dokumente, TrueNAS H20 + Backup auf EU-Cloud
• Resultat: Vollständige Datenkontrolle, geringe laufende Lizenzkosten, Compliance-Position deutlich verbessert

Diese drei Szenarien sind nicht “Cloud schlecht, on-prem gut” — sie sind “die Architektur muss zur Last passen”.

TrueNAS und Proxmox als typische on-prem-Bausteine

Für die Mehrheit der von uns betreuten Repatriation-Projekte sind zwei Bausteine zentral:

TrueNAS für Storage

• Storage-Konsolidierung: ein zentraler ZFS-Pool ersetzt verstreute Cloud-Storage-Accounts
• Snapshots als integrierter Versionierungs-Layer
• Replikation in eine zweite Site oder Cloud als Backup-Layer
• SMB/NFS/iSCSI/NVMe-TCP für alle gängigen Workloads
• Skalierbar von 20 TB (Mini X+) bis 30 PB (M60)

Proxmox VE für Virtualisierung und Container

• Vollwertiger Hypervisor als VMware-Alternative
• LXC-Container für leichtgewichtige Linux-Workloads
• HA-Cluster mit Live-Migration
• Open Source mit kommerzieller Subscription — kein Lock-in
• Integration mit TrueNAS als Storage-Layer

Die beiden zusammen ergeben einen on-prem-Stack, der für die meisten KMU-Workloads ausreichend ist — und der bei vernünftiger Hardware deutlich günstiger zu betreiben ist als gleichwertige Cloud-Ressourcen über 3-5 Jahre.

Wirtschaftlichkeit — ohne erfundene Zahlen

Eine ehrliche TCO-Rechnung ist die einzige Basis, auf der man Cloud vs. on-prem fair vergleicht. Ein paar Faktoren, die in jede Rechnung gehören:

On-prem CapEx:

• Hardware (Server, Storage, Switches, USV)
• Lizenzen (TrueNAS Enterprise, Proxmox Subscription, Backup-Software)
• Installations- und Migrationsdienstleistung
• Räumlichkeit/Klima (oft schon vorhanden)

On-prem OpEx:

• Strom (deutliche Komponente, siehe Energiekosten-Artikel)
• Wartung und Support
• IT-Personal-Aufwand
• Hardware-Refresh-Rücklage (jährliche Abschreibung mit Plan für 5-7 Jahre)

Cloud OpEx:

• Compute-Verbrauch
• Storage-Belegung
• Egress (häufig unterschätzt)
• Lizenz-Aufschläge (z.B. bei Microsoft 365)
• Backup-Storage extra

Die Vergleichsrechnung über 3 und 5 Jahre macht den Unterschied sichtbar. Für viele unserer Kunden ergibt die ehrliche TCO-Rechnung: on-prem ab Jahr 2-3 wirtschaftlicher, vor allem bei stabilen Workloads.

Migrations-Pfad: Schritt für Schritt

Cloud-Repatriation ist keine “Big-Bang”-Operation. Bewährter Pfad:

1. Workload-Inventur: Was läuft wo? Welche Datenmenge, welche Last?
2. Kategorisierung: stabile vs. variable Workloads, regulierungs-relevant ja/nein
3. Pilot-Migration: Ein nicht-kritischer Workload first, on-prem-Setup als Lerngegenstand
4. Schrittweise Migration: pro Quartal eine Workload-Klasse, parallel zur Cloud-Nutzung
5. Cloud-Reduzierung: am Ende bleiben die Cloud-Workloads übrig, die dort wirklich besser laufen

Das dauert typisch 6-18 Monate für KMU mit mehreren Cloud-Workloads. Schneller geht es nur bei sehr fokussiertem Migrations-Druck.

Stolpersteine — was schief gehen kann

• Unterschätzte Komplexität bei Identity: Wer von Azure AD weg will, muss Ersatz-IdP planen (Authentik, FreeIPA, Samba AD)
• Unterschätzter Personalaufwand: on-prem ist nicht “selbst-wartend”
• Migrations-Egress: ironischerweise produziert der Cloud-Exit selbst hohe Egress-Kosten
• Lizenz-Übergangs-Doppelkosten: einige Monate parallele Lizenzen während Migration
• Recovery-Pfad: das alte Cloud-Setup muss noch X Monate verfügbar bleiben

DATAZONE-Empfehlung

Cloud-Repatriation ist kein “zurück in die Vergangenheit” — es ist eine Architektur-Korrektur, in der jede Workload dorthin kommt, wo sie wirtschaftlich, performant und compliant am besten liegt. Für die meisten Mittelständler heißt das: hybrid, mit klarer Trennung.

Wenn Sie als Mittelständler eine ehrliche TCO-Vergleichsrechnung für einen Workload brauchen — das ist ein typischer Beratungs-Auftrag bei uns. Wir gehen ohne Vendor-Lock-Interesse rein, vergleichen Cloud-Setup (auch EU-Cloud) gegen on-prem-Setup (TrueNAS + Proxmox) und liefern eine 3- und 5-Jahres-Rechnung. Das Ergebnis ist nicht immer “on-prem ist günstiger” — aber es ist immer eine Entscheidung auf Datenbasis.

Quellen und weiterführende Artikel

• VMware Lizenzkosten 2026 für KMU — VMware-Wechsel-Aspekt der Repatriation
• VMware Broadcom Proxmox Alternative — Hypervisor-Migration
• Proxmox 3-Node-Cluster mit TrueNAS H20 — typische on-prem-Architektur
• TrueNAS für Architekturbüros — branchenbezogenes Repatriation-Beispiel
• Microsoft Exchange ablösen — ROI für KMU — Mail-Aspekt
• Nextcloud Hub Office-Alternative on-prem — Office-Aspekt
• Self-Hosting vs. Microsoft 365 — strategischer Vergleich
• Cloud-Backup-Anbieter im Vergleich — Cloud-Layer in Hybrid-Setups
• Energiekosten Serverraum Stellschrauben — on-prem-OpEx-Aspekt

Wer eine konkrete Repatriation-Analyse machen will: gerne Workshop vereinbaren — wir bringen die TCO-Vorlagen mit.