---
title: Workload Migration Use Cases
description: Structured overview of migration use cases by migration object, state profile, and constraints to make category boundaries and decision context transparent.
sidebar:
  label: Use Cases
  order: 8
source_url: "https://framework.stackit.cloud/migration/design-and-mobilize/design/workload-migration-use-cases/"
source_file: "docs/migration/design-and-mobilize/design/workload-migration-use-cases.mdx"
---

## Why this page exists

R-strategy explains how migration is run. This page adds the workload lens and clarifies what
is migrated. It is intentionally solution-neutral and focuses on transparent categorization,
feasibility boundaries, and decision context.

## Use-case categories in scope

<CardGrid>
  <Card title="Application runtime migration">
    Migration of complete application runtimes across VM and platform targets, including
    dependencies, cutover behavior, and operating handover.
  </Card>
  <Card title="Container platform migration">
    Migration between Kubernetes platforms with separate treatment of stateless and stateful
    workload profiles.
  </Card>
  <Card title="Data migration">
    Migration of large file volumes, databases, and data platform workloads with explicit
    consistency, performance, and integrity boundaries.
  </Card>
  <Card title="Identity and access migration">
    Migration of IAM foundations such as SSO, federation, roles, service accounts, and permission
    models.
  </Card>
  <Card title="Network and connectivity migration">
    Migration of routing, DNS, firewall rules, segmentation, private connectivity, and
    cross-environment communication paths.
  </Card>
  <Card title="Integration and API migration">
    Migration of API contracts, messaging, eventing, and integration endpoints across source and
    target estates.
  </Card>
  <Card title="Security and compliance controls migration">
    Migration of controls, evidence chains, key material, and audit requirements required for
    regulated production readiness.
  </Card>
  <Card title="Operations and observability migration">
    Migration of monitoring, alerting, logging, incident workflows, and service-level operations
    baselines.
  </Card>
  <Card title="Delivery and resilience migration">
    Migration of CI/CD pipelines, automation controls, backup chains, and disaster recovery
    capabilities.
  </Card>
</CardGrid>

## How current categories fit in this model

- **Application stack migration** is part of **Application runtime migration**.
- **Large file data migration** is part of **Data migration**.
- **Kubernetes to Kubernetes migration** is part of **Container platform migration**.

## Migration use cases from AWS and Azure to STACKIT

STACKIT supports migration paths from AWS and Azure across application runtimes, data, network,
identity, operations, and delivery. Select the target path for each workload according to its
architecture, data profile, availability requirements, and operating model.

| Use case                                           | Migration capability to STACKIT                                                                                                                                                                                                                                                                                                                                                           |
| -------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Landing zone migration**                         | AWS account and Azure subscription structures, network segmentation, identity and access controls, security policies, logging, monitoring, and governance guardrails are mapped to a STACKIT landing zone before application migration waves begin. The STACKIT Landing Zone Accelerator provides a reusable, automated foundation for implementing these controls consistently at scale. |
| **VM-based applications**                          | AWS EC2 and Azure VM workloads can be migrated to STACKIT Compute Engine, including operating systems, middleware, applications, configurations, and connected data.                                                                                                                                                                                                                      |
| **VM estates with high availability requirements** | Tool-assisted Relocate migration supports continuous replication, controlled validation, and planned cutover for large VM landscapes and repeatable migration waves.                                                                                                                                                                                                                      |
| **Container and Kubernetes workloads**             | AWS EKS, Azure AKS, and self-managed Kubernetes clusters can move to STACKIT Kubernetes Engine. Stateless applications can be redeployed declaratively; stateful applications can use backup and restore or data replication with staged traffic migration.                                                                                                                               |
| **PaaS and web applications**                      | Applications using common runtimes such as Java, Node.js, Python, or Ruby can run on STACKIT Cloud Foundry when they fit the platform model.                                                                                                                                                                                                                                              |
| **Databases and data platforms**                   | Self-managed and cloud-based databases can move to STACKIT Managed Database Services or initially to Compute Engine instances, using export/import, replication, and controlled cutover procedures.                                                                                                                                                                                       |
| **Object and file storage**                        | AWS S3 and Azure Blob Storage can move to STACKIT Object Storage. AWS EFS, Azure Files, and NFS-based file systems can move to STACKIT File Storage through initial copy, delta synchronization, and final consistency cutover.                                                                                                                                                           |
| **Identity and access management**                 | AWS IAM, Azure RBAC, and Microsoft Entra-based access models can be mapped to STACKIT roles, permissions, service accounts, and federation.                                                                                                                                                                                                                                               |
| **Network, DNS, and connectivity**                 | AWS VPCs and Azure VNets can be mapped to STACKIT Network Areas, routing, security groups, load balancing, DNS, and site-to-site VPN connectivity.                                                                                                                                                                                                                                        |
| **Integration, messaging, and APIs**               | APIs, integration endpoints, and messaging workloads can be migrated with their contracts, security mechanisms, and cutover sequence. STACKIT RabbitMQ supports AMQP- and RabbitMQ-based patterns.                                                                                                                                                                                        |
| **Security, compliance, and operations**           | Secrets, keys, audit requirements, logging, monitoring, alerting, backup, and operational processes are established as part of the target environment before go-live.                                                                                                                                                                                                                     |
| **CI/CD and delivery**                             | Deployment pipelines, infrastructure automation, and source control can move to STACKIT Git, Terraform or OpenTofu, CLI, APIs, and suitable image-management processes.                                                                                                                                                                                                                   |

For the service-by-service target mapping, see [AWS and Azure Target Service Mappings](/migration/design-and-mobilize/design/aws-azure-target-service-mappings/).

## Classification dimensions

Use these dimensions to categorize requests before selecting implementation variants:

- **Migration object**: Application stack, data set, or container platform.
- **State profile**: Stateless, stateful, or mixed.
- **Criticality profile**: Business criticality and accepted migration risk.
- **Connectivity profile**: Network reachability and protocol compatibility between source and target.
- **Downtime profile**: Allowed service interruption and cutover window constraints.
- **Compliance profile**: Security, audit, and regulatory boundaries.

## How to classify a migration request

<Steps>

1. Identify the primary migration object.
2. Determine workload state profile and criticality.
3. Capture connectivity and transfer constraints.
4. Define boundary conditions for downtime, consistency, and compliance.
5. Assign the request to a use-case category and record assumptions.

</Steps>

## Use-case catalog and boundaries

### 1. Application runtime migration

- **Includes**: Application stack migration (including VM-centered migrations).
- **Primary objective**: Transition application runtimes with predictable cutover and operating handover.

Mandatory boundaries:

- **Dependency clarity**: Integration dependencies and transition windows must be known.
- **Cutover model**: Interruption model and decision gates must be approved.
- **Rollback readiness**: Triggers and ownership must be defined.

### 2. Container platform migration

- **Includes**: Kubernetes to Kubernetes migration.
- **Primary objective**: Transition containerized workloads to target cluster models.

Mandatory boundaries:

- **State classification**: Stateless/stateful boundaries must be explicit per component.
- **State portability**: Storage and database compatibility must be validated.
- **Traffic control**: Progressive switch capability must be confirmed.

### 3. Data migration

- **Includes**: Large file data migration and database/data platform transitions.
- **Primary objective**: Transition data sets with controlled consistency and integrity.

Mandatory boundaries:

- **Connectivity feasibility**: Required endpoint reachability must be validated.
- **Consistency model**: Freeze windows, delta strategy, and validation methods must be defined.
- **Performance feasibility**: Throughput profile and run limits must be validated.

### 4. Identity and access migration

- **Primary objective**: Transition identity trust and access models without security regression.

Mandatory boundaries:

- **Trust model mapping**: Federation, SSO, and token flows must be mapped.
- **Authorization mapping**: Role and entitlement mapping must be validated.
- **Credential transition**: Secret rotation and emergency access paths must be approved.

### 5. Network and connectivity migration

- **Primary objective**: Transition communication paths and security boundaries between environments.

Mandatory boundaries:

- **Addressing and routing**: IP planning and route ownership must be defined.
- **Control policy parity**: Firewall and segmentation policies must be aligned.
- **Name resolution continuity**: DNS transition behavior must be planned.

### 6. Integration and API migration

- **Primary objective**: Transition service interfaces and integration patterns without breaking consumers.

Mandatory boundaries:

- **Contract compatibility**: Versioning and compatibility strategy must be explicit.
- **Dependency sequencing**: Producer/consumer switch order must be managed.
- **Message semantics**: Ordering, retries, and repeat-safe behavior assumptions must be validated.

### 7. Security and compliance controls migration

- **Primary objective**: Preserve or improve control effectiveness and audit readiness during transition.

Mandatory boundaries:

- **Control mapping**: Required controls and evidence points must be mapped.
- **Key and certificate handling**: Cryptographic material transition must be governed.
- **Audit continuity**: Logging and evidence retention obligations must remain intact.

### 8. Operations and observability migration

- **Primary objective**: Ensure operational control and incident response readiness after migration.

Mandatory boundaries:

- **Observability baseline**: Metrics, logs, traces, and alerts must be active before cutover.
- **Operating ownership**: On-call and escalation paths must be assigned.
- **Service objectives**: SLO/SLA targets and thresholds must be defined.

### 9. Delivery and resilience migration

- **Primary objective**: Transition software delivery and resilience capabilities to target operations.

Mandatory boundaries:

- **Pipeline continuity**: CI/CD and release controls must remain auditable.
- **Recovery readiness**: Backup/restore and DR assumptions must be validated.
- **Automation safety**: Guardrails for deployment automation must be in place.

## Cross-case decision criteria

- **Downtime target**: Planned downtime window versus continuous availability expectation.
- **Consistency requirement**: Eventual consistency, near-real-time, or strict transactional consistency.
- **Change tolerance**: How much architecture and application change is acceptable in the current wave.
- **Automation level**: Manual, semi-automated, or fully automated run path.
- **Risk and reversibility**: Ability to detect failure fast and revert without business-critical impact.

<Aside type="note" title="Use-case lens and R-strategy are complementary">
  The use-case lens does not replace R-strategy. It structures request transparency and category
  assignment before implementation assets are selected.
</Aside>

## Concrete asset templates

The implementation details are maintained in dedicated asset pages. This keeps the overview page
category-focused and allows concrete templates to evolve independently.

### Application with VM runtime

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

### Large data migration to STACKIT file service

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

### Kubernetes to Kubernetes migration

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