Skip to content
Beta

Migrate

In 4 trails

Last updated on

This module executes the actual migration delivery in the Migration Factory. By this point, design decisions are approved, landing zones are ready, and wave plans are defined.

Migrate focuses on repeatable technical run patterns for:

  • Relocate: Move workloads with minimal change in platform assumptions.
  • Rehost: Lift and shift workloads to STACKIT with controlled cutover and rollback readiness.
  • Replatform: Apply targeted platform changes during migration without a full application redesign.

Migrate starts after Design and Mobilize has produced implementable inputs:

  • Application design per workload: Target-state scope, interface decisions, data handling, and non-functional requirements are defined.
  • Wave assignment: Every workload is assigned to an approved migration wave with timing and dependency logic.
  • Runbook availability: A validated runbook exists per migration path and workload archetype, including go/no-go, cutover, and rollback criteria.
  • Application Landing Zone mapping: Workloads are mapped to the correct target landing zone and ownership model.
  • Decision and communication model: Decision paths, escalation process, and communication with the Application Owner are defined, including whether cutover must be performed jointly.

Reference modules:

  1. Confirm wave scope, cutover window, rollback criteria, and runbook ownership.
  2. Freeze wave baseline (application version, dependencies, data scope, and interface contracts).
  3. Run pre-migration technical readiness checks in source and target environments.
  4. Run migration runbook steps per workload archetype and R-strategy path.
  5. Perform cutover and route traffic to the STACKIT target according to the wave plan.
  6. Validate technical, functional, and operational acceptance criteria.
  7. Stabilize incidents and known defects in short feedback loops.
  8. Hand over stabilized workloads to Optimize and Operate.
  1. Recreate workload placement in STACKIT with equivalent topology assumptions.
  2. Migrate data and state with consistency checks.
  3. Cut over traffic with rollback guardrails.
  4. Validate business continuity and operational telemetry.
  1. Move application and data components largely unchanged.
  2. Reconfigure infrastructure bindings and connectivity on STACKIT.
  3. Run controlled cutover and smoke tests.
  4. Complete stabilization and baseline performance validation.
  1. Introduce selected managed services or platform capabilities during migration.
  2. Adapt configuration, deployment packaging, and operational controls.
  3. Cut over with compatibility and data integrity checks.
  4. Validate SLO behavior and operating model readiness.

Runbook evidence

Completed runbook records, decision logs, and rollback checkpoints for each migrated workload.

Cutover report

Time-stamped cutover outcome with acceptance results, defects, and mitigation actions.

Operational baseline

Initial monitoring, alerting, ownership, and incident procedures in the target setup.

Optimize backlog

Structured list of rightsizing, performance, and cost measures for post-cutover tuning.

Boundary to optimize, repurchase, and refactor

Section titled “Boundary to optimize, repurchase, and refactor”
  • Optimize starts directly after stable cutover and uses production telemetry to tune performance and cost: Optimize.
  • Repurchase follows a different SaaS transition logic and is treated as a dedicated module outside wave-based factory mechanics: Repurchase.
  • Refactor is typically run as a separate transformation stream: Refactor.

Post-cutover care can overlap with Optimize after cutover, but it is handled in the Run phase.