---
title: "Rehost to STACKIT: Spring Boot and PostgreSQL Overview"
description: "Plan a Spring Boot and PostgreSQL Rehost to STACKIT: discovery, VM design, landing-zone readiness, migration decisions, operating handoff, and optimization."
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: "Open with the complete Migration Framework so the audience can place workload assessment, Rehost design, controlled migration, stabilization, and optimization in one end-to-end journey."
      imageSrc: "migration/files/migration-framework-overview.svg"
      imageAlt: "STACKIT Migration Framework from Assess through Design and Mobilize and Migrate to Run"

    - style: "compass"
      id: "rapid-discovery"
      title: "Rapid Discovery"
      trailContext: "Build a lightweight workload baseline for the Spring Boot runtime, PostgreSQL data path, dependencies, and initial capacity signals. Use it to qualify migration intent, expose unknowns, and define what detailed Discovery must validate before target design; do not treat early assumptions as verified inputs."
      pageId: "migration/assess/rapid-discovery/overview/#overview"
      imageSrc: "migration/assess/rapid-discovery/files/rapid-discovery-process.svg"
      imageAlt: "Rapid Discovery process from source data collection to a decision-ready migration baseline"

    - style: "stairs"
      id: "discovery-evidence"
      title: "Discovery"
      trailContext: "Combine application-owner evidence with technical measurements of dependencies, Java and PostgreSQL versions, service behavior, data size and change rate, operating constraints, recovery objectives, and representative resource use. Confirm compatibility, migration constraints, and the target capacity baseline before design."
      pageId: "migration/design-and-mobilize/discovery/overview/#understanding-discovery"
      imageSrc: "migration/design-and-mobilize/discovery/files/discovery-analysis-flow.svg"
      imageAlt: "Discovery analysis combining technical and application-owner evidence"

    - style: "chairlift"
      id: "confirm-rehost"
      title: "Rehost Strategy"
      trailContext: "Use Discovery evidence to confirm that preserving the Spring Boot JAR, systemd service model, and PostgreSQL engine on a VM meets the migration goals; Kubernetes, Cloud Foundry, or PostgreSQL Flex would instead be Replatform. Derive the delivery sequence from that decision: Landing Zone, Terraform infrastructure, Ansible configuration, separate PostgreSQL migration, and the rehearsed runbook."
      pageId: "migration/design-and-mobilize/design/rehost/#understanding-rehost"
      imageSrc: "migration/files/r-strategy-method.svg"
      imageAlt: "R-strategy method with Rehost as the application-level lift-and-shift path"

    - style: "stairs"
      id: "automation-approach"
      title: "Automate with Terraform and Ansible"
      trailContext: "Separate infrastructure lifecycle from target configuration: Terraform or OpenTofu creates and reconciles STACKIT resources, while Ansible configures the reachable operating system, middleware, application, and validation controls."
      description: "Use one versioned delivery flow with plan review, explicit handoff between tools, idempotent configuration, and retained validation evidence."
      pageId: "migration/design-and-mobilize/landing-zones/automation-iac/#terraformopentofu-and-ansible-delivery-flow"

    - style: "chart"
      id: "target-architecture"
      title: "Target Architecture"
      trailContext: "Review the resulting one-VM baseline: Spring Boot under systemd, self-managed PostgreSQL on localhost, restricted ingress, Observability scraping, and boot-volume backup. Record the shared failure domain explicitly."
      description: "The target preserves the VM-centric runtime and database model while adding restricted ingress, reproducible configuration, managed telemetry, and VM-level backup. The application and database still share one failure domain."
      assetId: "migration/assetcontainer/stackit/architecture-spring-boot-vm-load-balancer-monitoring-backup#architecture-diagram"

    - style: "gondola"
      id: "design-data-path"
      title: "Database Migration"
      trailContext: "After the infrastructure and runtime path is defined, separate application preparation from PostgreSQL export, transfer, restore, and integrity validation. Define the write freeze, final dump, rollback deadline, and source retention before execution."
      description: "Freeze source writes, create and qualify the final PostgreSQL dump, rehearse an isolated restore, protect the pre-cutover target state, and accept or roll back from objective integrity evidence."
      pageId: "migration/design-and-mobilize/design/rehost/#data-migration-path-in-rehost"
      imageSrc: "contributors/stackit/files/migration/spring-boot-postgresql-rehost-data-path.svg"
      imageAlt: "Controlled PostgreSQL Rehost path from source freeze and evidence through rehearsal, transactional cutover, acceptance, or rollback"

    - style: "hut"
      id: "landing-zone"
      title: "Landing Zone"
      trailContext: "Establish the governed cloud foundation before the Rehost target depends on it. Use the six core components as the readiness frame: every control needs an owner, an approved implementation, and evidence before Terraform provisions the Spring Boot target."
      pageId: "migration/design-and-mobilize/landing-zones/overview/#understanding-landing-zones"
      imageSrc: "migration/design-and-mobilize/landing-zones/files/landing-zone-core-components-map-en.svg"
      imageAlt: "Six core components of a secure STACKIT landing zone: governance, identity, security, network, cost control, and automation"

    - role: "sub"
      id: "landing-zone-accelerator"
      title: "Accelerate the Foundation as Code"
      trailContext: "Use the STACKIT Landing Zone Accelerator to create reusable organization folders, platform projects, connectivity, management services, and the workload-ready Application Landing Zone before the Rehost automation deploys its VM."
      description: "Keep the boundary explicit: the Accelerator provides the governed environment; the application team deploys Spring Boot, PostgreSQL, telemetry, and backup into the approved Application Landing Zone."
      imageSrc: "contributors/stackit/files/migration/landing-zone-accelerator-architecture.svg"
      imageAlt: "Landing Zone Accelerator architecture separating platform, application landing zone, and workload responsibilities"

    - style: "rocket"
      id: "migration-flow"
      title: "Migration Framework"
      trailContext: "Enter execution only with approved design decisions, a ready Application Landing Zone, an assigned wave, and a factory-ready runbook. Execute readiness, migration, cutover, validation, stabilization, and handover as one controlled flow."
      description: "The Migration Framework defines the sequence and control points first; the following Rehost assets then instantiate that flow for Spring Boot and PostgreSQL."
      pageId: "migration/migrate/migrate/overview/#end-to-end-factory-flow"

    - style: "shield"
      id: "migration-checkpoints"
      title: "Migration Decision Gates"
      trailContext: "Review readiness, rehearsal, cutover approval, acceptance and recovery as separate decisions before assigning execution responsibilities."
      assetId: "migration/assetcontainer/stackit/rehost-automation-spring-boot-terraform-ansible#migration-decision-gates"
    - style: hut
      id: technical-implementation
      title: Technical Implementation
      center:
        trailId: migration/trails/stackit/spring-boot-postgresql-rehost-technical-walkthrough
    - style: summit
      id: operating-handoff
      title: Accept and Hand Over to Operations
      trailContext: Release the migrated system only after technical and business acceptance. Hand over ownership, monitoring, recovery and source retention; stabilize before optimization changes.
      assetId: migration/assetcontainer/stackit/runbook-rehost-spring-boot#handover-to-operations

    - style: "summit"
      id: "optimize-framework"
      title: "Optimization"
      trailContext: "Return from the concrete migration example to the Migration Framework. Start optimization only after stable cutover, use representative production telemetry, implement one controlled change at a time, and validate its effect on reliability, performance, and cost."
      description: "The framework loop defines how to collect evidence, prioritize improvements, implement controlled changes, validate outcomes, and feed lessons into later migration waves."
      pageId: "migration/migrate/optimize/overview/#understanding-the-optimize-module"

    - role: "sub"
      id: "optimize-target"
      title: "Select an Optimization Candidate"
      trailContext: "After stabilization, correlate VM capacity, Spring Boot health, PostgreSQL pressure, latency, errors, and cost over a representative period before changing the target."
      description: "Use the dashboard and defined thresholds to distinguish a compute bottleneck from database or storage pressure before changing capacity. Select one dominant change so its effect remains measurable."
      assetId: "migration/assetcontainer/stackit/optimize-rehosted-spring-boot-observability-rightsizing#observability-decision-dashboard"

  presentations:
    - id: "validated-rehost-path"
      label: "Rehost overview"
      description: "Presentation of strategy, architecture, migration controls and operations, without executable walkthrough commands."
      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/migration/trails/stackit/spring-boot-postgresql-rehost-to-stackit/"
source_file: "docs/migration/trails/stackit/spring-boot-postgresql-rehost-to-stackit.mdx"
---

## Steps

### 1. Spring Boot Rehost Journey

Stage: `compass`

Open with the complete Migration Framework so the audience can place workload assessment, Rehost design, controlled migration, stabilization, and optimization in one end-to-end journey.

### 2. Rapid Discovery

Stage: `compass`

Build a lightweight workload baseline for the Spring Boot runtime, PostgreSQL data path, dependencies, and initial capacity signals. Use it to qualify migration intent, expose unknowns, and define what detailed Discovery must validate before target design; do not treat early assumptions as verified inputs.

Page: [/migration/assess/rapid-discovery/overview/#overview](/migration/assess/rapid-discovery/overview/#overview) — source: [/raw/migration/assess/rapid-discovery/overview.md](/raw/migration/assess/rapid-discovery/overview.md), section `#overview`

### 3. Discovery

Stage: `stairs`

Combine application-owner evidence with technical measurements of dependencies, Java and PostgreSQL versions, service behavior, data size and change rate, operating constraints, recovery objectives, and representative resource use. Confirm compatibility, migration constraints, and the target capacity baseline before design.

Page: [/migration/design-and-mobilize/discovery/overview/#understanding-discovery](/migration/design-and-mobilize/discovery/overview/#understanding-discovery) — source: [/raw/migration/design-and-mobilize/discovery/overview.md](/raw/migration/design-and-mobilize/discovery/overview.md), section `#understanding-discovery`

### 4. Rehost Strategy

Stage: `chairlift`

Use Discovery evidence to confirm that preserving the Spring Boot JAR, systemd service model, and PostgreSQL engine on a VM meets the migration goals; Kubernetes, Cloud Foundry, or PostgreSQL Flex would instead be Replatform. Derive the delivery sequence from that decision: Landing Zone, Terraform infrastructure, Ansible configuration, separate PostgreSQL migration, and the rehearsed runbook.

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

### 5. Automate with Terraform and Ansible

Stage: `stairs`

Separate infrastructure lifecycle from target configuration: Terraform or OpenTofu creates and reconciles STACKIT resources, while Ansible configures the reachable operating system, middleware, application, and validation controls.

Use one versioned delivery flow with plan review, explicit handoff between tools, idempotent configuration, and retained validation evidence.

Page: [/migration/design-and-mobilize/landing-zones/automation-iac/#terraformopentofu-and-ansible-delivery-flow](/migration/design-and-mobilize/landing-zones/automation-iac/#terraformopentofu-and-ansible-delivery-flow) — source: [/raw/migration/design-and-mobilize/landing-zones/automation-iac.md](/raw/migration/design-and-mobilize/landing-zones/automation-iac.md), section `#terraformopentofu-and-ansible-delivery-flow`

### 6. Target Architecture

Stage: `chart`

Review the resulting one-VM baseline: Spring Boot under systemd, self-managed PostgreSQL on localhost, restricted ingress, Observability scraping, and boot-volume backup. Record the shared failure domain explicitly.

The target preserves the VM-centric runtime and database model while adding restricted ingress, reproducible configuration, managed telemetry, and VM-level backup. The application and database still share one failure domain.

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

### 7. Database Migration

Stage: `gondola`

After the infrastructure and runtime path is defined, separate application preparation from PostgreSQL export, transfer, restore, and integrity validation. Define the write freeze, final dump, rollback deadline, and source retention before execution.

Freeze source writes, create and qualify the final PostgreSQL dump, rehearse an isolated restore, protect the pre-cutover target state, and accept or roll back from objective integrity evidence.

Page: [/migration/design-and-mobilize/design/rehost/#data-migration-path-in-rehost](/migration/design-and-mobilize/design/rehost/#data-migration-path-in-rehost) — source: [/raw/migration/design-and-mobilize/design/rehost.md](/raw/migration/design-and-mobilize/design/rehost.md), section `#data-migration-path-in-rehost`

### 8. Landing Zone

Stage: `hut`

Establish the governed cloud foundation before the Rehost target depends on it. Use the six core components as the readiness frame: every control needs an owner, an approved implementation, and evidence before Terraform provisions the Spring Boot target.

Page: [/migration/design-and-mobilize/landing-zones/overview/#understanding-landing-zones](/migration/design-and-mobilize/landing-zones/overview/#understanding-landing-zones) — source: [/raw/migration/design-and-mobilize/landing-zones/overview.md](/raw/migration/design-and-mobilize/landing-zones/overview.md), section `#understanding-landing-zones`

### 9. Accelerate the Foundation as Code

Use the STACKIT Landing Zone Accelerator to create reusable organization folders, platform projects, connectivity, management services, and the workload-ready Application Landing Zone before the Rehost automation deploys its VM.

Keep the boundary explicit: the Accelerator provides the governed environment; the application team deploys Spring Boot, PostgreSQL, telemetry, and backup into the approved Application Landing Zone.

### 10. Migration Framework

Stage: `rocket`

Enter execution only with approved design decisions, a ready Application Landing Zone, an assigned wave, and a factory-ready runbook. Execute readiness, migration, cutover, validation, stabilization, and handover as one controlled flow.

The Migration Framework defines the sequence and control points first; the following Rehost assets then instantiate that flow for Spring Boot and PostgreSQL.

Page: [/migration/migrate/migrate/overview/#end-to-end-factory-flow](/migration/migrate/migrate/overview/#end-to-end-factory-flow) — source: [/raw/migration/migrate/migrate/overview.md](/raw/migration/migrate/migrate/overview.md), section `#end-to-end-factory-flow`

### 11. Migration Decision Gates

Stage: `shield`

Review readiness, rehearsal, cutover approval, acceptance and recovery as separate decisions before assigning execution responsibilities.

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

### 12. Technical Implementation

Stage: `hut`

### 13. Accept and Hand Over to Operations

Stage: `summit`

Release the migrated system only after technical and business acceptance. Hand over ownership, monitoring, recovery and source retention; stabilize before optimization changes.

Asset: [/migration/assetcontainer/stackit/runbook-rehost-spring-boot/#handover-to-operations](/migration/assetcontainer/stackit/runbook-rehost-spring-boot/#handover-to-operations) — source: [/raw/migration/assetcontainer/stackit/runbook-rehost-spring-boot.md](/raw/migration/assetcontainer/stackit/runbook-rehost-spring-boot.md), section `#handover-to-operations`

### 14. Optimization

Stage: `summit`

Return from the concrete migration example to the Migration Framework. Start optimization only after stable cutover, use representative production telemetry, implement one controlled change at a time, and validate its effect on reliability, performance, and cost.

The framework loop defines how to collect evidence, prioritize improvements, implement controlled changes, validate outcomes, and feed lessons into later migration waves.

Page: [/migration/migrate/optimize/overview/#understanding-the-optimize-module](/migration/migrate/optimize/overview/#understanding-the-optimize-module) — source: [/raw/migration/migrate/optimize/overview.md](/raw/migration/migrate/optimize/overview.md), section `#understanding-the-optimize-module`

### 15. Select an Optimization Candidate

After stabilization, correlate VM capacity, Spring Boot health, PostgreSQL pressure, latency, errors, and cost over a representative period before changing the target.

Use the dashboard and defined thresholds to distinguish a compute bottleneck from database or storage pressure before changing capacity. Select one dominant change so its effect remains measurable.

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