Application runtime migration
Migration of complete application runtimes across VM and platform targets, including dependencies, cutover behavior, and operating handover.
VM Application Migration with Controlled Cutover
STACKIT
Why this page exists
Section titled “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
Section titled “Use-case categories in scope”Container platform migration
Migration between Kubernetes platforms with separate treatment of stateless and stateful workload profiles.
Data migration
Migration of large file volumes, databases, and data platform workloads with explicit consistency, performance, and integrity boundaries.
Identity and access migration
Migration of IAM foundations such as SSO, federation, roles, service accounts, and permission models.
Network and connectivity migration
Migration of routing, DNS, firewall rules, segmentation, private connectivity, and cross-environment communication paths.
Integration and API migration
Migration of API contracts, messaging, eventing, and integration endpoints across source and target estates.
Security and compliance controls migration
Migration of controls, evidence chains, key material, and audit requirements required for regulated production readiness.
Operations and observability migration
Migration of monitoring, alerting, logging, incident workflows, and service-level operations baselines.
Delivery and resilience migration
Migration of CI/CD pipelines, automation controls, backup chains, and disaster recovery capabilities.
How current categories fit in this model
Section titled “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
Section titled “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.
Classification dimensions
Section titled “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
Section titled “How to classify a migration request”- Identify the primary migration object.
- Determine workload state profile and criticality.
- Capture connectivity and transfer constraints.
- Define boundary conditions for downtime, consistency, and compliance.
- Assign the request to a use-case category and record assumptions.
Use-case catalog and boundaries
Section titled “Use-case catalog and boundaries”1. Application runtime migration
Section titled “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
Section titled “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
Section titled “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
Section titled “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
Section titled “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
Section titled “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
Section titled “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
Section titled “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
Section titled “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
Section titled “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.
Concrete asset templates
Section titled “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
Section titled “Application with VM runtime”Asset title
Framework
Asset type
Migration
Runbook
Large data migration to STACKIT file service
Section titled “Large data migration to STACKIT file service”Asset title
Framework
Asset type
Migration
Runbook
Migration
Runbook
Kubernetes to Kubernetes migration
Section titled “Kubernetes to Kubernetes migration”Asset title
Framework
Asset type
Architecture
Guide
Migration
Runbook
Migration
Blueprint
Architecture
Guide
Advisory
Workshop
Data and AI
Guide
Migration
Runbook
Data and AI
Blueprint
Data and AI
Blueprint
Data and AI
Blueprint
Migration
Runbook
Migration
Runbook
Migration
Runbook
Architecture
Service
Migration
Service
Adoption
Service
Architecture
Service
Architecture
Service
Advisory
Service