---
title: Rehost
description: Rehost migriert Anwendungen mit minimalen Code-Änderungen und priorisiert Migrationsgeschwindigkeit, Betriebskontinuität und planbaren Wellen-Durchsatz.
sidebar:
  label: Rehost
  order: 2
source_url: "https://framework.stackit.cloud/de/migration/design-and-mobilize/design/rehost/"
source_file: "docs/de/migration/design-and-mobilize/design/rehost.mdx"
---

## Überblick: Rehost

Rehost (lift-and-shift) migriert Workloads mit möglichst geringer Anwendungsänderung.
Die Strategie reduziert Übergangsrisiken und beschleunigt den Umsetzungsdurchsatz.

Konkret ist Rehost anwendungs- und wellenorientiert: Für jeden Workload werden Zielabbildung,
Cutover-Pfad und Runbook-Paket für eine wiederholbare Factory-Ausführung festgelegt.

## Rehost vs. Relocate in STACKIT

Relocate und Rehost werden oft gleich verwendet, sind in diesem Framework jedoch bewusst getrennt.

- **Rehost in STACKIT**: Anwendungsbezogener Lift-and-Shift mit klarer Zielabbildung,
  Cutover-/Rollback-Logik und standardisierten Runbooks.
- **Relocate in STACKIT**: Überführung bestehender Virtualisierungs-Muster mit minimaler Umformung
  des bestehenden Laufzeitverhaltens.
- **Wann Rehost bevorzugt wird**: Wenn Wellen über viele Anwendungen mit einheitlicher Runbook-Qualität
  und stabiler Ausführung geplant sind.
- **Wann Relocate bevorzugt wird**: Wenn schnelle Estate-Überführung Priorität hat und Modernisierung
  bewusst später erfolgt.

## Wann Rehost sinnvoll ist

- **Strenger Zeitrahmen** bei begrenzter Engineering-Kapazität.
- **Legacy-Workloads**, die aktuell schwer zu refactoren sind.
- **Priorität auf Stabilität** bei möglichst unverändertem Fachverhalten.
- **Factory-Skalierung** mit wiederholbaren Migrationsabläufen über viele Systeme.

## Design-Aspekte im STACKIT-Kontext

<CardGrid>
  <Card title="Infrastruktur-Abbildung">
    Zielprofile für Compute, Storage und Netzwerk mit Kompatibilitätsprüfung definieren.
  </Card>
  <Card title="Daten- und Cutover-Pfad">
    Transferfenster, Konsistenzchecks und Rollback-Trigger entwerfen.
  </Card>
  <Card title="Stateful-Workload-Handling">
    Applikations-Deployment und Datenbankmigration als getrennte, aber abgestimmte Streams
    sequenzieren.
  </Card>
  <Card title="Security und Compliance">
    Identitätskontrollen, Verschlüsselungsanforderungen und Nachweis-Checkpoints abbilden.
  </Card>
  <Card title="Operatives Handover">
    Runbooks für Day-1-Betrieb und Incident-Ablaufe nach der Migration sicherstellen.
  </Card>
</CardGrid>

## Empfohlener Design-Ablauf

<Steps>

1. Laufzeitabhängigkeiten und nicht-funktionale Anforderungen baseline.
2. Zielabbildung und Migrationssequenz definieren.
3. Datenumzug und Cutover-Orchestrierung entwerfen.
4. Runbook-Qualität mit Dry-Run-Checkpoints validieren.
5. Produktive Migration mit Release- und Business-Sign-off freigeben.

</Steps>

## Datenmigrationspfad bei Rehost

In Rehost-Szenarien hängt der Datenmigrationspfad davon ab, ob der Workload zustandslos (stateless) oder zustandsbehaftet (stateful) ist:

- **Stateless-Workloads**: Fokus auf Anwendungs-Deployment und Konfiguration.
- **Stateful-Workloads**: Erfordern eine koordinierte Datenverschiebungs-Strategie parallel zur Anwendungsmigration.

Für zustandsbehaftete Migrationswellen empfiehlt sich eine Trennung in zwei Streams:

1. **Infrastruktur- und Anwendungs-Stream**: Zielumgebung bereitstellen, Anwendung bereitstellen und Zieldatenspeicher vorbereiten.
2. **Daten-Stream**: Quelldaten exportieren, zum Ziel übertragen, wiederherstellen und validieren.

### Empfohlene Datensequenz

1. Quelldaten mit plattformnativen oder werkspezifischen Methoden exportieren.
2. Daten in die Zielumgebung oder einen Zwischenspeicher übertragen.
3. Zielumgebung für den Import der migrierten Daten konfigurieren.
4. Wiederherstellungsprozess ausführen und Datenintegrität verifizieren.
5. Anwendungskonnektivität und funktionales Verhalten vor der endgültigen Umschaltung validieren.

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

### Rehost-spezifische Ergebnisse

- Rehost-Entscheidungsbegründung und Randbedingungen.
- Zielabbildung der Laufzeit.
- Datenumzugs- und Cutover-Plan.
- Runbook mit Validierungs- und Rollback-Checkpoints.
- Stabilisierungsliste nach der Welle.

## Diagramm-Schrittreferenz

### Define Landing Zone

Landing-Zone-Anforderungen und Controls als Startpunkt der Rehost-Ausführung festlegen.
Netzwerk-, Identitäts-, Backup- und Monitoring-Voraussetzungen vor der Abfolge der Migration
verbindlich festlegen, damit Rehost-Wellen mit planbarer Betriebsqualität umgesetzt werden.

- <LinkChip href="/de/migration/design-and-mobilize/landing-zones/overview/">Landing Zones: Übersicht</LinkChip>
- <LinkChip href="/de/migration/design-and-mobilize/landing-zones/application-landing-zone/">Application Landing Zone</LinkChip>
- <LinkChip href="/de/migration/design-and-mobilize/design/cloud-design-patterns/">Cloud-Design-Patterns</LinkChip>

### Use migration tools

Automatisierten Rehost-Pfad für wiederholbaren Wellen-Durchsatz definieren.
Im automatisierten Rehost-Pfad werden Infrastruktur und Anwendung als Code bereitgestellt, damit
Wellen reproduzierbar und auditierbar umgesetzt werden können.

- **VM-Ziel über IaC bereitstellen**: Netzwerk, Security-Gruppen, Compute-Instanzen und Basis-Storage mit Terraform oder OpenTofu aufbauen.
- **Anwendung automatisiert installieren und konfigurieren**: Ansible-Playbooks für die Installation von Paketen, Service-Setup und Basiskonfiguration verwenden.
- **Parameter der Zielumgebung kontrolliert anwenden**: Variablen im Ziel, Secret-Referenzen und Endpoint-Mappings in einem gesteuerten automatisierten Lauf einspielen.
- **Automatisierte Validierungs- und Cutover-Gates ausführen**: Health-Checks, Migrations-Pre-Checks, Rollback-Checkpoints und Release-Freigaben vor Live-Switch durchführen.

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

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

Das Runbook-Asset beschreibt die PostgreSQL-Flags und den optionalen Dump-basierten Restore-Pfad.

### Install

Manuelle Installations-Schritte für Ausnahme-Workloads beschreiben.

- **Ziel-VM manuell erstellen und vorbereiten**: VM über Portal oder CLI bereitstellen, erforderlichen Storage anbinden und OS-Hardening sowie Patch-Baseline anwenden.
- **Runtime und Abhängigkeiten manuell installieren**: Benötigte Runtime-Pakete, System-Bibliotheken und Service-User/-Gruppen gemäß Anleitung zur Installation des Produkts einrichten.
- **Anwendung klassisch installieren**: Geführte Installationsschritte (zum Beispiel Installer- oder Setup-Wizard-Ablauf) ausführen, um das Quell-Deployment-Modell auf der Ziel-VM nachzubilden.
- **Status der Installation validieren**: Service-Start, Rechte auf Dateien, erforderliche Ports, DNS-Erreichbarkeit und ausgehende Konnektivität prüfen.

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

### Config

Manuelle Konfiguration der Laufzeit und Controls festlegen.

- **Konfiguration der Quelle für den Kontext im Ziel spiegeln**: Einstellungen der Anwendung aus der Umgebung der Quelle nachbilden und auf Ziel-Endpoints, DNS, Zertifikate und Service-Integrationen anpassen.
- **Security- und Einstellungen für Zugriffe anwenden**: Service-Credentials, Secret-Handling und Least-Privilege-Zugriffe für den Betrieb im Ziel konfigurieren.
- **Standards für den Betrieb ausrichten**: Logging-Ziele, Metrics-Exporter, Backup-Zeitpläne und Retention-Baselines festlegen.
- **Konfigurationsparität validieren**: Smoke-Checks ausführen, damit die Zielinstanz funktional dem Quellbaseline-Verhalten entspricht.

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

### Deploy

Manuelle Deployment-Sequenz und Release-Checks definieren.

- **Finales Zeitfenster für die Migration planen**: Freeze-Fenster, Kommunikations-Checkpoints und Rollback-Autorität für den Wechsel in den Produktivbetrieb abstimmen.
- **Finale Datenmigration ausführen**: Letzten Abgleich der Daten oder Restore-Schritte fahren und Konsistenzprüfungen vor Go-live bestätigen.
- **Live-Verkehr aktivieren**: Kontrollierte Live-Schaltung auf die Zielumgebung durchführen und kritische Nutzer- sowie Integrationspfade prüfen.
- **Handover-Bereitschaft bestätigen**: Nachweise dokumentieren, offene Risiken schließen und Ownership für Day-1-Betrieb übergeben.

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