Cloud-Migration Schritt für Schritt — Praxis-Leitfaden für den Mittelstand 2026

Eine Cloud-Migration ist 2026 selten noch eine reine Infrastruktur-Übung — sie ist ein mehrjähriges Vorhaben mit unmittelbarer Wirkung auf Kosten, Lieferfähigkeit, Compliance und Personal. Im deutschen Mittelstand laufen aktuell zwei parallele Bewegungen: Unternehmen, die bisher zögerten, geraten durch auslaufende Hardware-Verträge, Energiekosten und Fachkräftemangel in eine Migrations-Pflicht. Unternehmen, die bereits Workloads in der Cloud haben, müssen ihre erste Generation Architekturen modernisieren, weil die Lift-and-Shift-Welle der Jahre 2019 bis 2022 inzwischen Kosten produziert, die nicht mehr tragbar sind. Beide Gruppen brauchen einen klaren, methodischen Fahrplan — keine Beratungs-Folie, sondern einen Plan, der Assessment, Tooling, Datenmigration, Cutover und Roll-back konkret beantwortet. Dieser Leitfaden fasst zusammen, wie ein solches Vorhaben mit realistischem Aufwand gelingt, welche Werkzeuge bei AWS, Azure und GCP eingesetzt werden, welche Strategien die 6-Rs-Matrix kennt und mit welchen Kostenrahmen Sie rechnen sollten. Für die Einordnung in die übergreifende Strategie siehe unseren Cloud-&-DevOps-Guide für den Mittelstand.

Warum Migration 2026 anders aussieht — Bußgeld, Haftung, Kosten

Die Cloud-Migration des Jahres 2026 unterscheidet sich von der ersten Welle vor sechs Jahren fundamental. Die treibenden Faktoren sind nicht mehr Innovation und Skalierbarkeit allein, sondern eine Mischung aus regulatorischem Druck, betriebswirtschaftlicher Notwendigkeit und Personalknappheit. Der EU Data Act, NIS2, DORA für Finanzdienstleister und die deutsche KRITIS-Regulierung verlangen heute dokumentierte Ausfallsicherheit, Auditierbarkeit und souveräne Daten­speicherung — Anforderungen, die in klassischen On-Premise-Rechenzentren zwar erfüllbar, aber teuer und personalintensiv sind. Gleichzeitig haben Strompreise und Hardware-Lieferzeiten den TCO von eigenen Rechenzentren spürbar erhöht.

Drei Beobachtungen aus aktuellen Projekten im deutschen Mittelstand prägen die Migrations-Realität 2026. Erstens: reine Lift-and-Shift-Migrationen sind aus der Mode — die Kostenfalle „On-Premise mit Cloud-Aufschlag“ ist inzwischen bekannt, Unternehmen verlangen direkt einen Re-Platform-Anteil. Zweitens: Souveränitäts-Anforderungen sind kein Nischen-Thema mehr — auch mittelständische Kunden fragen nach EU-Regionen, Sovereign-Cloud-Angeboten und Verschlüsselungs-Optionen mit Customer-Managed Keys. Drittens: der Personalmangel zwingt zu mehr Managed Services — wer als Mittelständler keine Datenbank-Administration mehr besetzen kann, wechselt aus Notwendigkeit zu RDS, Azure SQL oder Cloud SQL.

Diese drei Treiber verändern die Reihenfolge der Migrations-Entscheidungen. Die Frage ist seltener „Was migrieren wir zuerst“ und häufiger „Welche Workloads behalten wir auf welcher Stufe der Eigenverantwortung“. Das macht das 6-Rs-Modell und ein sauberes Assessment so wichtig wie nie zuvor.

Assessment-Phase: Application-Discovery, Dependency-Mapping, Compliance-Check

Jede Cloud-Migration steht und fällt mit dem Assessment. In unseren Projekten verbringen wir 15 bis 25 Prozent der gesamten Projektzeit in dieser Phase — und sparen damit später ein Vielfaches an Nacharbeit. Ein belastbares Assessment besteht aus drei Bausteinen, die parallel laufen sollten:

• Application-DiscoveryInventarisierung aller laufenden Anwendungen, ihrer Versions-Stände, Betriebssysteme, Datenbanken, Middleware und Lizenz-Modelle. Werkzeuge wie AWS Application Discovery Service, Azure Migrate Discovery oder GCP Migration Center sammeln automatisiert technische Metriken — CPU, RAM, IOPS, Netzwerk — über 30 bis 60 Tage. Diese Daten sind die Grundlage für Right-Sizing und Kostenkalkulation.
• Dependency-MappingErfassung der Abhängigkeiten zwischen Anwendungen, Datenbanken, Schnittstellen und externen Diensten. Häufig die wichtigste und am stärksten unterschätzte Aufgabe — kaum ein Mittelständler hat eine vollständige Karte seiner Integrationen. Tools wie ServiceNow Discovery, Device42 oder die Mapping-Funktionen von Azure Migrate liefern eine Basis, die durch Interviews mit Fachabteilungen ergänzt werden muss.
• Compliance-CheckBewertung jeder Anwendung gegen rechtliche und vertragliche Anforderungen: DSGVO-Datenkategorien, branchenspezifische Vorgaben (BAIT, VAIT, KRITIS), Vertragsklauseln mit Kunden zur Daten-Lokalisierung, Software-Lizenzen mit Cloud-Restriktionen. Das Ergebnis ist eine Matrix, die pro Anwendung sagt, in welcher Region und auf welchem Service-Modell sie betrieben werden darf.

Ein häufiger Fehler: das Assessment wird nur technisch geführt, ohne Fachbereiche und Einkauf. Eine Anwendung kann technisch perfekt migrierbar sein, aber wenn die Lizenz eines Software-Herstellers den Cloud-Betrieb mit Aufpreis belegt oder verbietet, ist die Migration wirtschaftlich tot. Solche Erkenntnisse müssen im Assessment auftauchen, nicht erst im Cutover.

Die 6 Rs — Entscheidungsmatrix für jede Anwendung

Das von AWS und Gartner geprägte 6-Rs-Modell ist 2026 weiter der Standard, um pro Anwendung die richtige Migrations-Strategie zu wählen. Wichtig ist die Erkenntnis: jede Strategie hat ihren legitimen Platz — ein Portfolio mit 100 Prozent Refactor ist genauso falsch wie eines mit 100 Prozent Rehost.

Strategie	Was passiert	Aufwand	Wann sinnvoll
Rehost (Lift & Shift)	VM 1:1 in die Cloud umziehen, kein Code-Eingriff	Niedrig	Schnelle Datacenter-Räumung, stabile Legacy-Anwendungen ohne Skalierungsbedarf
Replatform	Kleine Anpassungen, z. B. Wechsel auf Managed Datenbank oder Container	Mittel	Wenn Personal-Aufwand für DB-Admin oder OS-Patching wegfallen soll
Repurchase	Wechsel auf SaaS-Lösung, alter Stack wird stillgelegt	Mittel-Hoch	CRM, HR, Buchhaltung, Mail — überall wo Standard-SaaS funktioniert
Refactor / Re-architect	Anwendung wird zerlegt und Cloud-nativ neu gebaut (Microservices, Serverless)	Hoch	Geschäftskritische Eigenentwicklungen mit langfristigem Skalierungsbedarf
Retire	Anwendung wird abgeschaltet, nicht migriert	Niedrig	End-of-Life-Anwendungen, redundante Tools, „dead apps" mit nur 1–2 Nutzern
Retain	Anwendung bleibt On-Premise oder im alten Rechenzentrum	Niedrig	OT-Systeme, Lizenz-Sperren, sehr datenintensive Batch-Jobs

Eine bewährte Verteilung für mittelständische Portfolios sieht typischerweise so aus: 35 bis 50 Prozent Rehost, 20 bis 30 Prozent Replatform, 10 bis 15 Prozent Repurchase, 5 bis 10 Prozent Refactor, 5 bis 10 Prozent Retire, 5 bis 10 Prozent Retain. Die genaue Verteilung hängt vom Anwendungs-Alter, dem Maß an Standardisierung und der Verfügbarkeit interner Entwicklungs-Kapazität ab.

Tool-Stack — AWS MGN, Azure Migrate, GCP Migrate, CloudEndure

Für die operative Durchführung stellen die drei Hyperscaler ausgereifte, kostengünstige Migrations-Werkzeuge bereit. Sie sind heute deutlich reifer als noch vor drei Jahren und für mittelständische Projekte meist ausreichend ohne externe Spezial-Tools.

• AWS Application Migration Service (MGN) — Nachfolger von CloudEndure, repliziert laufende Server kontinuierlich in eine AWS-Region und ermöglicht Cutover binnen Minuten. Quasi-Standard für Rehost-Migrationen nach AWS, deutschsprachiger Support, kostengünstig pro Server pro Stunde.
• Azure Migrate — integrierte Suite mit Discovery, Assessment, Server- und Datenbank-Migration. Besonders stark bei Windows- und SQL-Server-Workloads, native Integration mit Azure Arc für Hybrid-Setups.
• Google Cloud Migration Center und Migrate to Virtual Machines — schlankere Lösung als die AWS- und Azure-Pendants, in DACH-Mittelstands-Projekten seltener gesehen, aber bei Container-zentrierten Migrationen eine ernste Option.
• CloudEndure — die ursprüngliche Engine, heute Teil von AWS MGN und Disaster Recovery — für Cross-Cloud-Migrationen oder als DR-Service weiterhin relevant.
• Carbonite Migrate, Zerto, Veeam — Drittanbieter-Werkzeuge, sinnvoll bei sehr heterogenen Landschaften oder wenn bereits eine Lizenz aus dem DR-Kontext besteht.

Empfehlung aus der Praxis: für ein mittelständisches Vorhaben mit klarer Hyperscaler-Wahl sind die nativen Tools des Ziel-Anbieters fast immer ausreichend. Drittanbieter lohnen sich erst bei mehreren parallelen Zielen, exotischen Quellen (AS/400, Mainframe) oder wenn Disaster Recovery in einem Schritt mitgelöst werden soll.

Datenmigration — Storage Gateway, DataSync, Database Migration Service

Die Datenmigration ist der heikelste Teil jeder Cloud-Bewegung. Sie entscheidet über Cutover-Fenster, Konsistenz und Roll-back-Fähigkeit. Für strukturierte und unstrukturierte Daten gelten unterschiedliche Werkzeug-Klassen.

Unstrukturierte Daten (Dateifreigaben, Archive, Backups). Hier dominieren synchronisierende Werkzeuge. AWS DataSync und Azure File Sync übertragen kontinuierlich, mit Bandbreiten-Drosselung, Verschlüsselung und Delta-Synchronisation. AWS Storage Gateway und Azure StorSimple bieten zusätzlich eine On-Premise-Cache-Schicht, sinnvoll wenn Cutover gestaffelt ablaufen soll. Für sehr große Volumina (mehr als 50 TB) sind physische Transport-Geräte (AWS Snowball, Azure Data Box) günstiger als reine Netzwerk-Übertragung.

Strukturierte Daten (Datenbanken). Hier sind die Migrations-Services der Hyperscaler erste Wahl. AWS Database Migration Service (DMS), Azure Database Migration Service und GCP Database Migration Service unterstützen heterogene Migrationen — etwa Oracle nach PostgreSQL oder SQL Server nach Aurora — und bieten Change-Data-Capture für nahezu unterbrechungsfreie Cutover. Bei homogenen Migrationen (SQL Server nach Azure SQL, MySQL nach RDS MySQL) ist die Kombination aus DMS und nativen Replikations-Mechanismen am robustesten.

Drei Empfehlungen aus der Praxis: erstens immer mit einem Daten-Probelauf in einer Test-Umgebung beginnen, der mindestens 7 Tage Change-Data-Capture umfasst, weil viele Konflikte erst über die Zeit sichtbar werden. Zweitens die Netzwerk-Bandbreite für die Initial-Übertragung früh prüfen — ein 10-TB-Datenbank-Initial-Load über 100-MBit-Anbindung dauert physikalisch mehrere Tage. Drittens immer das Cutover-Fenster mit dem Fachbereich vereinbaren und nicht aus IT-Sicht setzen — Buchhalterische Periodenwechsel oder Quartals-Closings sind harte Tabu-Zonen.

Netzwerk-Setup — VPC, Hybrid-Connectivity, Direct Connect, ExpressRoute

Das Netzwerk ist das Skelett jeder Cloud-Migration, und es muss vor dem ersten Server-Cutover stehen. Drei Ebenen sind zu planen.

Cloud-interne Segmentierung. AWS VPC, Azure VNet oder GCP VPC sind die Basis-Container für alle Cloud-Ressourcen. Eine sinnvolle Segmentierung trennt Produktion, Test und Entwicklung in eigene VPCs oder Subscription-Strukturen, mit dedizierten Subnetzen für Public-, Private- und Datenbank-Schichten. Transit-Gateway (AWS), Virtual WAN (Azure) oder Network Connectivity Center (GCP) bündeln das Routing zwischen mehreren VPCs und der Außenwelt.

Hybrid-Konnektivität in der Migrations-Phase. Während der Migration läuft On-Premise und Cloud parallel — und brauchen eine zuverlässige Verbindung. Site-to-Site-VPN ist der schnelle, kostengünstige Einstieg (typisch 100 bis 500 MBit), reicht aber für große Datenmigrations-Volumina selten aus. Dedicated Lines wie AWS Direct Connect, Azure ExpressRoute oder GCP Partner Interconnect bieten 1 bis 10 Gbit, niedrigere Latenz und stabilere SLA — bei monatlichen Kosten zwischen 500 und 3.000 Euro je nach Bandbreite und Carrier.

DNS, Identität, Zertifikate. Eine konsistente DNS-Struktur über Cloud und On-Premise (Route 53 Resolver, Azure Private DNS Zones), die Anbindung der bestehenden Identität (AD Connect, Azure AD-DS, IAM Identity Center) und ein einheitliches Zertifikats-Management gehören in dieselbe Planung. Diese drei Themen werden in der Migrations-Planung oft unterschätzt und produzieren spätere Reibung.

Cutover-Strategien — Big Bang, Wave, Strangler

Drei Cutover-Muster haben sich etabliert. Die Auswahl hängt von Risiko-Toleranz, Anwendungs-Kopplung und verfügbarem Wartungsfenster ab.

• Big-Bang-Cutover — die gesamte Landschaft wird in einem definierten Wochenend-Fenster umgeschaltet. Einfach in der Planung, hoch im Risiko. Sinnvoll nur bei sehr kleinen Landschaften (unter 10 Anwendungen) oder wenn ein abruptes Rechenzentrums-Ende den Zeitplan diktiert.
• Wave-Migration — Anwendungen werden in Wellen zu je 5 bis 20 Einheiten migriert, jeweils mit eigenem Cutover-Wochenende. Standard für mittelständische Projekte, weil das Risiko pro Welle handhabbar bleibt und Lernen zwischen den Wellen einfließt. Typische Wave-Dauer: 4 bis 8 Wochen.
• Strangler-Pattern — alte Anwendung läuft parallel weiter, neue Cloud-Anwendung übernimmt schrittweise Funktionen, bis die alte komplett ersetzt ist. Sinnvoll bei großen Eigenentwicklungen, die im Zuge der Migration refaktoriert werden. Aufwendig, aber risiko-arm.

Empfehlung: ein Mittelständler mit 40 bis 80 Anwendungen fährt mit einer Wave-Migration über 4 bis 6 Wellen am sichersten. Die erste Welle sollte bewusst kleine, unkritische Anwendungen enthalten, um Prozess und Tooling zu testen, bevor die geschäftskritischen Workloads dran sind.

Risiken und Roll-back-Plan

Die häufigsten Risiken in Cloud-Migrations-Projekten sind nicht technischer, sondern organisatorischer Natur. Fünf wiederkehrende Muster:

• Unvollständige DiscoveryVergessene Schnittstellen oder Schatten-IT taucht erst beim Cutover auf. Gegenmaßnahme: Discovery mindestens 60 Tage, plus Workshops mit allen Fachabteilungen.
• Personal- und Skill-LückeDas Migrations-Team hat zu wenig Cloud-Praxis. Gegenmaßnahme: externe Begleitung in den ersten 2 Wellen, parallele Schulung interner Mitarbeitender mit Hyperscaler-Zertifizierungen.
• Unklare VerantwortlichkeitenFachabteilungen wissen nicht, wann sie testen müssen. Gegenmaßnahme: pro Anwendung benannter Business Owner mit klarer Testaufgabe vor jedem Cutover.
• Fehlende Kosten-SteuerungRechnungen explodieren, weil Right-Sizing ausgeblieben ist. Gegenmaßnahme: FinOps-Verantwortliche ab Tag 1 und monatliche Kosten-Reviews. Mehr dazu in unserem Beitrag Cloud-Kosten und FinOps.
• Kein belastbarer Roll-back-PlanWenn etwas schiefläuft, fehlt der Weg zurück. Gegenmaßnahme: pro Welle dokumentierter Roll-back-Plan, mindestens einmal in der Test-Umgebung durchgespielt.

Ein realistischer Roll-back-Plan hat drei Säulen: erstens läuft das Quellsystem im Read-Only-Modus für 7 bis 14 Tage nach Cutover weiter. Zweitens ist die DNS-Umstellung mit kurzen TTL-Werten (60 Sekunden) so vorbereitet, dass der Schwenk zurück binnen Minuten möglich ist. Drittens existiert eine getestete Datenbank-Rück­synchronisation, die in der Test-Umgebung mindestens einmal durchgelaufen ist. Ein Roll-back-Plan, der diese drei Punkte nicht erfüllt, ist ein Dokument, kein Plan.

Kosten-Beispiele Mittelstand

Die Frage „Was kostet eine Cloud-Migration“ ist seriös nur in Spannen zu beantworten. Drei typische Profile zeigen die Größenordnung — die Zahlen verstehen sich als Orientierung für mittelständische Vorhaben in Deutschland.

Profil	Apps / Server	Projekt-Dauer	Externe Kosten	Interner Aufwand
Kleines Vorhaben (Rehost-lastig)	15–30 Apps / 40–80 Server	6–9 Monate	80.000–180.000 €	1–2 Vollzeit-Äquivalente
Standard-Mittelstand (Mix)	30–80 Apps / 100–250 Server	9–15 Monate	200.000–500.000 €	2–4 Vollzeit-Äquivalente
Großer Mittelstand (mit Refactor)	80–200 Apps / 250–600 Server	15–24 Monate	500.000–1.500.000 €	4–8 Vollzeit-Äquivalente

Hinzu kommen die laufenden Cloud-Kosten nach Cutover — bei einem Standard-Mittelstand typischerweise 8.000 bis 25.000 Euro pro Monat in den ersten 12 Monaten, danach mit Right-Sizing und Reserved-Instances oft um 25 bis 40 Prozent reduzierbar. Die Wirtschaftlichkeit ergibt sich selten aus reinen Infrastruktur-Einsparungen, sondern aus weggefallenem Personal-Aufwand, schnellerer Bereitstellung neuer Umgebungen und reduzierter Ausfallzeit.

Reepa-Migrations-Ansatz

Wir begleiten mittelständische Cloud-Migrationen in vier definierten Stufen, die sich in Projekten bewährt haben. Stufe 1 ist ein vierwöchiges Assessment mit Discovery-Tool, Dependency-Workshops und Compliance-Mapping — am Ende steht ein 6-Rs-Portfolio, ein Wave-Plan und ein realistischer Kostenrahmen. Stufe 2 ist die Landing-Zone: VPC, Identity, Netzwerk-Anbindung, Logging, FinOps-Tagging und Infrastructure-as-Code-Basis werden in 4 bis 8 Wochen aufgebaut. Wer Infrastructure-as-Code noch nicht etabliert hat, findet Einstiegshinweise in unserem Beitrag Terraform IaC Best Practices. Stufe 3 ist die eigentliche Wellen-Migration, typischerweise über 6 bis 18 Monate, mit dedizierter Migration Factory aus internen und externen Mitarbeitenden. Stufe 4 ist die Stabilisierung und Optimierung der ersten 6 Monate nach Cutover — Right-Sizing, Reserved-Instances, Modernisierungs-Backlog, Personal-Übergabe.

Charakteristisch für unseren Ansatz: wir argumentieren in jedem Schritt gegen Lock-in, indem wir Infrastructure-as-Code, Container-Orchestrierung und offene Datenformate konsequent nutzen. Wir akzeptieren Hyperscaler-spezifische Services dort, wo sie Personalaufwand sparen (Managed Datenbanken, Object Storage, Identity), aber wir vermeiden tiefe Bindung an proprietäre Plattform-Dienste, wo sie eine spätere Multi-Cloud- oder Exit-Strategie verhindern würden. Welcher Hyperscaler im Einzelfall passt, hängt von der vorhandenen Microsoft-, Linux- oder Daten-Landschaft ab — eine differenzierte Gegenüberstellung finden Sie in AWS vs Azure vs GCP.

Häufige Fragen