--- title: Relocate description: Relocate moves existing virtualization stacks to STACKIT with minimal redesign when speed and low-change delivery are the primary goals. sidebar: label: Relocate order: 1 source_url: "https://framework.stackit.cloud/migration/design-and-mobilize/design/relocate/" source_file: "docs/migration/design-and-mobilize/design/relocate.mdx" --- ## Understanding Relocate Relocate moves workloads with minimal architectural change, typically by transferring virtualization estates to a STACKIT-compatible target setup. The goal is fast transition with controlled risk, not immediate cloud-native modernization. In practical terms, Relocate keeps the existing VM operating pattern largely intact. The main change is the runtime location and surrounding platform controls, not the workload runtime model itself. ## Relocate vs. Rehost in STACKIT Relocate and Rehost are both low-change paths, but they differ in migration depth and adaptation scope. - **Relocate in STACKIT**: Focuses on moving existing VM-centric estates into a compatible STACKIT target with as little workload reshaping as possible. - **Rehost in STACKIT**: Focuses on workload-level lift-and-shift into STACKIT target runtimes, including explicit runtime mapping, cutover design, and runbook standardization for factory scale. - **Operational consequence**: Relocate is usually the fastest path for estate movement, while Rehost is usually the clearer path for repeatable application-wave delivery. - **Planning consequence**: Choose Relocate when preserving current operating patterns is the priority; choose Rehost when migration repeatability across many applications is the priority. ## Delivery variants in Relocate Relocate can be delivered in two operational variants, depending on estate size, heterogeneity, and cutover risk profile. - **Tool-assisted relocate**: Preferred for large-scale migration programs where throughput, consistency, and repeatable wave handling are required. - **Controlled manual relocate**: Suitable for smaller or exceptional workloads that require more manual sequencing. - **Shared quality baseline**: Both variants still require the same cutover controls, rollback design, and Day-1 operations readiness. ## When Relocate is a good fit - **Time-critical transitions**: Exit timelines or data residency deadlines require rapid movement. - **Low change tolerance**: Business cannot absorb major application refactoring in the current phase. - **Known workload behavior**: Existing VM-based patterns are stable and operationally understood. - **Deferred modernization strategy**: Cloud-native optimization is planned as a later wave. ## Design considerations in STACKIT context Validate network segmentation, IAM model, and security controls before migration starts. Re-baseline VM sizing and storage profiles to avoid overprovisioning after move. Preserve monitoring, backup, and recovery controls from day one in the target environment. For very large VM data sets, define pre-seeding, delta-sync windows, and transfer throttle rules before cutover to avoid extended outage windows. Record explicit trigger points for follow-up replatform/refactor decisions. ## Data path guidance in Relocate In Relocate, the data path is often implicit because the full VM (including attached storage) is moved. Even so, large data footprints still require explicit design decisions: - **Network connectivity capacity**: Validate end-to-end throughput, latency, and transfer path stability for the planned migration window. - **Storage class fit**: Align source and target storage classes with required IOPS/throughput characteristics before cutover. - **Pre-seed strategy**: Transfer baseline volumes before cutover where possible. - **Delta synchronization**: Minimize final downtime window by only syncing latest changes during cutover. - **Integrity checks**: Define checksum and sample-read validation for migrated disks. - **Rollback checkpoints**: Keep source snapshot retention until target acceptance is confirmed. ## Recommended design flow 1. Confirm baseline workload dependencies and operational constraints. 2. Define target stack mapping in STACKIT and required network/security controls. 3. Design migration sequence, downtime assumptions, and rollback model. 4. Validate operational readiness (monitoring, backup, incident handling). 5. Document post-move optimization backlog and ownership. ## Required outputs ### Shared outputs across all migration paths - Approved design decision record with scope, assumptions, and governance sign-off. - Validation evidence package for security, compliance, and operational readiness. - Strategy-specific migration runbook draft from the Design phase. - Handover package for Migration Factory Setup and wave planning. ### Relocate-specific outputs - Relocate decision record with trade-offs and exit criteria. - Target stack mapping per workload. - Cutover and rollback design. - Day-1 operations checklist. - Post-relocation optimization backlog. ## Diagram step reference ### Define landing zone Define the target landing zone controls for the Relocate wave before run start. Confirm account boundaries, network segmentation, and baseline controls so existing VM operating patterns can be transferred without violating platform governance. - Landing Zones Overview - Platform Landing Zone - Application Landing Zone ### Use migration tools Define the tool-assisted run path for scalable and repeatable Relocate waves. Set execution roles, migration batches, and rollback checkpoints up front so large VM estates can be moved with consistent controls across waves. - Migration Factory Setup Overview - Tooling and Automation - Scope, Timeline, and Communications ### Install Describe manual installation steps for workloads that are not migrated with tools. Include OS baseline, package dependencies, and host preparation criteria to keep exception paths compatible with standard operations. - **Prepare target VM and storage**: Create target VM, attach required disks, and align CPU/memory sizing with measured source behavior. - **Install required base components**: Install hypervisor guest tools, OS packages, and runtime prerequisites needed to boot and operate the workload. - **Transfer workload artifacts**: Copy disk images, boot files, and service units/scripts using a controlled transfer path. - **Validate boot and host baseline**: Verify successful boot, filesystem mount integrity, and core network reachability before configuration. - Runbook Blueprint - Cloud Design Patterns ### Config Document manual target-side configuration and parameter alignment. Record security policies, IAM assignments, backup defaults, and monitoring baselines so moved workloads are operationally equivalent from day one. - **Align system and application parameters**: Apply hostname, DNS, time sync, and environment settings required by the workload. - **Configure security and access model**: Apply access policies, service credentials, and administrative boundaries for the target environment. - **Enable operations baseline**: Configure monitoring agents, log forwarding, backup jobs, and restore-test hooks. - **Run configuration parity checks**: Compare key runtime parameters with source baseline and document accepted differences. - Runbook Blueprint - Migration Plan ### Deploy Define manual deployment sequencing and handover checks. Define freeze windows, acceptance checks, and ownership transfer steps to prevent ambiguous handover during cutover. - **Execute cutover sequence**: Stop source writes, run final delta sync, and activate the target workload in the approved order. - **Validate service behavior**: Run smoke and critical-path tests, including connectivity to dependent systems. - **Stabilize and monitor**: Observe key metrics, error rates, and operational alerts during the agreed Hypercare window. - **Finalize ownership transfer**: Confirm support responsibilities, escalation paths, and rollback closure criteria. - Migration Plan - Runbook Blueprint ### Validation handover Specify how Relocate outputs enter the common validation gate. Bundle technical evidence, risk log updates, and operational acceptance status so downstream wave governance can decide release without rework. - Runbook Readiness - Migration Plan