STACKIT · Migration in Wellen
Migration zu STACKIT – von AWS, Azure, GCP und On-Premises
Sie wissen vorher, welche Ihrer Dienste auf STACKIT ein Gegenstück haben und welche nicht. Danach migrieren wir Daten und Anwendungen in Wellen, mit festem Rückfallweg und Abnahme am Ziel.
- AWS, Azure, Google Cloud
- On-Premises und VMware
- Zuordnung mit offenen Lücken
- Cutover mit Rückfallkriterien
01Ausgangslage
Ein Umzug auf STACKIT scheitert selten an den Servern
Virtuelle Maschinen und Datenbanken lassen sich verschieben. Schwierig wird es bei den Diensten dazwischen: Funktionen, Spezialdienste, Rechtemodelle. Deshalb beginnt jede Migration nach STACKIT bei uns mit einer ehrlichen Zuordnung, nicht mit einem Kopierlauf.
SKAFFON plant und führt die Migration durch, von AWS, Microsoft Azure und Google Cloud, aus eigenen Rechenzentren und aus VMware-Umgebungen. Die Seite richtet sich an IT-Leitung und Architekten, die den Wechsel erwägen. Das allgemeine Vorgehen bei Cloud-Migrationen beschreibt Cloud-Migration; hier geht es um das Ziel STACKIT.
02Quellplattformen
Woher Sie kommen bestimmt, wie genau das Assessment wird
-
AWS, Azure, Google Cloud
Maßgeblich ist, wie Ihre Umgebung beschrieben ist. Liegt sie als Terraform- oder OpenTofu-Code vor, ist das Assessment präzise; ohne Code erfassen wir den Bestand über Konsole, Export und Gespräche.
-
On-Premises und VMware
Inventar aus Virtualisierungsverwaltung oder RVTools-Export. Wenn nicht STACKIT, sondern ein eigener Betrieb Ziel ist, passt VMware-Exit nach Proxmox besser; die Entscheidungshilfe steht im VMware-Alternativen-Vergleich.
-
Andere Quellen
Prüfung im Einzelfall.
03Zuordnung
Was aus Ihrem Dienst auf STACKIT wird, und wo nichts wird
Die Tabelle ist ein Ausgangspunkt für das Assessment, kein Automatismus. Sie stützt sich auf die STACKIT-Produktübersicht vom 13.11.2026; „Lücke“ heißt: in dieser Übersicht kein gleichartiges Produkt aufgeführt. Die Spalte „Prüfen“ nennt, was an der konkreten Zuordnung noch zu klären ist.
| Dienst auf der Quelle (Beispiele) | STACKIT-Ziel | Prüfen |
|---|---|---|
| Verwaltetes Kubernetes (EKS, AKS, GKE) | Kubernetes Engine (SKE) | Kubernetes-Version, Add-ons, Integration der Cloud-Identität (IRSA, Workload Identity der Quelle) |
| Virtuelle Server (EC2, Azure VM, Compute Engine) | STACKIT Compute Engine | Images, Betriebssysteme, Maschinengrößen, Lizenzen |
| Verwaltetes PostgreSQL (RDS, Azure Database, Cloud SQL) | PostgreSQL Flex | Extensions, Rollen, Version; siehe Datenbanken auf STACKIT |
| Objektspeicher (S3, Blob Storage, Cloud Storage) | Object Storage (S3-kompatibel) | genutzte API-Funktionen, Lebenszyklusregeln, Zugriffsmodell |
| Load Balancer | Load Balancing | Protokolle, Zertifikate, Ingress-Konzept |
| Geheimnisverwaltung, Schlüsselverwaltung | Secrets Manager, KMS | Verfahren zur Rotation, Schlüsselherkunft |
| Monitoring und Logging | Observability | Metrik- und Log-Formate, Alarmierung; siehe Managed Monitoring |
| Container-Registry | Container Registry | Image-Migration, Zugriffsrechte |
| Redis, OpenSearch, RabbitMQ, MongoDB (verwaltet) | gleichnamige STACKIT-Produkte (Redis, OpenSearch, RabbitMQ, MongoDB Flex) | Versionen und Funktionsumfang je Dienst |
| GPU-Server, KI-Modelle | Compute Engine GPU, AI Model Serving | GPU und KI auf STACKIT; Modelle und Auslastung |
| Funktions-Dienste (Lambda, Azure Functions, Cloud Functions) | in der Produktübersicht nicht aufgeführt (Lücke) | Umbau auf Container oder Kubernetes |
| Data Warehouse und ähnliche Spezialdienste | in der Produktübersicht nicht aufgeführt (Lücke); teils Dremio und Workflows als Bausteine | Funktionsumfang und Anwendungsabhängigkeit |
| Spezifische KI-Dienste des Hyperscalers | Lücke, ggf. AI Model Serving als Teilersatz | Funktionsvergleich pro Anwendung |
| Identität und Netzwerk | IAM, Service Accounts, Core Networking | Rechtemodell, Adressplan; siehe Landing Zone |
Lücken
Eine Lücke in der Tabelle ist noch kein Nein
Ob eine Lücke ein Hindernis ist, entscheidet die Anwendung: Manche Dienste lassen sich durch Standardtechnik ersetzen, andere verlangen einen Umbau, und manche sprechen gegen den Wechsel. Genau das legt das Assessment offen, bevor ein Plan entsteht. Auf dem Hyperscaler zu bleiben, bleibt eine legitime Antwort.
Kriterien im Cloud-Anbieter-Vergleich04Überblick
Acht Schritte vom Bestand bis zur Übergabe
Wer mehrstufig vorgeht, setzt vorher ein Cloud Readiness Assessment auf, und wer aus dem Hyperscaler-Vertrag heraus will, findet den Rahmen unter Cloud-Exit und Portabilität.
05Ablauf im Detail
Was in den acht Schritten konkret passiert
- 01
Assessment
Ergebnis: EntscheidungsvorlageInventar, Abhängigkeiten, Datenklassen, Lizenzen, Zeitrestriktionen. Ergebnis: Zuordnung mit Lücken, Risikoliste, Entscheidungsvorlage.
- 02
Zielarchitektur und Landing Zone
Ergebnis: ZielbildStruktur, Netzwerk, Rechte, Protokollierung, wie unter Landing Zone beschrieben.
- 03
Wellenplan
Ergebnis: ReihenfolgeGruppen von Systemen nach Abhängigkeit; kritische oder schwierige Systeme nicht zuerst. Jede Welle hat Ziel, Abnahmekriterien, Fenster und Rückfallweg.
- 04
Pilot
Ergebnis: erprobtes MusterEine unkritische Anwendung durchläuft das Muster vollständig, einschließlich Restore-Test und Betriebsübergabe.
- 05
Daten und Anwendungen
Ergebnis: Systeme am ZielDatenbanken nach Dump oder Replikation (Datenbankmigration), Objektdaten per Kopierwerkzeug, Server per Neuaufbau aus Code oder Image-Übernahme, Kubernetes-Workloads per GitOps auf SKE. Anwendungsanpassungen, wo Dienste wegfallen (Anwendungsmodernisierung).
- 06
Cutover
Ergebnis: umgeschaltetUmschalten von DNS, Verbindungen und Zugriffen nach Checkliste; die Quelle bleibt bis zur Abnahme unverändert erhalten.
- 07
Validierung
Ergebnis: AbnahmeFunktionstests, Datenabgleich, Lastprüfung, Restore-Test, Kosten- und Berechtigungsprüfung am Ziel.
- 08
Übergabe oder Betrieb
Ergebnis: RunbooksRunbooks, Einweisung, optional Betrieb (Managed Cloud Services).
06Umschaltmoment
Cutover: sechs Punkte, bevor umgeschaltet wird
Vor jeder Welle muss feststehen, wann Sie zurückgehen. Konkrete Schwellwerte legen wir mit Ihnen je System fest.
- Backup von Quelle und Ziel liegt vor, Restore wurde getestet.
- Datenabgleich ohne ungeklärte Abweichung.
- Monitoring und Alarme am Ziel aktiv, Nachtzuständigkeiten geklärt.
- DNS-Gültigkeitsdauern vorab gesenkt, Umschaltplan mit Uhrzeiten liegt vor.
- Rückfallkriterium vorab festgelegt (etwa: Abnahmetest nicht bestanden oder Fehlerquote nach dem Umschalten über dem vereinbarten Wert), Rückfallweg geprobt.
- Abnahme durch den Fachbereich terminiert.
07Eingaben
Systemliste, Bestand, Termine: Ihre Eingaben für das Assessment
- Systemliste mit Verantwortlichen
- Zugang zu Dokumentation und Bestand (Infrastruktur-Code oder Inventar)
- Terminvorgaben, etwa Vertragsenden und Lizenzen
- Wartungsfenster
- Ihr STACKIT-Projekt oder die Absicht, eines anzulegen
08Grenzen
Zugriff, Vertrag, Region: was bei Ihnen bleibt
Zugangsdaten bleiben bei Ihnen; wir arbeiten mit den Rechten, die Sie für die jeweilige Aufgabe freigeben.
Für die Datenübertragung beim Verlassen des Quellanbieters gelten dessen Bedingungen (Stand: 13.11.2026). AWS schreibt die Entgelte für Datenübertragung ins Internet gut, wenn Sie alle Daten aus AWS oder aus einem AWS-Dienst abziehen; beantragt wird das beim AWS Support. Für AWS-Konten mit Kontoland in einem EU-Mitgliedstaat regelt das AWS EU Data Act Addendum den Ablauf: Wechselantrag mindestens zwei Monate vor dem geplanten Beginn, Übergangszeitraum von 30 Kalendertagen, bei technischer Undurchführbarkeit bis zu sieben Monaten. Microsoft Azure verlangt vorab eine Support-Anfrage mit Startdatum und geschätzter Datenmenge; gutgeschrieben werden Egress-Entgelte für höchstens 60 Kalendertage ab dem angegebenen Startdatum, ausgenommen etwa ExpressRoute, VPN, Front Door und CDN; die Gutschrift beantragen Sie, nachdem alle Azure-Abonnements gekündigt sind. Google Cloud verlangt eine Exit Notice per Formular und die Beendigung des Vertrags für den verlassenen Dienst; die Migrationsphase beträgt mindestens 30 Tage, die Gutschrift für Übertragungen über das Internet erscheint auf der Schlussrechnung. Nach Artikel 29 der Verordnung (EU) 2023/2854 dürfen Anbieter bis zum 12. Januar 2027 nur ermäßigte Wechselentgelte erheben, die ihre unmittelbaren Kosten des Wechsels nicht übersteigen; ab dem 12. Januar 2027 dürfen sie für den Vollzug des Wechsels keine Wechselentgelte mehr erheben. Die Fristen Ihres Vertrags setzen wir in den Wellenplan ein.
STACKIT betreibt die Regionen eu01 in Deutschland und eu02 in Österreich; Resource Manager und IAM arbeiten regionsübergreifend (Regionen und Verfügbarkeitszonen). Spezialisierte Dienste und neue Funktionen kann STACKIT zuerst in einzelnen Regionen bereitstellen; so ist der KMS laut Release Notes seit dem 7. April 2026 in eu02 verfügbar. Im Entwurf prüfen wir für jedes benötigte Produkt, ob es in der Zielregion verfügbar ist.
STACKIT-Zusagen zu Datenstandort, Verfügbarkeit und Support stehen im Vertrag mit STACKIT; die rechtliche Prüfung liegt bei Ihnen.
09Angebot
Was ein Migrationsangebot teurer oder günstiger macht
Den Aufwand bestimmen Zahl und Heterogenität der Systeme, Datenvolumen und Änderungsrate, die Zahl der Lücken, zulässige Downtime, Sicherheitsanforderungen und der Anteil, den Ihr Team selbst übernimmt. Aus dem Assessment entsteht ein Angebot mit klaren Ergebnissen.
10Passung
Für wen die Migration nach STACKIT ein Fall für uns ist
Dann sollten wir sprechen
- Sie erwägen den Wechsel zu STACKIT und wollen wissen, was auf Sie zukommt.
- Sie wollen Lücken offen benannt bekommen, bevor ein Plan entsteht.
- Sie suchen jemanden, der Cutover und Validierung verantwortet.
Dann ist ein anderer Weg besser
- Sie wollen eine Garantie auf „Migration ohne Risiko“ oder ohne Anwendungsänderung, obwohl Ihre Anwendung an Hyperscaler-Diensten ohne Entsprechung hängt.
- Die Zielplattform steht fest auf einem anderen Anbieter: Dann sind die Seiten zu AWS, Azure oder Google Cloud der passende Einstieg.
- Sie suchen einen Reseller für STACKIT-Verträge: Verträge schließen Sie mit STACKIT.
11
Häufige Fragen
Brauche ich StackToIT für die Migration?
Nein. StackToIT liest Terraform-/OpenTofu-Code oder VMware-RVTools-Exporte und erzeugt Zuordnung, Zielarchitektur, Terraform-Entwürfe und Entscheidungsliste. Wir nutzen es im Assessment, wenn die Eingaben vorliegen; die Migration läuft mit oder ohne.
Was, wenn Dienste ohne Entsprechung auf STACKIT genutzt werden?
Das Assessment weist sie als Lücke aus. Je Anwendung entscheiden wir mit Ihnen: ersetzen, umbauen, in der Quelle belassen oder den Wechsel für dieses System verwerfen.
Betreiben Sie die Umgebung nach der Migration?
Auf Wunsch, als Managed Service. Umfang und Servicezeiten legen wir im Angebot fest.
Nennen Sie uns Ausgangsplattform und Fristen
Aus Ihrer Beschreibung entsteht der Vorschlag für das Assessment. Überblick über alle STACKIT-Leistungen: STACKIT.