---
title: Rehost Spring Boot Service auf VM
description: "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."
sidebar:
  badge:
    text: "STACKIT"
    variant: success
scfAsset:
  managed: false
  category: "runbook"
  external: false
  tags: ["design-and-mobilize", "design", "runnable-example", "rehost", "spring-boot", "migration", "vm"]
  maintainers:
    - user: "lukas.weberruss"
      role: true
      website: true
source_url: "https://framework.stackit.cloud/de/migration/assetcontainer/stackit/runbook-rehost-spring-boot/"
source_file: "docs/de/migration/assetcontainer/stackit/runbook-rehost-spring-boot.mdx"
---

## Use Case

- **Migrationsstrategie:** Rehost (Lift-and-Shift)
- **Anwendungstyp:** Spring-Boot-Service (JAR), kein Kubernetes-Ziel
- **Zielplattform:** VM-basierter Runtime-Betrieb auf STACKIT
- **Daten-Backend:** PostgreSQL

## Scope und Annahmen

- **In Scope:** Terraform-Provisioning, Ansible-Konfiguration, Quelldump-Nachweise, Probe in einer
  temporären Datenbank, kontrollierter Restore, Laufzeitvalidierung, Rollback, Observability und
  Server-Backup-Zeitplan.
- **Out of Scope:** Code-Refactoring, Wechsel der Datenbank-Engine, Load Balancing, DNS-Switch,
  TLS-Terminierung, Multi-VM-Verfügbarkeit, Kubernetes, Cloud Foundry und PostgreSQL Flex.
- **Annahmen:** Die Quelle verwendet eine PostgreSQL-Version, die mit den Restore-Werkzeugen im Ziel
  kompatibel ist; freigegebene Quell-CIDRs für SSH und Applikationszugriff sind bekannt.

## Rollen und Ownership

- **Migrationsleitung:** Steuert Zeitplan, Checkpoints und Go/No-Go-Entscheidung.
- **Application Owner:** Validiert das Verhalten der Anwendung und business-kritische User Journeys.
- **Platform Engineer:** Bereitet VM, eingeschränkte Netzwerkregeln, Monitoring und Backup-Zeitplan vor.
- **DB Owner:** Führt DB-Backup, Restore, Konsistenzprüfungen und Rollback-Trigger aus.
- **Operations Owner:** Übernimmt den Handover und verantwortet Day-1/Day-2 Incident Response.

## Pre-Migration-Checks

- **Access Readiness:** SSH, Deployment-Credentials, DB-Zugriff und Secrets-Zugriff sind validiert.
- **Baseline erfasst:** Aktuelle Versionen, Umgebungsvariablen, Ports, Zertifikate und geplante Jobs sind dokumentiert.
- **Kapazität validiert:** CPU, RAM, Disk-IOPS und Storage auf der Ziel-VM sind bestätigt.
- **Security-Controls bereit:** Firewall-Regeln, IAM-Mapping, TLS-Chain und Logging sind aktiv.
- **Quelldaten bereit:** Dump-Prüfsumme, erwartete Datensatzanzahl und deterministischer Daten-Fingerprint sind erfasst.
- **Rollback-Readiness:** Dump von vor dem Restore, erwartete ursprüngliche Datensatzanzahl,
  Entscheidungsbefugnis und Deadline sind abgestimmt.

## Run-Plan (Cutover-Fenster)

### Phase 1: Ziel-Runtime vorbereiten

1. Ziel-App-User und benötigte Filesystem-Struktur anlegen.
2. Java-Runtime und unterstützende OS-Pakete installieren.
3. App-Artefakt in das Ziel-Verzeichnis deployen.
4. Service-Unit (systemd) und Environment-Datei konfigurieren.
5. Selbstverwaltetes PostgreSQL installieren, Application Role und Datenbank erstellen und den Zugriff auf localhost beschränken.
6. Node Exporter, Observability Scraping und Server-Backup-Zeitplan aktivieren.

### Phase 2: Daten- und Konfigurationsabgleich

1. PostgreSQL-Dump im Custom Format ohne Ownership und Privileges der Quelle erstellen.
2. Prüfsumme, erwartete Datensatzanzahl und deterministischen Fingerprint erfassen und validieren.
3. `./scripts/run_migration_rehearsal.sh` gegen eine temporäre Zieldatenbank ausführen.
4. Bestätigen, dass die Probe ihre temporäre Datenbank entfernt und die produktive Zieldatenbank nicht verändert hat.
5. Den ursprünglichen Ziel-Rollback-Dump in einer separaten temporären Datenbank prüfen.

### Phase 3: Cutover und Release

1. Schreibzugriffe auf der Quelle einfrieren und den finalen freigegebenen Dump erstellen.
2. `./scripts/run_cutover.sh --confirm` mit den freigegebenen Quelldaten ausführen.
3. Verlangen, dass der gespeicherte Terraform-Plan ausschließlich die Ansible-Orchestrierungsressource ändert.
4. Datensatzanzahl, Fingerprint, Ownership, Schreibverhalten der Application Role, Services und Endpunkt validieren.
5. Abschließenden Terraform-No-op-Plan verlangen, Abnahme dokumentieren und Stabilisierungsbeobachtung starten.

## Validierungscheckliste

- **Technische Gesundheit:** Spring Boot, PostgreSQL und Node Exporter sind aktiv; lokale und freigegebene öffentliche HTTP-Checks sind erfolgreich.
- **Funktionale Checks:** Die Anwendung liefert die migrierten Spring-Music-Datensätze.
- **Datenprüfungen:** Erwartete Datensatzanzahl und Fingerprint stimmen; Tabellen gehören der Application Role.
- **Security-Checks:** Runtime Environment und Rollback-Dump sind nur für root beziehungsweise den Datenbank-Owner lesbar.
- **Operations-Checks:** Observability Scrape, Server-Backup-Zeitplan, Nachweisdateien und Eskalations-Ownership sind geprüft.

## Rollback-Kriterien und Schritte

### Rollback-Trigger

- **Kritischer funktionaler Fehler:** Kern-Business-Flow ist nach Fix-Fenster nicht verfügbar.
- **Datenintegritätsrisiko:** Abweichung in kritischen Datensätzen ohne schnelle Remediation.
- **Betriebliche Instabilität:** Wiederholte Restarts oder nicht aufgelöste kritische Alerts.

### Rollback-Schritte

1. Freigegebene Rollback-Entscheidung vor der Deadline auslösen und Logs sowie Nachweise sichern.
2. `./scripts/rollback_postgresql.sh --confirm` ausführen, um Spring Boot zu stoppen und die aktuelle Zieldatenbank zu bewahren.
3. Geschützten Dump von vor dem Cutover wiederherstellen und die erwartete ursprüngliche Datensatzanzahl validieren.
4. Spring Boot neu starten und lokale sowie freigegebene öffentliche Erreichbarkeit validieren.
5. Vereinbarten Betriebszustand von Quelle oder Ziel wieder aufnehmen und Rollback-Nachweis sowie Entscheidung veröffentlichen.

## Handover an Operations

- **Übergabe-Artefakte:** Finales Konfigurationspaket, Deployment-Manifest, Validierungsnachweise, Rollback-Log.
- **Ownership-Transfer:** Benannter On-Call-Owner und Eskalationsweg sind bestätigt.
- **Stabilisierungsphase:** 24-72 Stunden mit erhöhtem Monitoring und täglicher Statusprüfung.
- **Exit-Kriterien:** Keine kritischen Alerts, stabile zentrale Metriken und Business-Owner-Sign-off.

## Nachweisprotokoll-Vorlage

| Checkpoint                      | Owner                   | Timestamp        | Ergebnis  | Evidence Link |
| ------------------------------- | ----------------------- | ---------------- | --------- | ------------- |
| Ziel-VM-Runtime vorbereitet     | Platform Engineer       | YYYY-MM-DD HH:MM | Pass/Fail | link          |
| Probe abgeschlossen             | DB Owner                | YYYY-MM-DD HH:MM | Pass/Fail | link          |
| DB-Restore und Integritätscheck | DB Owner                | YYYY-MM-DD HH:MM | Pass/Fail | link          |
| Terraform-No-op bestätigt       | Platform Engineer       | YYYY-MM-DD HH:MM | Pass/Fail | link          |
| Post-Cutover Business-Checks    | Application Owner       | YYYY-MM-DD HH:MM | Pass/Fail | link          |
| Handover akzeptiert             | Operations Owner        | YYYY-MM-DD HH:MM | Pass/Fail | link          |