Landing zone compatibility
Validate network segmentation, IAM model, and security controls before migration starts.
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 and Rehost are both low-change paths, but they differ in migration depth and adaptation scope.
Relocate can be delivered in two operational variants, depending on estate size, heterogeneity, and cutover risk profile.
Landing zone compatibility
Validate network segmentation, IAM model, and security controls before migration starts.
Performance and sizing
Re-baseline VM sizing and storage profiles to avoid overprovisioning after move.
Operational controls
Preserve monitoring, backup, and recovery controls from day one in the target environment.
Large data volume handling
For very large VM data sets, define pre-seeding, delta-sync windows, and transfer throttle rules before cutover to avoid extended outage windows.
Future modernization path
Record explicit trigger points for follow-up replatform/refactor decisions.
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:
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.
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.




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