--- title: "Rehost to STACKIT: Überblick zu Spring Boot und PostgreSQL" description: "Planen Sie den Rehost von Spring Boot und PostgreSQL nach STACKIT: Discovery, VM-Design, Landing Zone, Migrationsfreigaben, Betriebsübergabe und Optimierung." scfTrail: tags: [ "rehost", "spring-boot", "postgresql", "terraform", "ansible", "cutover" ] maintainers: - user: "lukas.weberruss" role: true website: true steps: - style: "compass" id: "rehost-journey" title: "Spring-Boot-Rehost-Journey" trailContext: "Beginnen Sie mit dem vollständigen Migration Framework, damit das Publikum Workload-Bewertung, Rehost-Design, kontrollierte Migration, Stabilisierung und Optimierung als durchgängige Journey einordnen kann." imageSrc: "de/migration/files/migration-framework-overview.svg" imageAlt: "STACKIT Migration Framework von Assess über Design and Mobilize und Migrate bis Run" - style: "compass" id: "rapid-discovery" title: "Rapid Discovery" trailContext: "Erstellen Sie eine kompakte Workload-Baseline für Spring-Boot-Laufzeit, PostgreSQL-Datenpfad, Abhängigkeiten und erste Kapazitätssignale. Qualifizieren Sie damit die Migrationsabsicht, machen Sie Unbekannte sichtbar und definieren Sie, was die detaillierte Discovery vor dem Zieldesign validieren muss; behandeln Sie frühe Annahmen nicht als bestätigte Eingaben." pageId: "de/migration/assess/rapid-discovery/overview/#überblick" imageSrc: "de/migration/assess/rapid-discovery/files/rapid-discovery-process.svg" imageAlt: "Rapid-Discovery-Prozess von der Erfassung der Quelldaten bis zur entscheidungsreifen Migrations-Baseline" - style: "stairs" id: "discovery-evidence" title: "Discovery" trailContext: "Kombinieren Sie Nachweise der Application Owner mit technischen Messungen zu Abhängigkeiten, Java- und PostgreSQL-Versionen, Service-Verhalten, Datenmenge und Änderungsrate, Betriebsbedingungen, Recovery-Zielen und repräsentativer Ressourcennutzung. Bestätigen Sie Kompatibilität, Migrationsbedingungen und Kapazitäts-Baseline vor dem Design." pageId: "de/migration/design-and-mobilize/discovery/overview/#überblick-discovery" imageSrc: "de/migration/design-and-mobilize/discovery/files/discovery-analysis-flow.svg" imageAlt: "Discovery-Analyse aus technischen Nachweisen und Erkenntnissen der Application Owner" - 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: "stairs" id: "automation-approach" title: "Mit Terraform und Ansible automatisieren" trailContext: "Trennen Sie Infrastruktur-Lifecycle und Zielkonfiguration: Terraform oder OpenTofu erstellt und synchronisiert STACKIT Ressourcen, während Ansible das erreichbare Betriebssystem, Middleware, Anwendung und Validierungskontrollen konfiguriert." description: "Nutzen Sie einen versionierten Delivery-Flow mit Plan-Review, expliziter Übergabe zwischen den Werkzeugen, idempotenter Konfiguration und aufbewahrten Validierungsnachweisen." pageId: "de/migration/design-and-mobilize/landing-zones/automation-iac/#delivery-flow-mit-terraformopentofu-und-ansible" - 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: "gondola" id: "design-data-path" title: "Datenbankmigration" trailContext: "Trennen Sie nach der Definition von Infrastruktur und Laufzeitpfad die Vorbereitung der Anwendung von PostgreSQL-Export, Übertragung, Restore und Integritätsvalidierung. Definieren Sie Write Freeze, finalen Dump, Rollback-Deadline und Aufbewahrung der Quelle vor der Ausführung." description: "Frieren Sie Schreibzugriffe auf der Quelle ein, erstellen und qualifizieren Sie den finalen PostgreSQL-Dump, proben Sie einen isolierten Restore, schützen Sie den Zustand vor dem Cutover und akzeptieren Sie das Ziel oder rollen Sie anhand objektiver Integritätsnachweise zurück." pageId: "de/migration/design-and-mobilize/design/rehost/#datenmigrationspfad-bei-rehost" imageSrc: "contributors/stackit/files/migration/spring-boot-postgresql-rehost-data-path-de.svg" imageAlt: "Kontrollierter PostgreSQL-Rehost-Pfad von Source Freeze und Nachweisen über Probe und transaktionalen Cutover bis zur Abnahme oder zum Rollback" - style: "hut" id: "landing-zone" title: "Landing Zone" trailContext: "Etablieren Sie die gesteuerte Cloud-Basis, bevor das Rehost-Ziel davon abhängt. Verwenden Sie die sechs Kernkomponenten als Readiness-Rahmen: Jede Kontrolle benötigt Ownership, eine freigegebene Implementierung und Nachweise, bevor Terraform das Spring-Boot-Ziel bereitstellt." pageId: "de/migration/design-and-mobilize/landing-zones/overview/#überblick-landing-zones" imageSrc: "de/migration/design-and-mobilize/landing-zones/files/landing-zone-core-components-map-de.svg" imageAlt: "Sechs Kernkomponenten einer sicheren STACKIT Landing Zone: Governance, Identity, Security, Netzwerk, Kostenkontrolle und Automatisierung" - role: "sub" id: "landing-zone-accelerator" title: "Basis als Code beschleunigen" trailContext: "Nutzen Sie den STACKIT Landing Zone Accelerator, um wiederverwendbare Organisations-Folder, Plattformprojekte, Connectivity, Management Services und die Workload-bereite Application Landing Zone zu erstellen, bevor die Rehost-Automatisierung ihre VM deployt." description: "Halten Sie die Grenze explizit: Der Accelerator stellt die gesteuerte Umgebung bereit; das Application Team deployt Spring Boot, PostgreSQL, Telemetrie und Backup in die freigegebene Application Landing Zone." imageSrc: "contributors/stackit/files/migration/landing-zone-accelerator-architecture.svg" imageAlt: "Architektur des Landing Zone Accelerators mit getrennten Verantwortlichkeiten für Plattform, Application Landing Zone und Workload" - style: "rocket" id: "migration-flow" title: "Migration Framework" trailContext: "Beginnen Sie die Ausführung nur mit freigegebenen Designentscheidungen, einer bereiten Application Landing Zone, einer zugewiesenen Welle und einem Factory-fähigen Runbook. Führen Sie Readiness, Migration, Cutover, Validierung, Stabilisierung und Handover als einen kontrollierten Ablauf aus." description: "Das Migration Framework definiert zuerst Reihenfolge und Kontrollpunkte; die folgenden Rehost-Assets setzen diesen Ablauf anschließend für Spring Boot und PostgreSQL konkret um." pageId: "de/migration/migrate/migrate/overview/#end-to-end-ablauf-in-der-factory" - style: "shield" id: "migration-checkpoints" title: "Freigabepunkte der Migration" trailContext: "Prüfen Sie Readiness, Probe, Cutover-Freigabe, Abnahme und Recovery als getrennte Entscheidungen, bevor Sie die Ausführungsverantwortung zuweisen." assetId: "de/migration/assetcontainer/stackit/rehost-automation-spring-boot-terraform-ansible#entscheidungs--und-freigabepunkte-der-migration" - style: hut id: technical-implementation title: Technische Umsetzung center: trailId: de/migration/trails/stackit/spring-boot-postgresql-rehost-technical-walkthrough - style: summit id: operating-handoff title: Abnehmen und an den Betrieb übergeben trailContext: Geben Sie das migrierte System erst nach technischer und fachlicher Abnahme frei. Übergeben Sie Zuständigkeiten, Monitoring, Wiederherstellung und Quellaufbewahrung; stabilisieren Sie vor Optimierungsänderungen. assetId: de/migration/assetcontainer/stackit/runbook-rehost-spring-boot#handover-an-operations - 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" - 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" presentations: - id: "validated-rehost-path" label: "Rehost-Überblick" description: "Präsentation von Strategie, Architektur, Migrationskontrollen und Betrieb ohne ausführbare Walkthrough-Befehle." default: true launch: true preset: "standard" fullscreen: true steps: - { id: "rehost-journey", role: "hidden" } - "rapid-discovery" - { id: "discovery-evidence", role: "hidden" } - "confirm-rehost" - { id: "automation-approach", role: "hidden" } - "target-architecture" - { id: "design-data-path", role: "hidden" } - "landing-zone" - { id: "landing-zone-accelerator", role: "hidden" } - "migration-flow" - { id: "migration-checkpoints", role: "hidden" } - id: technical-implementation role: hidden - operating-handoff - "optimize-framework" - { id: "optimize-target", role: "hidden" } source_url: "https://framework.stackit.cloud/de/migration/trails/stackit/spring-boot-postgresql-rehost-to-stackit/" source_file: "docs/de/migration/trails/stackit/spring-boot-postgresql-rehost-to-stackit.mdx" --- ## Steps ### 1. Spring-Boot-Rehost-Journey Stage: `compass` Beginnen Sie mit dem vollständigen Migration Framework, damit das Publikum Workload-Bewertung, Rehost-Design, kontrollierte Migration, Stabilisierung und Optimierung als durchgängige Journey einordnen kann. ### 2. Rapid Discovery Stage: `compass` Erstellen Sie eine kompakte Workload-Baseline für Spring-Boot-Laufzeit, PostgreSQL-Datenpfad, Abhängigkeiten und erste Kapazitätssignale. Qualifizieren Sie damit die Migrationsabsicht, machen Sie Unbekannte sichtbar und definieren Sie, was die detaillierte Discovery vor dem Zieldesign validieren muss; behandeln Sie frühe Annahmen nicht als bestätigte Eingaben. Page: [/de/migration/assess/rapid-discovery/overview/#überblick](/de/migration/assess/rapid-discovery/overview/#überblick) — source: [/raw/de/migration/assess/rapid-discovery/overview.md](/raw/de/migration/assess/rapid-discovery/overview.md), section `#überblick` ### 3. Discovery Stage: `stairs` Kombinieren Sie Nachweise der Application Owner mit technischen Messungen zu Abhängigkeiten, Java- und PostgreSQL-Versionen, Service-Verhalten, Datenmenge und Änderungsrate, Betriebsbedingungen, Recovery-Zielen und repräsentativer Ressourcennutzung. Bestätigen Sie Kompatibilität, Migrationsbedingungen und Kapazitäts-Baseline vor dem Design. Page: [/de/migration/design-and-mobilize/discovery/overview/#überblick-discovery](/de/migration/design-and-mobilize/discovery/overview/#überblick-discovery) — source: [/raw/de/migration/design-and-mobilize/discovery/overview.md](/raw/de/migration/design-and-mobilize/discovery/overview.md), section `#überblick-discovery` ### 4. 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` ### 5. Mit Terraform und Ansible automatisieren Stage: `stairs` Trennen Sie Infrastruktur-Lifecycle und Zielkonfiguration: Terraform oder OpenTofu erstellt und synchronisiert STACKIT Ressourcen, während Ansible das erreichbare Betriebssystem, Middleware, Anwendung und Validierungskontrollen konfiguriert. Nutzen Sie einen versionierten Delivery-Flow mit Plan-Review, expliziter Übergabe zwischen den Werkzeugen, idempotenter Konfiguration und aufbewahrten Validierungsnachweisen. Page: [/de/migration/design-and-mobilize/landing-zones/automation-iac/#delivery-flow-mit-terraformopentofu-und-ansible](/de/migration/design-and-mobilize/landing-zones/automation-iac/#delivery-flow-mit-terraformopentofu-und-ansible) — source: [/raw/de/migration/design-and-mobilize/landing-zones/automation-iac.md](/raw/de/migration/design-and-mobilize/landing-zones/automation-iac.md), section `#delivery-flow-mit-terraformopentofu-und-ansible` ### 6. 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` ### 7. Datenbankmigration Stage: `gondola` Trennen Sie nach der Definition von Infrastruktur und Laufzeitpfad die Vorbereitung der Anwendung von PostgreSQL-Export, Übertragung, Restore und Integritätsvalidierung. Definieren Sie Write Freeze, finalen Dump, Rollback-Deadline und Aufbewahrung der Quelle vor der Ausführung. Frieren Sie Schreibzugriffe auf der Quelle ein, erstellen und qualifizieren Sie den finalen PostgreSQL-Dump, proben Sie einen isolierten Restore, schützen Sie den Zustand vor dem Cutover und akzeptieren Sie das Ziel oder rollen Sie anhand objektiver Integritätsnachweise zurück. Page: [/de/migration/design-and-mobilize/design/rehost/#datenmigrationspfad-bei-rehost](/de/migration/design-and-mobilize/design/rehost/#datenmigrationspfad-bei-rehost) — source: [/raw/de/migration/design-and-mobilize/design/rehost.md](/raw/de/migration/design-and-mobilize/design/rehost.md), section `#datenmigrationspfad-bei-rehost` ### 8. Landing Zone Stage: `hut` Etablieren Sie die gesteuerte Cloud-Basis, bevor das Rehost-Ziel davon abhängt. Verwenden Sie die sechs Kernkomponenten als Readiness-Rahmen: Jede Kontrolle benötigt Ownership, eine freigegebene Implementierung und Nachweise, bevor Terraform das Spring-Boot-Ziel bereitstellt. Page: [/de/migration/design-and-mobilize/landing-zones/overview/#überblick-landing-zones](/de/migration/design-and-mobilize/landing-zones/overview/#überblick-landing-zones) — source: [/raw/de/migration/design-and-mobilize/landing-zones/overview.md](/raw/de/migration/design-and-mobilize/landing-zones/overview.md), section `#überblick-landing-zones` ### 9. Basis als Code beschleunigen Nutzen Sie den STACKIT Landing Zone Accelerator, um wiederverwendbare Organisations-Folder, Plattformprojekte, Connectivity, Management Services und die Workload-bereite Application Landing Zone zu erstellen, bevor die Rehost-Automatisierung ihre VM deployt. Halten Sie die Grenze explizit: Der Accelerator stellt die gesteuerte Umgebung bereit; das Application Team deployt Spring Boot, PostgreSQL, Telemetrie und Backup in die freigegebene Application Landing Zone. ### 10. Migration Framework Stage: `rocket` Beginnen Sie die Ausführung nur mit freigegebenen Designentscheidungen, einer bereiten Application Landing Zone, einer zugewiesenen Welle und einem Factory-fähigen Runbook. Führen Sie Readiness, Migration, Cutover, Validierung, Stabilisierung und Handover als einen kontrollierten Ablauf aus. Das Migration Framework definiert zuerst Reihenfolge und Kontrollpunkte; die folgenden Rehost-Assets setzen diesen Ablauf anschließend für Spring Boot und PostgreSQL konkret um. Page: [/de/migration/migrate/migrate/overview/#end-to-end-ablauf-in-der-factory](/de/migration/migrate/migrate/overview/#end-to-end-ablauf-in-der-factory) — source: [/raw/de/migration/migrate/migrate/overview.md](/raw/de/migration/migrate/migrate/overview.md), section `#end-to-end-ablauf-in-der-factory` ### 11. Freigabepunkte der Migration Stage: `shield` Prüfen Sie Readiness, Probe, Cutover-Freigabe, Abnahme und Recovery als getrennte Entscheidungen, bevor Sie die Ausführungsverantwortung zuweisen. Asset: [/de/migration/assetcontainer/stackit/rehost-automation-spring-boot-terraform-ansible/#entscheidungs--und-freigabepunkte-der-migration](/de/migration/assetcontainer/stackit/rehost-automation-spring-boot-terraform-ansible/#entscheidungs--und-freigabepunkte-der-migration) — 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 `#entscheidungs--und-freigabepunkte-der-migration` ### 12. Technische Umsetzung Stage: `hut` ### 13. Abnehmen und an den Betrieb übergeben Stage: `summit` Geben Sie das migrierte System erst nach technischer und fachlicher Abnahme frei. Übergeben Sie Zuständigkeiten, Monitoring, Wiederherstellung und Quellaufbewahrung; stabilisieren Sie vor Optimierungsänderungen. Asset: [/de/migration/assetcontainer/stackit/runbook-rehost-spring-boot/#handover-an-operations](/de/migration/assetcontainer/stackit/runbook-rehost-spring-boot/#handover-an-operations) — source: [/raw/de/migration/assetcontainer/stackit/runbook-rehost-spring-boot.md](/raw/de/migration/assetcontainer/stackit/runbook-rehost-spring-boot.md), section `#handover-an-operations` ### 14. 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` ### 15. 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`