Rehost

Ü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

Infrastruktur-Abbildung

Zielprofile für Compute, Storage und Netzwerk mit Kompatibilitätsprüfung definieren.

Daten- und Cutover-Pfad

Transferfenster, Konsistenzchecks und Rollback-Trigger entwerfen.

Stateful-Workload-Handling

Applikations-Deployment und Datenbankmigration als getrennte, aber abgestimmte Streams sequenzieren.

Security und Compliance

Identitätskontrollen, Verschlüsselungsanforderungen und Nachweis-Checkpoints abbilden.

Operatives Handover

Runbooks für Day-1-Betrieb und Incident-Ablaufe nach der Migration sicherstellen.

Empfohlener Design-Ablauf

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.

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.

• Landing Zones: Übersicht
• Application Landing Zone
• Cloud-Design-Patterns

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.

• Runbook Blueprint
• Migrationsplan

Asset-Titel

Framework

Asset-Typ

Runbook

Rehost Spring Boot mit Observability und VM-Rightsizing optimieren

STACKIT

Migration migrate optimize rehost observability +2

Open Source In 2 Trails

Praktisches Optimize-Runbook für einen Rehost-Spring-Boot-Workload auf STACKIT mit managed Observability-Signalen und kontrolliertem VM-Rightsizing per IaC.

Climb log

• Sharp summary The description has 120 to 160 characters: enough to say what the page offers, short enough that the card shows all of it
• Well tagged 6 tags make it easy to find in the explorer
• On the route Part of 2 active trail journeys

Rehost Spring Boot mit Observability und VM-Rightsizing optimieren

Migration

Runbook

Runbook

Rehost Spring Boot Service auf VM

STACKIT

Migration design-and-mobilize design runnable-example rehost +3

Open Source In 2 Trails

Ausführbares Migrations-Runbook für den Rehost eines Spring-Boot-JARs und PostgreSQL auf eine STACKIT VM mit Probe, nachweisbasiertem Cutover, Validierung und Rollback.

Climb log

• Well tagged 7 tags make it easy to find in the explorer
• On the route Part of 2 active trail journeys

Rehost Spring Boot Service auf VM

Migration

Runbook

Blueprint

Spring Boot hybrid access with VPN and central firewall

STACKIT

Migration design-and-mobilize design target-architecture rehost +4

Open Source

Referenzarchitektur für Spring Boot auf STACKIT mit hybrider Anbindung über VPN und zentraler Firewall-Inspektion im Hub-and-Spoke-Modell für Migration.

Climb log

• Sharp summary The description has 120 to 160 characters: enough to say what the page offers, short enough that the card shows all of it
• Well tagged 8 tags make it easy to find in the explorer

Spring Boot hybrid access with VPN and central firewall

Migration

Blueprint

Runbook

Spring Boot mit Terraform und Ansible rehosten

STACKIT

Migration design-and-mobilize design runnable-example rehost +4

Open Source In 2 Trails

Ausführbare Rehost-Automatisierung für ein Spring-Boot-JAR auf einer STACKIT VM mit lokalem PostgreSQL, geprobtem Cutover, Rollback-Nachweisen, Observability und Server Backup.

Climb log

• Well tagged 8 tags make it easy to find in the explorer
• On the route Part of 2 active trail journeys

Spring Boot mit Terraform und Ansible rehosten

Migration

Runbook

Blueprint

Spring Boot und PostgreSQL auf einer VM mit Observability und Backup

STACKIT

Migration design-and-mobilize design target-architecture rehost +5

Open Source In 2 Trails

Validierte Rehost-Architektur für ein Spring-Boot-JAR und selbstverwaltetes PostgreSQL auf einer STACKIT VM mit eingeschränktem Ingress, Observability und Server Backup.

Climb log

• Well tagged 9 tags make it easy to find in the explorer
• On the route Part of 2 active trail journeys

Spring Boot und PostgreSQL auf einer VM mit Observability und Backup

Migration

Blueprint

Runbook

VM-Anwendungsmigration mit kontrolliertem Cutover

STACKIT

Migration design-and-mobilize use-cases app-stack rehost +1

Open Source

Runbook-Vorlage für die Migration einer Anwendung mit VM-Runtime auf STACKIT mit klaren Voraussetzungen, Cutover-Governance und definierten Rollback-Grenzen.

Climb log

• Sharp summary The description has 120 to 160 characters: enough to say what the page offers, short enough that the card shows all of it
• Well tagged 5 tags make it easy to find in the explorer

VM-Anwendungsmigration mit kontrolliertem Cutover

Migration

Runbook

Anleitung

MI1: Rehost- und Replatform-Guide

STACKIT

Migration design-and-mobilize design rehost replatform +2

Managed Asset Marketplace

Technische Anleitung für Rehost und Replatform bestehender On-Premise-Workloads nach STACKIT mit Tooling, Reihenfolge und Validierung für planbaren Cutover.

Climb log

• Sharp summary The description has 120 to 160 characters: enough to say what the page offers, short enough that the card shows all of it
• Well tagged 6 tags make it easy to find in the explorer

Gear check

• Marketplace link is a stand-in The pill leads to the product list instead of this entry, so the reader has to search again

MI1: Rehost- und Replatform-Guide

Migration

Anleitung

Owner

Mock

Mock

42 Assets · 19 Trails

true

_

_

_

_

1. _

Hinweis

_

_

Cloud Framework _ Seite öffnen _ _ _

Asset-VerlaufIn 7 von 12 Wochen aktivTMAktualisiertKeine Änderungen · 1 Balken = 1 Woche i

Maintainers

• LWLukas Weberruß · Head of STACKIT Cloud Migration Framework · STACKITOwnerLukas WeberrußHead of STACKIT Cloud Migration Framework · STACKITOwnerIn 10 von 12 Wochen aktiv · 47 Änderungenwww.linkedin.com/in/lukas-weberruß-a360b081

TMTobias M.Head of STACKIT Cloud Framework · STACKITOwnerIn 12 von 12 Wochen aktiv · 168 ÄnderungenSTACKITwww.linkedin.com/in/tobias-müller-011304172LWLukas WeberrußHead of STACKIT Cloud Migration Framework · STACKITOwnerIn 10 von 12 Wochen aktiv · 47 ÄnderungenSTACKITwww.linkedin.com/in/lukas-weberruß-a360b081Beigetragen in STACKIT

• Tobias M.Tobias M.Head of STACKIT Cloud Framework · STACKITOwnerIn 12 von 12 Wochen aktiv · 168 ÄnderungenSTACKITwww.linkedin.com/in/tobias-müller-011304172 · 5. Okt. 2026

• Lukas WeberrußLukas WeberrußHead of STACKIT Cloud Migration Framework · STACKITOwnerIn 10 von 12 Wochen aktiv · 47 ÄnderungenSTACKITwww.linkedin.com/in/lukas-weberruß-a360b081 · 25. Sept. 2026

• Tobias M.Tobias M.Head of STACKIT Cloud Framework · STACKITOwnerIn 12 von 12 Wochen aktiv · 168 ÄnderungenSTACKITwww.linkedin.com/in/tobias-müller-011304172 · 26. Aug. 2026

Vollständigen Verlauf anzeigen (7 weitere)

• Tobias M.Tobias M.Head of STACKIT Cloud Framework · STACKITOwnerIn 12 von 12 Wochen aktiv · 168 ÄnderungenSTACKITwww.linkedin.com/in/tobias-müller-011304172 · 7. Aug. 2026

• Tobias M.Tobias M.Head of STACKIT Cloud Framework · STACKITOwnerIn 12 von 12 Wochen aktiv · 168 ÄnderungenSTACKITwww.linkedin.com/in/tobias-müller-011304172 · 31. Juli 2026

• Tobias M.Tobias M.Head of STACKIT Cloud Framework · STACKITOwnerIn 12 von 12 Wochen aktiv · 168 ÄnderungenSTACKITwww.linkedin.com/in/tobias-müller-011304172 · 31. Juli 2026

• Lukas WeberrußLukas WeberrußHead of STACKIT Cloud Migration Framework · STACKITOwnerIn 10 von 12 Wochen aktiv · 47 ÄnderungenSTACKITwww.linkedin.com/in/lukas-weberruß-a360b081 · 28. Juli 2026

• Lukas WeberrußLukas WeberrußHead of STACKIT Cloud Migration Framework · STACKITOwnerIn 10 von 12 Wochen aktiv · 47 ÄnderungenSTACKITwww.linkedin.com/in/lukas-weberruß-a360b081 · 24. Juli 2026

• Tobias M.Tobias M.Head of STACKIT Cloud Framework · STACKITOwnerIn 12 von 12 Wochen aktiv · 168 ÄnderungenSTACKITwww.linkedin.com/in/tobias-müller-011304172 · 15. Juli 2026

• STACKIT · 7. Juli 2026

Mehr Assets laden

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.

• Cloud-Design-Patterns
• Runbook Blueprint

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.

• Runbook Blueprint

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.

• Migrationsplan
• Runbook Blueprint