---
title: "Rehost to STACKIT: Spring Boot mit Terraform und Ansible"
description: "Migrieren Sie Spring Boot und PostgreSQL auf eine STACKIT-VM mit Terraform und Ansible: Eingaben, Bereitstellung, Probe, Cutover, Abnahme und Betriebsübergabe."
scfTrail:
  tags: [ "rehost", "spring-boot", "postgresql", "terraform", "ansible", "cutover" ]
  maintainers:
    - user: "lukas.weberruss"
      role: true
      website: true
  steps:

    - style: "chairlift"
      id: "confirm-rehost"
      title: "Rehost-Strategie"
      trailContext: "Bestätigen Sie anhand der Discovery-Nachweise, dass das Beibehalten von Spring-Boot-JAR, systemd-Service-Modell und PostgreSQL-Engine auf einer VM die Migrationsziele erfüllt; Kubernetes, Cloud Foundry oder PostgreSQL Flex wären stattdessen Replatform. Leiten Sie daraus die Delivery-Reihenfolge ab: Landing Zone, Terraform-Infrastruktur, Ansible-Konfiguration, separate PostgreSQL-Migration und geprobtes Runbook."
      pageId: "de/migration/design-and-mobilize/design/rehost/#überblick-rehost"
      imageSrc: "de/migration/files/r-strategy-method.svg"
      imageAlt: "R-Strategie-Methode mit Rehost als Lift-and-Shift-Pfad auf Anwendungsebene"

    - style: "chart"
      id: "target-architecture"
      title: "Zielarchitektur"
      trailContext: "Prüfen Sie die resultierende Ein-VM-Baseline: Spring Boot unter systemd, selbstverwaltetes PostgreSQL auf localhost, eingeschränkter Ingress, Observability Scraping und Backup des Boot Volumes. Dokumentieren Sie die gemeinsame Failure Domain ausdrücklich."
      description: "Das Ziel behält VM-zentrierte Laufzeit und Datenbank bei und ergänzt eingeschränkten Ingress, reproduzierbare Konfiguration, Managed Telemetry und Backup auf VM-Ebene. Anwendung und Datenbank teilen weiterhin eine Failure Domain."
      assetId: "de/migration/assetcontainer/stackit/architecture-spring-boot-vm-load-balancer-monitoring-backup#architekturdiagramm"

    - style: "rocket"
      id: "reference-implementation"
      title: "Referenzimplementierung"
      trailContext: "Wechseln Sie von der Framework-Anleitung zum konkreten Spring-Boot- und PostgreSQL-Beispiel. Nutzen Sie das gepflegte Repository als Source of Truth für Terraform, Ansible, Migrationsskripte, Validierung und Laufzeitkonfiguration; die folgenden Schritte wenden seine Workflows an."
      description: "Die Referenzimplementierung demonstriert eine getestete Rehost-Topologie. Passen Sie Sizing, Security, Verfügbarkeit und Betriebskontrollen an den Workload an, statt das Beispiel als universelles Zieldesign zu behandeln."
      assetId: "de/migration/assetcontainer/stackit/rehost-automation-spring-boot-terraform-ansible#referenzimplementierung"

    - style: "hut"
      id: "prepare-workspace"
      title: "Arbeitsumgebung vorbereiten"
      trailContext: "Verwenden Sie den fixierten Repository-Stand auf einem vorbereiteten Linux-Laborhost. Prüfen Sie Werkzeuge und Berechtigungen vor Sample-Erzeugung und Ressourcenbereitstellung."
      assetId: "de/migration/assetcontainer/stackit/rehost-automation-spring-boot-terraform-ansible#arbeitsumgebung-für-den-walkthrough-vorbereiten"

    - style: "shield"
      id: "configure-target"
      title: "Private Zielparameter konfigurieren"
      trailContext: "Setzen Sie Projekt, Credentials, SSH-Vertrauen, Ingress und Sizing ausdrücklich. Lassen Sie den Quelldaten-Restore beim ersten Provisioning deaktiviert, damit die Probe ein getrenntes Gate bleibt."
      assetId: "de/migration/assetcontainer/stackit/rehost-automation-spring-boot-terraform-ansible#zielparameter-konfigurieren"

    - style: "shield"
      id: "source-target-readiness"
      title: "Quellnachweise vorbereiten"
      trailContext: Erfassen und prüfen Sie Quell-Dump, Manifest und Datenstand vor der Zielbereitstellung. Halten Sie Quelle und isolierte Testdaten eindeutig auseinander.
      assetId: de/migration/assetcontainer/stackit/rehost-automation-spring-boot-terraform-ansible#nachweise-an-der-quelle-vorbereiten
    - style: hut
      id: provision-target
      title: Ziel bereitstellen
      trailContext: Prüfen Sie die Zielparameter und den Infrastrukturplan, stellen Sie die Ressourcen bereit und sichern Sie die Ergebnisse vor der Migrationsprobe.
      assetId: de/migration/assetcontainer/stackit/rehost-automation-spring-boot-terraform-ansible#ziel-bereitstellen

    - style: "stairs"
      id: "rehearse-and-approve"
      title: "Proben und freigeben"
      splitRatio: 50
      left:
        - assetId: "de/migration/assetcontainer/stackit/rehost-automation-spring-boot-terraform-ansible#migration-proben"
      right:
        - assetId: "de/migration/assetcontainer/stackit/runbook-rehost-spring-boot#pre-migration-checks"

    - style: "rocket"
      id: "execute-cutover"
      title: "Cutover"
      trailContext: "Führen Sie den ausdrücklich bestätigten Cutover-Workflow aus. Erlauben Sie ausschließlich den Ersatz der Ansible-Orchestrierungsressource, stellen Sie den finalen Dump wieder her, validieren Sie Anwendung und Daten und verlangen Sie abschließend einen Terraform-No-op-Plan."
      assetId: "de/migration/assetcontainer/stackit/runbook-rehost-spring-boot#run-plan-cutover-fenster"
      imageSrc: "de/migration/files/migrate-wave-flow.svg"
      imageAlt: "Kontrollierte Migrationswelle von Readiness über Cutover und Validierung bis zum Handover"
      imagePosition: right
      imageWidth: 48

    - style: "rocket"
      id: "run-cutover"
      title: "Freigegebenen Cutover ausführen"
      trailContext: "Setzen Sie die finalen Quellnachweise und führen Sie das ausdrückliche Bestätigungs-Gate nur im freigegebenen Fenster mit aktuellem Backup und Rollback-Befugnis aus."
      assetId: "de/migration/assetcontainer/stackit/rehost-automation-spring-boot-terraform-ansible#cutover-ausführen"

    - style: "shield"
      id: "validate-or-rollback"
      title: "Validieren oder zurückrollen"
      splitRatio: 50
      left:
        - assetId: "de/migration/assetcontainer/stackit/runbook-rehost-spring-boot#validierungscheckliste"
      right:
        - assetId: "de/migration/assetcontainer/stackit/runbook-rehost-spring-boot#rollback-kriterien-und-schritte"

    - style: "shield"
      id: "validate-data-and-runtime"
      title: "Daten und Laufzeit verifizieren"
      trailContext: "Führen Sie die unabhängigen Validierungsbefehle aus und prüfen Sie den geschützten Rollback-Dump. Führen Sie Rollback nur bei erfülltem Entscheidungs-Gate aus, nicht automatisch als nächsten Schritt."
      assetId: "de/migration/assetcontainer/stackit/rehost-automation-spring-boot-terraform-ansible#validieren-und-zurückrollen"

    - style: "shield"
      id: "verify-acceptance"
      title: "Apply und Abnahme nachweisen"
      trailContext: "Unterscheiden Sie einen vorgeschlagenen Plan von abgeschlossenem Apply und abgenommenen Daten. Verlangen Sie den finalen No-op mit denselben Quellparametern und bewahren Sie maschinenlesbare Nachweise auf."
      assetId: "de/migration/assetcontainer/stackit/rehost-automation-spring-boot-terraform-ansible#nachweise-und-abnahme"

    - style: "summit"
      id: "stabilize-and-optimize"
      title: "Stabilisierung"
      splitRatio: 50
      left:
        - assetId: "de/migration/assetcontainer/stackit/runbook-rehost-spring-boot#handover-an-operations"
      right:
        - assetId: "de/migration/assetcontainer/stackit/rehost-automation-spring-boot-terraform-ansible#grenze-zwischen-backup-und-recovery"

    - style: "summit"
      id: "optimize-framework"
      title: "Optimierung"
      trailContext: "Kehren Sie vom konkreten Migrationsbeispiel zum Migration Framework zurück. Beginnen Sie Optimize erst nach stabilem Cutover, verwenden Sie repräsentative Produktionstelemetrie, setzen Sie jeweils eine kontrollierte Änderung um und validieren Sie ihre Wirkung auf Zuverlässigkeit, Performance und Kosten."
      description: "Der Framework-Zyklus definiert, wie Nachweise erfasst, Verbesserungen priorisiert, kontrollierte Änderungen umgesetzt, Ergebnisse validiert und Erkenntnisse in spätere Migrationswellen zurückgeführt werden."
      pageId: "de/migration/migrate/optimize/overview/#überblick-optimize-modul"

    - style: "chart"
      id: "optimize-reference-implementation"
      title: "Dieselbe Referenzimplementierung fortsetzen"
      trailContext: "Wenden Sie den Optimize-Zyklus des Frameworks auf dasselbe Spring-Boot- und PostgreSQL-Repository an, das für Provisioning, Probe, Cutover und Stabilisierung verwendet wurde. Es wird kein zweites Beispiel oder Repository eingeführt."
      description: "Verwenden Sie dessen Terraform-Variablen, Ansible-Konfiguration, STACKIT-Observability-Daten und Validierungsworkflows für die folgenden Compute- und Storage-Entscheidungen weiter."
      assetId: "de/migration/assetcontainer/stackit/optimize-rehosted-spring-boot-observability-rightsizing#dieselbe-referenzimplementierung-fortsetzen"

    - role: "sub"
      id: "optimize-target"
      title: "Optimierungskandidaten auswählen"
      trailContext: "Korrelieren Sie nach der Stabilisierung VM-Kapazität, Spring-Boot-Zustand, PostgreSQL-Druck, Latenz, Fehler und Kosten über einen repräsentativen Zeitraum, bevor Sie das Ziel ändern."
      description: "Unterscheiden Sie mit Dashboard und definierten Schwellwerten einen Compute-Engpass von Datenbank- oder Storage-Druck. Wählen Sie eine dominante Änderung, damit ihre Wirkung messbar bleibt."
      assetId: "de/migration/assetcontainer/stackit/optimize-rehosted-spring-boot-observability-rightsizing#observability-entscheidungsdashboard"

    - style: "chart"
      id: "optimize-compute"
      title: "VM-Flavor richtig dimensionieren"
      trailContext: "Ändern Sie `machine_type` in `env.tfvars` erst, wenn repräsentative Telemetrie anhaltende Überprovisionierung oder Überlast zeigt. Prüfen Sie den Terraform-Plan, wenden Sie ihn in einem freigegebenen Fenster an und vergleichen Sie Zustand, Latenz, Fehler, Durchsatz und Kosten mit der Baseline."
      description: "Das ausführbare Beispiel demonstriert Downsize und Scale-up. Stellen Sie bei verschlechterten Akzeptanzkriterien den vorherigen Machine Type über denselben geprüften IaC-Workflow wieder her."
      assetId: "de/migration/assetcontainer/stackit/optimize-rehosted-spring-boot-observability-rightsizing#beispiel-a-downsize-nach-dauerhaft-niedriger-auslastung"

    - style: "shield"
      id: "optimize-storage"
      title: "Storage-Pfad entscheiden"
      trailContext: "Wählen Sie die Storage-Performance-Klasse vor dem Provisioning anhand gemessener IOPS, Durchsatz, Latenz, Backup-Aktivität und Wachstumsreserve. Betriebssystem, Anwendung und PostgreSQL-Daten teilen in dieser Baseline das Boot Volume."
      description: "Nutzen Sie ein kontrolliertes Ersatzziel, wenn das gemeinsame Boot Volume eine andere Performance-Klasse benötigt. Verwenden Sie ein separates Data Volume, wenn sich Storage unabhängig weiterentwickeln soll, und migrieren Sie verifizierte Daten auf ein neu erstelltes Volume, bevor Sie umschalten."
      assetId: "de/migration/assetcontainer/stackit/optimize-rehosted-spring-boot-observability-rightsizing#storage-als-optimierungsaspekt"

    - style: "gondola"
      id: "replatform-baseline"
      title: "Rehost-Basis weiterverwenden"
      trailContext: "Trennen Sie die Wiederverwendung des fixierten JARs und lokaler Sample-Artefakte von einem realen Export der laufenden Rehost-VM, bevor Sie den nächsten Plattformwechsel planen."
      assetId: "de/migration/assetcontainer/stackit/rehost-automation-spring-boot-terraform-ansible#als-replatform-basis-weiterverwenden"
      role: sub

  presentations:

    - id: "technical-rehost-path"
      label: "Technischer Walkthrough"
      description: "VM-Referenz mit Quellvorbereitung, geprüftem Terraform-Provisioning, Probe, Cutover, Rollback und optionaler Optimierung nachstellen."
      launch: true
      preset: "standard"
      fullscreen: true
      steps:
        - confirm-rehost
        - target-architecture
        - reference-implementation
        - prepare-workspace
        - configure-target
        - source-target-readiness
        - provision-target
        - rehearse-and-approve
        - execute-cutover
        - run-cutover
        - validate-or-rollback
        - validate-data-and-runtime
        - verify-acceptance
        - stabilize-and-optimize
        - id: optimize-framework
          notes: Optional nach Stabilisierung und Abnahme. Rightsizing ist kein Teil des Cutovers und benötigt ein separat freigegebenes Änderungsfenster.
        - optimize-reference-implementation
        - id: optimize-target
          role: sub
        - optimize-compute
        - optimize-storage
        - id: replatform-baseline
          role: sub
      default: true
source_url: "https://framework.stackit.cloud/de/migration/trails/stackit/spring-boot-postgresql-rehost-technical-walkthrough/"
source_file: "docs/de/migration/trails/stackit/spring-boot-postgresql-rehost-technical-walkthrough.mdx"
---

## Steps

### 1. Rehost-Strategie

Stage: `chairlift`

Bestätigen Sie anhand der Discovery-Nachweise, dass das Beibehalten von Spring-Boot-JAR, systemd-Service-Modell und PostgreSQL-Engine auf einer VM die Migrationsziele erfüllt; Kubernetes, Cloud Foundry oder PostgreSQL Flex wären stattdessen Replatform. Leiten Sie daraus die Delivery-Reihenfolge ab: Landing Zone, Terraform-Infrastruktur, Ansible-Konfiguration, separate PostgreSQL-Migration und geprobtes Runbook.

Page: [/de/migration/design-and-mobilize/design/rehost/#überblick-rehost](/de/migration/design-and-mobilize/design/rehost/#überblick-rehost) — source: [/raw/de/migration/design-and-mobilize/design/rehost.md](/raw/de/migration/design-and-mobilize/design/rehost.md), section `#überblick-rehost`

### 2. Zielarchitektur

Stage: `chart`

Prüfen Sie die resultierende Ein-VM-Baseline: Spring Boot unter systemd, selbstverwaltetes PostgreSQL auf localhost, eingeschränkter Ingress, Observability Scraping und Backup des Boot Volumes. Dokumentieren Sie die gemeinsame Failure Domain ausdrücklich.

Das Ziel behält VM-zentrierte Laufzeit und Datenbank bei und ergänzt eingeschränkten Ingress, reproduzierbare Konfiguration, Managed Telemetry und Backup auf VM-Ebene. Anwendung und Datenbank teilen weiterhin eine Failure Domain.

Asset: [/de/migration/assetcontainer/stackit/architecture-spring-boot-vm-load-balancer-monitoring-backup/#architekturdiagramm](/de/migration/assetcontainer/stackit/architecture-spring-boot-vm-load-balancer-monitoring-backup/#architekturdiagramm) — source: [/raw/de/migration/assetcontainer/stackit/architecture-spring-boot-vm-load-balancer-monitoring-backup.md](/raw/de/migration/assetcontainer/stackit/architecture-spring-boot-vm-load-balancer-monitoring-backup.md), section `#architekturdiagramm`

### 3. Referenzimplementierung

Stage: `rocket`

Wechseln Sie von der Framework-Anleitung zum konkreten Spring-Boot- und PostgreSQL-Beispiel. Nutzen Sie das gepflegte Repository als Source of Truth für Terraform, Ansible, Migrationsskripte, Validierung und Laufzeitkonfiguration; die folgenden Schritte wenden seine Workflows an.

Die Referenzimplementierung demonstriert eine getestete Rehost-Topologie. Passen Sie Sizing, Security, Verfügbarkeit und Betriebskontrollen an den Workload an, statt das Beispiel als universelles Zieldesign zu behandeln.

Asset: [/de/migration/assetcontainer/stackit/rehost-automation-spring-boot-terraform-ansible/#referenzimplementierung](/de/migration/assetcontainer/stackit/rehost-automation-spring-boot-terraform-ansible/#referenzimplementierung) — source: [/raw/de/migration/assetcontainer/stackit/rehost-automation-spring-boot-terraform-ansible.md](/raw/de/migration/assetcontainer/stackit/rehost-automation-spring-boot-terraform-ansible.md), section `#referenzimplementierung`

### 4. Arbeitsumgebung vorbereiten

Stage: `hut`

Verwenden Sie den fixierten Repository-Stand auf einem vorbereiteten Linux-Laborhost. Prüfen Sie Werkzeuge und Berechtigungen vor Sample-Erzeugung und Ressourcenbereitstellung.

Asset: [/de/migration/assetcontainer/stackit/rehost-automation-spring-boot-terraform-ansible/#arbeitsumgebung-für-den-walkthrough-vorbereiten](/de/migration/assetcontainer/stackit/rehost-automation-spring-boot-terraform-ansible/#arbeitsumgebung-für-den-walkthrough-vorbereiten) — source: [/raw/de/migration/assetcontainer/stackit/rehost-automation-spring-boot-terraform-ansible.md](/raw/de/migration/assetcontainer/stackit/rehost-automation-spring-boot-terraform-ansible.md), section `#arbeitsumgebung-für-den-walkthrough-vorbereiten`

### 5. Private Zielparameter konfigurieren

Stage: `shield`

Setzen Sie Projekt, Credentials, SSH-Vertrauen, Ingress und Sizing ausdrücklich. Lassen Sie den Quelldaten-Restore beim ersten Provisioning deaktiviert, damit die Probe ein getrenntes Gate bleibt.

Asset: [/de/migration/assetcontainer/stackit/rehost-automation-spring-boot-terraform-ansible/#zielparameter-konfigurieren](/de/migration/assetcontainer/stackit/rehost-automation-spring-boot-terraform-ansible/#zielparameter-konfigurieren) — source: [/raw/de/migration/assetcontainer/stackit/rehost-automation-spring-boot-terraform-ansible.md](/raw/de/migration/assetcontainer/stackit/rehost-automation-spring-boot-terraform-ansible.md), section `#zielparameter-konfigurieren`

### 6. Quellnachweise vorbereiten

Stage: `shield`

Erfassen und prüfen Sie Quell-Dump, Manifest und Datenstand vor der Zielbereitstellung. Halten Sie Quelle und isolierte Testdaten eindeutig auseinander.

Asset: [/de/migration/assetcontainer/stackit/rehost-automation-spring-boot-terraform-ansible/#nachweise-an-der-quelle-vorbereiten](/de/migration/assetcontainer/stackit/rehost-automation-spring-boot-terraform-ansible/#nachweise-an-der-quelle-vorbereiten) — source: [/raw/de/migration/assetcontainer/stackit/rehost-automation-spring-boot-terraform-ansible.md](/raw/de/migration/assetcontainer/stackit/rehost-automation-spring-boot-terraform-ansible.md), section `#nachweise-an-der-quelle-vorbereiten`

### 7. Ziel bereitstellen

Stage: `hut`

Prüfen Sie die Zielparameter und den Infrastrukturplan, stellen Sie die Ressourcen bereit und sichern Sie die Ergebnisse vor der Migrationsprobe.

Asset: [/de/migration/assetcontainer/stackit/rehost-automation-spring-boot-terraform-ansible/#ziel-bereitstellen](/de/migration/assetcontainer/stackit/rehost-automation-spring-boot-terraform-ansible/#ziel-bereitstellen) — source: [/raw/de/migration/assetcontainer/stackit/rehost-automation-spring-boot-terraform-ansible.md](/raw/de/migration/assetcontainer/stackit/rehost-automation-spring-boot-terraform-ansible.md), section `#ziel-bereitstellen`

### 8. Proben und freigeben

Stage: `stairs`

### 9. Cutover

Stage: `rocket`

Führen Sie den ausdrücklich bestätigten Cutover-Workflow aus. Erlauben Sie ausschließlich den Ersatz der Ansible-Orchestrierungsressource, stellen Sie den finalen Dump wieder her, validieren Sie Anwendung und Daten und verlangen Sie abschließend einen Terraform-No-op-Plan.

Asset: [/de/migration/assetcontainer/stackit/runbook-rehost-spring-boot/#run-plan-cutover-fenster](/de/migration/assetcontainer/stackit/runbook-rehost-spring-boot/#run-plan-cutover-fenster) — source: [/raw/de/migration/assetcontainer/stackit/runbook-rehost-spring-boot.md](/raw/de/migration/assetcontainer/stackit/runbook-rehost-spring-boot.md), section `#run-plan-cutover-fenster`

### 10. Freigegebenen Cutover ausführen

Stage: `rocket`

Setzen Sie die finalen Quellnachweise und führen Sie das ausdrückliche Bestätigungs-Gate nur im freigegebenen Fenster mit aktuellem Backup und Rollback-Befugnis aus.

Asset: [/de/migration/assetcontainer/stackit/rehost-automation-spring-boot-terraform-ansible/#cutover-ausführen](/de/migration/assetcontainer/stackit/rehost-automation-spring-boot-terraform-ansible/#cutover-ausführen) — source: [/raw/de/migration/assetcontainer/stackit/rehost-automation-spring-boot-terraform-ansible.md](/raw/de/migration/assetcontainer/stackit/rehost-automation-spring-boot-terraform-ansible.md), section `#cutover-ausführen`

### 11. Validieren oder zurückrollen

Stage: `shield`

### 12. Daten und Laufzeit verifizieren

Stage: `shield`

Führen Sie die unabhängigen Validierungsbefehle aus und prüfen Sie den geschützten Rollback-Dump. Führen Sie Rollback nur bei erfülltem Entscheidungs-Gate aus, nicht automatisch als nächsten Schritt.

Asset: [/de/migration/assetcontainer/stackit/rehost-automation-spring-boot-terraform-ansible/#validieren-und-zurückrollen](/de/migration/assetcontainer/stackit/rehost-automation-spring-boot-terraform-ansible/#validieren-und-zurückrollen) — source: [/raw/de/migration/assetcontainer/stackit/rehost-automation-spring-boot-terraform-ansible.md](/raw/de/migration/assetcontainer/stackit/rehost-automation-spring-boot-terraform-ansible.md), section `#validieren-und-zurückrollen`

### 13. Apply und Abnahme nachweisen

Stage: `shield`

Unterscheiden Sie einen vorgeschlagenen Plan von abgeschlossenem Apply und abgenommenen Daten. Verlangen Sie den finalen No-op mit denselben Quellparametern und bewahren Sie maschinenlesbare Nachweise auf.

Asset: [/de/migration/assetcontainer/stackit/rehost-automation-spring-boot-terraform-ansible/#nachweise-und-abnahme](/de/migration/assetcontainer/stackit/rehost-automation-spring-boot-terraform-ansible/#nachweise-und-abnahme) — source: [/raw/de/migration/assetcontainer/stackit/rehost-automation-spring-boot-terraform-ansible.md](/raw/de/migration/assetcontainer/stackit/rehost-automation-spring-boot-terraform-ansible.md), section `#nachweise-und-abnahme`

### 14. Stabilisierung

Stage: `summit`

### 15. Optimierung

Stage: `summit`

Kehren Sie vom konkreten Migrationsbeispiel zum Migration Framework zurück. Beginnen Sie Optimize erst nach stabilem Cutover, verwenden Sie repräsentative Produktionstelemetrie, setzen Sie jeweils eine kontrollierte Änderung um und validieren Sie ihre Wirkung auf Zuverlässigkeit, Performance und Kosten.

Der Framework-Zyklus definiert, wie Nachweise erfasst, Verbesserungen priorisiert, kontrollierte Änderungen umgesetzt, Ergebnisse validiert und Erkenntnisse in spätere Migrationswellen zurückgeführt werden.

Page: [/de/migration/migrate/optimize/overview/#überblick-optimize-modul](/de/migration/migrate/optimize/overview/#überblick-optimize-modul) — source: [/raw/de/migration/migrate/optimize/overview.md](/raw/de/migration/migrate/optimize/overview.md), section `#überblick-optimize-modul`

### 16. Dieselbe Referenzimplementierung fortsetzen

Stage: `chart`

Wenden Sie den Optimize-Zyklus des Frameworks auf dasselbe Spring-Boot- und PostgreSQL-Repository an, das für Provisioning, Probe, Cutover und Stabilisierung verwendet wurde. Es wird kein zweites Beispiel oder Repository eingeführt.

Verwenden Sie dessen Terraform-Variablen, Ansible-Konfiguration, STACKIT-Observability-Daten und Validierungsworkflows für die folgenden Compute- und Storage-Entscheidungen weiter.

Asset: [/de/migration/assetcontainer/stackit/optimize-rehosted-spring-boot-observability-rightsizing/#dieselbe-referenzimplementierung-fortsetzen](/de/migration/assetcontainer/stackit/optimize-rehosted-spring-boot-observability-rightsizing/#dieselbe-referenzimplementierung-fortsetzen) — source: [/raw/de/migration/assetcontainer/stackit/optimize-rehosted-spring-boot-observability-rightsizing.md](/raw/de/migration/assetcontainer/stackit/optimize-rehosted-spring-boot-observability-rightsizing.md), section `#dieselbe-referenzimplementierung-fortsetzen`

### 17. Optimierungskandidaten auswählen

Korrelieren Sie nach der Stabilisierung VM-Kapazität, Spring-Boot-Zustand, PostgreSQL-Druck, Latenz, Fehler und Kosten über einen repräsentativen Zeitraum, bevor Sie das Ziel ändern.

Unterscheiden Sie mit Dashboard und definierten Schwellwerten einen Compute-Engpass von Datenbank- oder Storage-Druck. Wählen Sie eine dominante Änderung, damit ihre Wirkung messbar bleibt.

Asset: [/de/migration/assetcontainer/stackit/optimize-rehosted-spring-boot-observability-rightsizing/#observability-entscheidungsdashboard](/de/migration/assetcontainer/stackit/optimize-rehosted-spring-boot-observability-rightsizing/#observability-entscheidungsdashboard) — source: [/raw/de/migration/assetcontainer/stackit/optimize-rehosted-spring-boot-observability-rightsizing.md](/raw/de/migration/assetcontainer/stackit/optimize-rehosted-spring-boot-observability-rightsizing.md), section `#observability-entscheidungsdashboard`

### 18. VM-Flavor richtig dimensionieren

Stage: `chart`

Ändern Sie `machine_type` in `env.tfvars` erst, wenn repräsentative Telemetrie anhaltende Überprovisionierung oder Überlast zeigt. Prüfen Sie den Terraform-Plan, wenden Sie ihn in einem freigegebenen Fenster an und vergleichen Sie Zustand, Latenz, Fehler, Durchsatz und Kosten mit der Baseline.

Das ausführbare Beispiel demonstriert Downsize und Scale-up. Stellen Sie bei verschlechterten Akzeptanzkriterien den vorherigen Machine Type über denselben geprüften IaC-Workflow wieder her.

Asset: [/de/migration/assetcontainer/stackit/optimize-rehosted-spring-boot-observability-rightsizing/#beispiel-a-downsize-nach-dauerhaft-niedriger-auslastung](/de/migration/assetcontainer/stackit/optimize-rehosted-spring-boot-observability-rightsizing/#beispiel-a-downsize-nach-dauerhaft-niedriger-auslastung) — source: [/raw/de/migration/assetcontainer/stackit/optimize-rehosted-spring-boot-observability-rightsizing.md](/raw/de/migration/assetcontainer/stackit/optimize-rehosted-spring-boot-observability-rightsizing.md), section `#beispiel-a-downsize-nach-dauerhaft-niedriger-auslastung`

### 19. Storage-Pfad entscheiden

Stage: `shield`

Wählen Sie die Storage-Performance-Klasse vor dem Provisioning anhand gemessener IOPS, Durchsatz, Latenz, Backup-Aktivität und Wachstumsreserve. Betriebssystem, Anwendung und PostgreSQL-Daten teilen in dieser Baseline das Boot Volume.

Nutzen Sie ein kontrolliertes Ersatzziel, wenn das gemeinsame Boot Volume eine andere Performance-Klasse benötigt. Verwenden Sie ein separates Data Volume, wenn sich Storage unabhängig weiterentwickeln soll, und migrieren Sie verifizierte Daten auf ein neu erstelltes Volume, bevor Sie umschalten.

Asset: [/de/migration/assetcontainer/stackit/optimize-rehosted-spring-boot-observability-rightsizing/#storage-als-optimierungsaspekt](/de/migration/assetcontainer/stackit/optimize-rehosted-spring-boot-observability-rightsizing/#storage-als-optimierungsaspekt) — source: [/raw/de/migration/assetcontainer/stackit/optimize-rehosted-spring-boot-observability-rightsizing.md](/raw/de/migration/assetcontainer/stackit/optimize-rehosted-spring-boot-observability-rightsizing.md), section `#storage-als-optimierungsaspekt`

### 20. Rehost-Basis weiterverwenden

Stage: `gondola`

Trennen Sie die Wiederverwendung des fixierten JARs und lokaler Sample-Artefakte von einem realen Export der laufenden Rehost-VM, bevor Sie den nächsten Plattformwechsel planen.

Asset: [/de/migration/assetcontainer/stackit/rehost-automation-spring-boot-terraform-ansible/#als-replatform-basis-weiterverwenden](/de/migration/assetcontainer/stackit/rehost-automation-spring-boot-terraform-ansible/#als-replatform-basis-weiterverwenden) — source: [/raw/de/migration/assetcontainer/stackit/rehost-automation-spring-boot-terraform-ansible.md](/raw/de/migration/assetcontainer/stackit/rehost-automation-spring-boot-terraform-ansible.md), section `#als-replatform-basis-weiterverwenden`