---
title: Workload Migration Use Cases
description: Strukturierte Übersicht der Migrations-Use-Cases nach Migrationsobjekt, State-Profil und Rahmenbedingungen für klare Kategoriegrenzen und Entscheidungskontext.
sidebar:
  label: Use Cases
  order: 8
source_url: "https://framework.stackit.cloud/de/migration/design-and-mobilize/design/workload-migration-use-cases/"
source_file: "docs/de/migration/design-and-mobilize/design/workload-migration-use-cases.mdx"
---

## 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

<CardGrid>
  <Card title="Application-Runtime-Migration">
    Migration kompletter Anwendungs-Runtimes über VM- und Plattform-Ziele hinweg, inklusive
    Abhängigkeiten, Cutover-Verhalten und Betriebs-Handover.
  </Card>
  <Card title="Container-Plattform-Migration">
    Migration zwischen Kubernetes-Plattformen mit getrennter Behandlung von stateless und stateful
    Workload-Profilen.
  </Card>
  <Card title="Datenmigration">
    Migration großer Dateibestände, Datenbanken und Datenplattform-Workloads mit expliziten
    Konsistenz-, Performance- und Integritätsgrenzen.
  </Card>
  <Card title="Identity- und Access-Migration">
    Migration von IAM-Grundlagen wie SSO, Föderation, Rollen, Service-Accounts und
    Berechtigungsmodellen.
  </Card>
  <Card title="Netzwerk- und Konnektivitäts-Migration">
    Migration von Routing, DNS, Firewall-Regeln, Segmentierung, privater Konnektivität und
    umgebungsübergreifenden Kommunikationspfaden.
  </Card>
  <Card title="Integrations- und API-Migration">
    Migration von API-Verträgen, Messaging, Eventing und Integrations-Endpunkten über Quell- und
    Zielumgebungen hinweg.
  </Card>
  <Card title="Migration von Security- und Compliance-Controls">
    Migration von Controls, Nachweisketten, Schlüsselmaterial und Audit-Anforderungen für regulierte
    Produktionsreife.
  </Card>
  <Card title="Operations- und Observability-Migration">
    Migration von Monitoring, Alerting, Logging, Incident-Workflows und Service-Level-Baselines für
    den Betrieb.
  </Card>
  <Card title="Delivery- und Resilienz-Migration">
    Migration von CI/CD-Pipelines, Automatisierungs-Controls, Backup-Ketten und
    Disaster-Recovery-Fähigkeiten.
  </Card>
</CardGrid>

## 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

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](/de/migration/design-and-mobilize/design/aws-azure-target-service-mappings/).

## 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

<Steps>

1. Das primäre Migrationsobjekt identifizieren.
2. Workload-State-Profil und Kritikalität bestimmen.
3. Konnektivitäts- und Transfer-Einschränkungen erfassen.
4. Rahmenbedingungen für Downtime, Konsistenz und Compliance definieren.
5. Die Anfrage einer Use-Case-Kategorie zuordnen und Annahmen dokumentieren.

</Steps>

## Use-Case-Katalog und Grenzen

### 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

- **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

- **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

- **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

- **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

- **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

- **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

- **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

- **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

- **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.

<Aside type="note" title="Use-Case-Sicht und R-Strategie ergänzen sich">
  Die Use-Case-Sicht ersetzt die R-Strategie nicht. Sie strukturiert Anfragen-Transparenz und
  Kategorie-Zuordnung, bevor Umsetzungs-Assets ausgewählt werden.
</Aside>

## 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

<ScfAssetLoader
  showFilter={false}
  showSearch={false}
  frameworkSlug="migration"
  filterByTag={["uc/app-stack", "app-stack"]}
/>

### Große Datenmigration zum STACKIT File Service

<ScfAssetLoader
  showFilter={false}
  showSearch={false}
  frameworkSlug="migration"
  filterByTag={["uc/file-data", "file-data"]}
/>

### Kubernetes-zu-Kubernetes-Migration

<ScfAssetLoader
  showFilter={false}
  showSearch={false}
  frameworkSlug="migration"
  filterByTag={["uc/k8s", "kubernetes"]}
/>