Application-Runtime-Migration
Migration kompletter Anwendungs-Runtimes über VM- und Plattform-Ziele hinweg, inklusive Abhängigkeiten, Cutover-Verhalten und Betriebs-Handover.
VM-Anwendungsmigration mit kontrolliertem Cutover
STACKIT
Warum diese Seite existiert
Abschnitt betitelt „Warum diese Seite existiert“Die R-Strategie erklärt, wie migriert wird. Diese Seite ergänzt die Workload-Sicht und klärt, was migriert wird. Sie ist bewusst lösungsneutral und fokussiert auf transparente Kategorisierung, Machbarkeitsgrenzen und Entscheidungskontext.
Use-Case-Kategorien im Scope
Abschnitt betitelt „Use-Case-Kategorien im Scope“Container-Plattform-Migration
Migration zwischen Kubernetes-Plattformen mit getrennter Behandlung von stateless und stateful Workload-Profilen.
Datenmigration
Migration großer Dateibestände, Datenbanken und Datenplattform-Workloads mit expliziten Konsistenz-, Performance- und Integritätsgrenzen.
Identity- und Access-Migration
Migration von IAM-Grundlagen wie SSO, Föderation, Rollen, Service-Accounts und Berechtigungsmodellen.
Netzwerk- und Konnektivitäts-Migration
Migration von Routing, DNS, Firewall-Regeln, Segmentierung, privater Konnektivität und umgebungsübergreifenden Kommunikationspfaden.
Integrations- und API-Migration
Migration von API-Verträgen, Messaging, Eventing und Integrations-Endpunkten über Quell- und Zielumgebungen hinweg.
Migration von Security- und Compliance-Controls
Migration von Controls, Nachweisketten, Schlüsselmaterial und Audit-Anforderungen für regulierte Produktionsreife.
Operations- und Observability-Migration
Migration von Monitoring, Alerting, Logging, Incident-Workflows und Service-Level-Baselines für den Betrieb.
Delivery- und Resilienz-Migration
Migration von CI/CD-Pipelines, Automatisierungs-Controls, Backup-Ketten und Disaster-Recovery-Fähigkeiten.
Wie sich die aktuellen Kategorien in dieses Modell einfügen
Abschnitt betitelt „Wie sich die aktuellen Kategorien in dieses Modell einfügen“- Application-Stack-Migration ist Teil der Application-Runtime-Migration.
- Migration großer Dateibestände ist Teil der Datenmigration.
- Kubernetes-zu-Kubernetes-Migration ist Teil der Container-Plattform-Migration.
Migrations-Use-Cases von AWS und Azure zu STACKIT
Abschnitt betitelt „Migrations-Use-Cases von AWS und Azure zu STACKIT“STACKIT unterstützt Migrationspfade von AWS und Azure über Anwendungs-Runtimes, Daten, Netzwerk, Identität, Betrieb und Delivery hinweg. Der Zielpfad wird je Workload anhand von Architektur, Datenprofil, Verfügbarkeitsanforderungen und Betriebsmodell ausgewählt.
| Use Case | Migrationsmöglichkeit zu STACKIT |
|---|---|
| Landing-Zone-Migration | AWS-Account- und Azure-Subscription-Strukturen, Netzwerksegmentierung, Identity- und Access-Controls, Security-Policies, Logging, Monitoring und Governance-Leitplanken werden vor Beginn der Applikationswellen auf eine STACKIT Landing Zone abgebildet. Der STACKIT Landing Zone Accelerator liefert eine wiederverwendbare, automatisierte Grundlage, um diese Controls konsistent und skalierbar umzusetzen. |
| VM-basierte Anwendungen | AWS-EC2- und Azure-VM-Workloads können zu STACKIT Compute Engine migriert werden, einschließlich Betriebssystemen, Middleware, Anwendungen, Konfigurationen und angebundenen Daten. |
| VM-Landschaften mit hohen Verfügbarkeitsanforderungen | Die toolgestützte Relocate-Migration unterstützt kontinuierliche Replikation, kontrollierte Validierung und geplanten Cutover für große VM-Landschaften und wiederholbare Migrationswellen. |
| Container- und Kubernetes-Workloads | AWS EKS, Azure AKS und selbstbetriebene Kubernetes-Cluster können zu STACKIT Kubernetes Engine migriert werden. Stateless Anwendungen werden deklarativ neu ausgerollt; stateful Anwendungen nutzen Backup und Restore oder Datenreplikation mit schrittweiser Traffic-Verlagerung. |
| PaaS- und Web-Anwendungen | Anwendungen mit gängigen Runtimes wie Java, Node.js, Python oder Ruby können auf STACKIT Cloud Foundry betrieben werden, wenn sie zum Plattformmodell passen. |
| Datenbanken und Datenplattformen | Selbstbetriebene und cloudbasierte Datenbanken können zu STACKIT Managed Database Services oder zunächst auf Compute-Engine-Instanzen migriert werden; die Umsetzung erfolgt über Export/Import, Replikation und kontrollierte Cutover-Verfahren. |
| Object Storage und Dateispeicher | AWS S3 und Azure Blob Storage können zu STACKIT Object Storage migriert werden. AWS EFS, Azure Files und NFS-basierte Dateisysteme können über Erstkopie, Delta-Synchronisation und finalen Konsistenz-Cutover nach STACKIT File Storage migriert werden. |
| Identity und Access Management | AWS IAM, Azure RBAC und Microsoft-Entra-basierte Zugriffsmodelle können auf STACKIT Rollen, Berechtigungen, Service Accounts und Föderation abgebildet werden. |
| Netzwerk, DNS und Konnektivität | AWS VPCs und Azure VNets können auf STACKIT Network Areas, Routing, Security Groups, Load Balancing, DNS und Site-to-Site-VPN-Konnektivität abgebildet werden. |
| Integration, Messaging und APIs | APIs, Integrationsendpunkte und Messaging-Workloads können zusammen mit ihren Verträgen, Sicherheitsmechanismen und Umschaltreihenfolgen migriert werden. STACKIT RabbitMQ unterstützt AMQP- und RabbitMQ-basierte Muster. |
| Security, Compliance und Betrieb | Secrets, Schlüssel, Audit-Anforderungen, Logging, Monitoring, Alerting, Backup und Betriebsprozesse werden vor dem Go-live als Teil der Zielumgebung aufgebaut. |
| CI/CD und Delivery | Deployment-Pipelines, Infrastrukturautomatisierung und Versionsverwaltung können auf STACKIT Git, Terraform oder OpenTofu, CLI, APIs und geeignete Image-Management-Prozesse überführt werden. |
Das servicebezogene Ziel-Mapping finden Sie unter Zielservice-Mappings für AWS und Azure.
Klassifikationsdimensionen
Abschnitt betitelt „Klassifikationsdimensionen“Nutzen Sie diese Dimensionen, um Anfragen vor der Auswahl von Umsetzungsvarianten zu kategorisieren:
- Migrationsobjekt: Application Stack, Datenbestand oder Container-Plattform.
- State-Profil: Stateless, stateful oder gemischt.
- Kritikalitätsprofil: Business-Kritikalität und akzeptiertes Migrationsrisiko.
- Konnektivitätsprofil: Netzwerk-Erreichbarkeit und Protokollkompatibilität zwischen Quelle und Ziel.
- Downtime-Profil: Erlaubte Service-Unterbrechung und Grenzen des Cutover-Fensters.
- Compliance-Profil: Security-, Audit- und regulatorische Grenzen.
Wie eine Migrationsanfrage klassifiziert wird
Abschnitt betitelt „Wie eine Migrationsanfrage klassifiziert wird“- Das primäre Migrationsobjekt identifizieren.
- Workload-State-Profil und Kritikalität bestimmen.
- Konnektivitäts- und Transfer-Einschränkungen erfassen.
- Rahmenbedingungen für Downtime, Konsistenz und Compliance definieren.
- Die Anfrage einer Use-Case-Kategorie zuordnen und Annahmen dokumentieren.
Use-Case-Katalog und Grenzen
Abschnitt betitelt „Use-Case-Katalog und Grenzen“1. Application-Runtime-Migration
Abschnitt betitelt „1. Application-Runtime-Migration“- Umfasst: Application-Stack-Migration (inklusive VM-zentrierter Migrationen).
- Primäres Ziel: Anwendungs-Runtimes mit planbarem Cutover und Betriebs-Handover überführen.
Verbindliche Grenzen:
- Abhängigkeits-Klarheit: Integrationsabhängigkeiten und Übergangsfenster müssen bekannt sein.
- Cutover-Modell: Unterbrechungsmodell und Entscheidungs-Gates müssen freigegeben sein.
- Rollback-Readiness: Trigger und Ownership müssen definiert sein.
2. Container-Plattform-Migration
Abschnitt betitelt „2. Container-Plattform-Migration“- Umfasst: Kubernetes-zu-Kubernetes-Migration.
- Primäres Ziel: Containerisierte Workloads in Ziel-Cluster-Modelle überführen.
Verbindliche Grenzen:
- State-Klassifikation: Stateless-/Stateful-Grenzen müssen je Komponente explizit sein.
- State-Portabilität: Storage- und Datenbank-Kompatibilität müssen validiert sein.
- Traffic-Steuerung: Die Fähigkeit zum progressiven Switch muss bestätigt sein.
3. Datenmigration
Abschnitt betitelt „3. Datenmigration“- Umfasst: Migration großer Dateibestände sowie Datenbank-/Datenplattform-Übergänge.
- Primäres Ziel: Datenbestände mit kontrollierter Konsistenz und Integrität überführen.
Verbindliche Grenzen:
- Konnektivitäts-Machbarkeit: Die erforderliche Endpunkt-Erreichbarkeit muss validiert sein.
- Konsistenzmodell: Freeze-Fenster, Delta-Strategie und Validierungsmethoden müssen definiert sein.
- Performance-Machbarkeit: Durchsatzprofil und Laufzeitgrenzen müssen validiert sein.
4. Identity- und Access-Migration
Abschnitt betitelt „4. Identity- und Access-Migration“- Primäres Ziel: Identity-Trust- und Access-Modelle ohne Security-Regression überführen.
Verbindliche Grenzen:
- Trust-Modell-Mapping: Föderation, SSO und Token-Flows müssen gemappt sein.
- Autorisierungs-Mapping: Rollen- und Entitlement-Mapping müssen validiert sein.
- Credential-Übergang: Secret-Rotation und Notfall-Zugriffspfade müssen freigegeben sein.
5. Netzwerk- und Konnektivitäts-Migration
Abschnitt betitelt „5. Netzwerk- und Konnektivitäts-Migration“- Primäres Ziel: Kommunikationspfade und Security-Grenzen zwischen Umgebungen überführen.
Verbindliche Grenzen:
- Adressierung und Routing: IP-Planung und Routen-Ownership müssen definiert sein.
- Policy-Parität der Controls: Firewall- und Segmentierungs-Policies müssen abgeglichen sein.
- Kontinuität der Namensauflösung: Das DNS-Übergangsverhalten muss geplant sein.
6. Integrations- und API-Migration
Abschnitt betitelt „6. Integrations- und API-Migration“- Primäres Ziel: Service-Schnittstellen und Integrationsmuster überführen, ohne Consumer zu brechen.
Verbindliche Grenzen:
- Vertragskompatibilität: Versionierungs- und Kompatibilitätsstrategie müssen explizit sein.
- Abhängigkeits-Sequenzierung: Die Switch-Reihenfolge von Producer/Consumer muss gesteuert werden.
- Message-Semantik: Annahmen zu Ordering, Retries und wiederholungssicherem Verhalten müssen validiert sein.
7. Migration von Security- und Compliance-Controls
Abschnitt betitelt „7. Migration von Security- und Compliance-Controls“- Primäres Ziel: Wirksamkeit der Controls und Audit-Readiness während des Übergangs erhalten oder verbessern.
Verbindliche Grenzen:
- Control-Mapping: Erforderliche Controls und Nachweispunkte müssen gemappt sein.
- Schlüssel- und Zertifikats-Handling: Der Übergang kryptografischen Materials muss gesteuert sein.
- Audit-Kontinuität: Logging- und Nachweis-Aufbewahrungspflichten müssen intakt bleiben.
8. Operations- und Observability-Migration
Abschnitt betitelt „8. Operations- und Observability-Migration“- Primäres Ziel: Operative Kontrolle und Incident-Response-Readiness nach der Migration sicherstellen.
Verbindliche Grenzen:
- Observability-Baseline: Metriken, Logs, Traces und Alerts müssen vor dem Cutover aktiv sein.
- Betriebs-Ownership: On-Call- und Eskalationspfade müssen zugewiesen sein.
- Service-Ziele: SLO-/SLA-Ziele und Schwellwerte müssen definiert sein.
9. Delivery- und Resilienz-Migration
Abschnitt betitelt „9. Delivery- und Resilienz-Migration“- Primäres Ziel: Software-Delivery- und Resilienz-Fähigkeiten in den Zielbetrieb überführen.
Verbindliche Grenzen:
- Pipeline-Kontinuität: CI/CD- und Release-Controls müssen auditierbar bleiben.
- Recovery-Readiness: Backup-/Restore- und DR-Annahmen müssen validiert sein.
- Automatisierungs-Sicherheit: Leitplanken für Deployment-Automatisierung müssen vorhanden sein.
Fallübergreifende Entscheidungskriterien
Abschnitt betitelt „Fallübergreifende Entscheidungskriterien“- Downtime-Ziel: Geplantes Downtime-Fenster versus Erwartung durchgehender Verfügbarkeit.
- Konsistenzanforderung: Eventual Consistency, Near-Real-Time oder strikte transaktionale Konsistenz.
- Änderungstoleranz: Wie viel Architektur- und Anwendungsänderung in der aktuellen Welle akzeptabel ist.
- Automatisierungsgrad: Manueller, teilautomatisierter oder vollautomatisierter Ausführungspfad.
- Risiko und Reversibilität: Fähigkeit, Fehler schnell zu erkennen und ohne business-kritische Auswirkung zurückzurollen.
Konkrete Asset-Vorlagen
Abschnitt betitelt „Konkrete Asset-Vorlagen“Die Umsetzungsdetails werden auf dedizierten Asset-Seiten gepflegt. Das hält die Übersichtsseite kategorie-fokussiert und lässt konkrete Vorlagen unabhängig weiterentwickeln.
Anwendung mit VM-Runtime
Abschnitt betitelt „Anwendung mit VM-Runtime“Asset-Titel
Framework
Asset-Typ
Migration
Runbook
Große Datenmigration zum STACKIT File Service
Abschnitt betitelt „Große Datenmigration zum STACKIT File Service“Asset-Titel
Framework
Asset-Typ
Migration
Runbook
Migration
Runbook
Kubernetes-zu-Kubernetes-Migration
Abschnitt betitelt „Kubernetes-zu-Kubernetes-Migration“Asset-Titel
Framework
Asset-Typ
Migration
Runbook
Migration
Blueprint
Migration
Runbook
Data and AI
Blueprint
Migration
Runbook
Migration
Runbook
Migration
Runbook
Migration
Service