---
title: Relocate
description: Relocate überführt bestehende Virtualisierungs-Stacks mit minimalem Redesign nach STACKIT, wenn Geschwindigkeit und geringe Veränderung im Vordergrund stehen.
sidebar:
  label: Relocate
  order: 1
source_url: "https://framework.stackit.cloud/de/migration/design-and-mobilize/design/relocate/"
source_file: "docs/de/migration/design-and-mobilize/design/relocate.mdx"
---

## Überblick: Relocate

Relocate verschiebt Workloads mit minimalen Architektur-Änderungen in ein STACKIT-kompatibles Zielsetup.
Im Fokus steht eine schnelle und risikoarme Überführung, nicht die sofortige cloud-native Modernisierung.

Konkret bedeutet Relocate: Das bestehende VM-Betriebsmuster bleibt weitgehend erhalten. Geändert wird
vor allem der Zielstandort inklusive Plattformkontrollen, nicht das Laufzeitmodell der Workloads.

## Relocate vs. Rehost in STACKIT

Relocate und Rehost sind beide Low-Change-Pfade, unterscheiden sich aber in Tiefe und Zielbild der
Migration.

- **Relocate in STACKIT**: Fokus auf Überführung bestehender VM-zentrierter Landschaften in ein
  kompatibles STACKIT Zielsetup mit möglichst wenig Umformung.
- **Rehost in STACKIT**: Fokus auf anwendungsbezogenen Lift-and-Shift mit klarer Zielabbildung,
  Cutover-Design und standardisierten Runbooks für den Factory-Betrieb.
- **Betriebliche Konsequenz**: Relocate ist oft der schnellste Weg für Estate-Movement, Rehost ist oft
  der klarere Weg für wiederholbare Wellenumsetzung je Anwendung.
- **Planerische Konsequenz**: Relocate bei Priorität auf Erhalt bestehender Betriebsmuster,
  Rehost bei Priorität auf standardisierte Migration über viele Anwendungen.

## Vorgehensvarianten bei Relocate

Relocate kann in zwei operativen Varianten umgesetzt werden, je nach Estate-Grösse,
Unterschiedlichkeit und Cutover-Risiko.

- **Tool-gestütztes Relocate**: Bevorzugt in Large-Scale-Programmen, wenn Durchsatz,
  Konsistenz und ein wiederholbarer Ablauf der Wellen im Fokus stehen.
- **Kontrolliertes manuelles Relocate**: Sinnvoll für kleinere oder besondere Workloads,
  die eine engere manuelle Steuerung brauchen.
- **Gemeinsame Qualitätsanforderungen**: Beide Varianten brauchen dieselben Cutover-Kontrollen,
  Rollback-Logik und Day-1-Betriebsreife.

## Wann Relocate sinnvoll ist

- **Zeitkritische Transition**: Strikte Exit-Termine oder Vorgaben zur Datenlokation.
- **Geringe Veränderungstoleranz**: Fachbereiche können aktuell keine größeren Umbauten tragen.
- **Stabile Bestands-Workloads**: VM-basierte Muster sind bekannt und betrieblich beherrscht.
- **Spätere Modernisierung geplant**: Replatform/Refactor ist als Folgeschritt vorgesehen.

## Design-Aspekte im STACKIT-Kontext

<CardGrid>
  <Card title="Landing-Zone-Kompatibilität">
    Netzwerksegmentierung, IAM-Modell und Security Controls vor der Migration verifizieren.
  </Card>
  <Card title="Sizing und Performance">
    VM-Sizing und Storage-Profile neu baseline, um Überprovisionierung zu vermeiden.
  </Card>
  <Card title="Betriebliche Kontrollen">
    Monitoring-, Backup- und Recovery-Kontrollen ab Tag 1 im Ziel sicherstellen.
  </Card>
  <Card title="Umgang mit grossen Datenmengen">
    Für sehr grosse VM-Datenbestände Pre-Seeding, Delta-Sync-Fenster und Bandbreitensteuerung vorab
    festlegen, um Cutover-Downtime zu begrenzen.
  </Card>
  <Card title="Pfad für spätere Modernisierung">
    Klare Trigger für spätere Replatform/Refactor-Entscheidungen dokumentieren.
  </Card>
</CardGrid>

## Datenmigration bei Relocate

Bei Relocate ist die Datenmigration oft implizit gelöst, weil die gesamte VM inklusive Storage verschoben wird.
Trotzdem sollten bei großen Datenmengen explizite Design-Entscheidungen getroffen werden:

- **Anbindung im Netzwerk**: End-to-End-Durchsatz, Latenz und Stabilität des Pfads für den Transfer im Fenster der Migration verifizieren.
- **Storage-Klasse**: Quell- und Ziel-Storage-Klassen vor dem Cutover auf erforderliche IOPS-/Throughput-Profile abstimmen.
- **Pre-Seeding**: Daten möglichst vor dem Cutover übertragen.
- **Delta-Synchronisation**: Im finalen Fenster nur die letzten Änderungen nachziehen.
- **Integritätsprüfung**: Prüfsummen und Stichproben-Reads für migrierte Volumes definieren.
- **Rollback-Checkpoints**: Quell-Snapshots bis zur Abnahme im Ziel vorhalten.

## Empfohlener Design-Ablauf

<Steps>

1. Workload-Abhängigkeiten und betriebliche Rahmenbedingungen bestätigen.
2. Zielabbildung in STACKIT inklusive Netzwerk- und Security-Vorgaben definieren.
3. Migrationssequenz, Downtime-Annahmen und Rollback-Modell entwerfen.
4. Betriebsbereitschaft (Monitoring, Backup, Incident-Prozess) validieren.
5. Optimierungs-Backlog für die Zeit nach der Überführung festlegen.

</Steps>

## Erforderliche Ergebnisse

### Gemeinsame Ergebnisse für alle Migrationspfade

- Freigegebener Design-Entscheidungsnachweis mit Scope, Annahmen und Governance-Sign-off.
- Validierungsnachweise für Security, Compliance und Betriebsbereitschaft.
- Entwurf des Migrations-Runbooks je Strategie aus der Design-Phase.
- Übergabepaket für Migration Factory Setup und Wellenplanung.

### Relocate-spezifische Ergebnisse

- Relocate-Entscheidungsnachweis mit Trade-offs und Exit-Kriterien.
- Zielabbildung pro Workload.
- Cutover- und Rollback-Design.
- Day-1-Betriebscheckliste.
- Post-Relocate-Optimierungs-Backlog.

## Diagramm-Schrittreferenz

### Define Landing Zone

Landing-Zone-Vorgaben für die Relocate-Welle als Startpunkt der Ausführung festlegen.
Account-Struktur, Netzwerksegmentierung und Basis-Kontrollen so abstimmen, dass bestehende
VM-Betriebsmuster ohne Governance-Verstöße übertragen werden können.

- <LinkChip href="/de/migration/design-and-mobilize/landing-zones/overview/">Landing Zones: Übersicht</LinkChip>
- <LinkChip href="/de/migration/design-and-mobilize/landing-zones/platform-landing-zone/">Platform Landing Zone</LinkChip>
- <LinkChip href="/de/migration/design-and-mobilize/landing-zones/application-landing-zone/">Application Landing Zone</LinkChip>

### Use migration tools

Tool-gestützten Vorgehenspfad für skalierbare, wiederholbare Relocate-Wellen festlegen.
Ausführungsrollen, Batches und Rollback-Checkpoints früh festlegen, damit große VM-Landschaften
konsistent über mehrere Wellen hinweg übertragen werden.

- <LinkChip href="/de/migration/design-and-mobilize/migration-factory-setup/overview/">Migration Factory Setup: Übersicht</LinkChip>
- <LinkChip href="/de/migration/design-and-mobilize/migration-factory-setup/tooling-and-automation/">Tooling und Automatisierung</LinkChip>
- <LinkChip href="/de/migration/design-and-mobilize/migration-factory-setup/scope-timeline-and-communications/">Scope, Timeline und Communication</LinkChip>

<ScfAssetLoader
  showFilter={false}
  showSearch={false}
  frameworkSlug="migration"
  filterByTag="relocate"
/>

### Install

Manuelle Installationsschritte für nicht tool-gestützte Ausnahme-Workloads beschreiben.

- **Ziel-VM und Storage vorbereiten**: Ziel-VM erstellen, erforderliche Disks anbinden und CPU-/Memory-Sizing anhand gemessener Werte aus der Quelle ausrichten.
- **Erforderliche Basis-Komponenten installieren**: Hypervisor-Guest-Tools, OS-Pakete und Runtime-Voraussetzungen einrichten, damit der Workload stabil starten kann.
- **Workload-Artefakte übertragen**: Disk-Images, Boot-Dateien und Service-Units/Skripte über einen kontrollierten Transfer-Pfad kopieren.
- **Boot- und Host-Baseline prüfen**: Erfolgreichen Boot, Dateisystem-Mount-Integrität und Kernnetzwerk-Erreichbarkeit vor der Konfiguration verifizieren.

- <LinkChip href="/de/migration/design-and-mobilize/design/runbook/">Runbook Blueprint</LinkChip>
- <LinkChip href="/de/migration/design-and-mobilize/design/cloud-design-patterns/">Cloud-Design-Patterns</LinkChip>

### Config

Manuelle Konfiguration und den Abgleich der Parameter im Ziel festlegen.

- **System- und Parameter der Anwendung angleichen**: Hostname, DNS, Synchronisierung der Zeit und Umgebungswerte gemäß Workload-Anforderungen setzen.
- **Security- und Zugriffsmodell konfigurieren**: Regeln für Zugriffe, Service-Credentials und administrative Grenzen für den Betrieb im Ziel anwenden.
- **Betriebs-Basis aktivieren**: Monitoring-Agenten, Log-Forwarding, Backup-Jobs und Restore-Test-Hooks einrichten.
- **Konfigurationsparität prüfen**: Wichtige Runtime-Parameter mit der Basis der Quelle vergleichen und akzeptierte Abweichungen dokumentieren.

- <LinkChip href="/de/migration/design-and-mobilize/design/runbook/">Runbook Blueprint</LinkChip>
- <LinkChip href="/de/migration/design-and-mobilize/migration-plan/overview/">Migrationsplan</LinkChip>

### Deploy

Manuelle Deployment-Reihenfolge und Handover-Checks definieren.

- **Cutover-Sequenz ausführen**: Schreibzugriffe auf die Quelle stoppen, finalen Delta-Sync fahren und den Ziel-Workload in der freigegebenen Reihenfolge aktivieren.
- **Verhalten des Service validieren**: Smoke- und Critical-Path-Tests inklusive Konnektivität zu abhängigen Systemen durchführen.
- **Stabilisieren und überwachen**: Schlüsselmetriken, Fehlerraten und Betriebs-Alarme während des vereinbarten Hypercare-Fensters beobachten.
- **Ownership-Übergang abschließen**: Support-Verantwortung, Eskalationswege und Rollback-Abschlusskriterien verbindlich bestätigen.

- <LinkChip href="/de/migration/design-and-mobilize/migration-plan/overview/">Migrationsplan</LinkChip>
- <LinkChip href="/de/migration/design-and-mobilize/design/runbook/">Runbook Blueprint</LinkChip>

### Validation handover

Festlegen, wie Relocate-Ergebnisse in das gemeinsame Validation-Gate einfliessen.
Technische Evidenz, aktualisierte Risiko-Logs und operativen Abnahme-Status bündeln, damit die
Wellen-Governance Entscheidungen ohne Rework treffen kann.

- <LinkChip href="/de/migration/design-and-mobilize/migration-factory-setup/runbook-readiness/">Runbook-Readiness</LinkChip>
- <LinkChip href="/de/migration/design-and-mobilize/migration-plan/overview/">Migrationsplan</LinkChip>