Skip to content
Beta

Relocate

In 1 trail

Last updated on

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

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

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:

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

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.

Asset title
Framework
Asset type

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

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

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

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.