---
title: "Rehost to STACKIT: Spring Boot with Terraform and Ansible"
description: "Rehost Spring Boot and PostgreSQL to a STACKIT VM with Terraform and Ansible: prepare inputs, provision, rehearse, cut over, validate, and hand over operations."
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 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: "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: "rocket"
      id: "reference-implementation"
      title: "Reference Implementation"
      trailContext: "Move from framework guidance to the concrete Spring Boot and PostgreSQL example. Use the maintained repository as the source of truth for Terraform, Ansible, migration scripts, validation, and runtime configuration; the following steps apply its workflows."
      description: "The reference implementation demonstrates one tested Rehost topology. Adapt sizing, security, availability, and operating controls to the workload instead of treating the example as a universal target design."
      assetId: "migration/assetcontainer/stackit/rehost-automation-spring-boot-terraform-ansible#reference-implementation"

    - style: "hut"
      id: "prepare-workspace"
      title: "Prepare the Workspace"
      trailContext: "Use the pinned repository revision on a prepared Linux lab host. Confirm tools and privileges before generating sample data or deploying resources."
      assetId: "migration/assetcontainer/stackit/rehost-automation-spring-boot-terraform-ansible#prepare-the-walkthrough-workspace"

    - style: "shield"
      id: "configure-target"
      title: "Configure Private Target Inputs"
      trailContext: "Set project, credentials, SSH trust, ingress and sizing explicitly. Keep source restore disabled for initial provisioning so rehearsal remains a separate gate."
      assetId: "migration/assetcontainer/stackit/rehost-automation-spring-boot-terraform-ansible#configure-the-target-inputs"

    - style: "shield"
      id: "source-target-readiness"
      title: "Prepare Source Evidence"
      trailContext: Capture and validate the source dump, manifest and data boundary before target provisioning. Keep the source and isolated test data unambiguous.
      assetId: migration/assetcontainer/stackit/rehost-automation-spring-boot-terraform-ansible#prepare-source-evidence
    - style: hut
      id: provision-target
      title: Provision the Target
      trailContext: Review target inputs and the infrastructure plan, provision the resources, and retain the results before migration rehearsal.
      assetId: migration/assetcontainer/stackit/rehost-automation-spring-boot-terraform-ansible#provision-the-target

    - style: "stairs"
      id: "rehearse-and-approve"
      title: "Rehearse and Approve"
      splitRatio: 50
      left:
        - assetId: "migration/assetcontainer/stackit/rehost-automation-spring-boot-terraform-ansible#rehearse-the-migration"
      right:
        - assetId: "migration/assetcontainer/stackit/runbook-rehost-spring-boot#pre-migration-checks"

    - style: "rocket"
      id: "execute-cutover"
      title: "Cutover"
      trailContext: "Run the explicitly confirmed cutover workflow. Permit replacement only of the Ansible orchestration resource, restore the final dump, validate the application and data, and require a final Terraform no-op plan."
      assetId: "migration/assetcontainer/stackit/runbook-rehost-spring-boot#run-plan-cutover-window"
      imageSrc: "migration/files/migrate-wave-flow.svg"
      imageAlt: "Controlled migration wave from readiness through cutover, validation, and handover"
      imagePosition: right
      imageWidth: 48

    - style: "rocket"
      id: "run-cutover"
      title: "Run the Approved Cutover"
      trailContext: "Set the final source evidence and execute the explicit confirmation gate only within the approved window, with a fresh backup and rollback authority."
      assetId: "migration/assetcontainer/stackit/rehost-automation-spring-boot-terraform-ansible#execute-cutover"

    - style: "shield"
      id: "validate-or-rollback"
      title: "Validate or Roll Back"
      splitRatio: 50
      left:
        - assetId: "migration/assetcontainer/stackit/runbook-rehost-spring-boot#validation-checklist"
      right:
        - assetId: "migration/assetcontainer/stackit/runbook-rehost-spring-boot#rollback-criteria-and-steps"

    - style: "shield"
      id: "validate-data-and-runtime"
      title: "Verify Data and Runtime"
      trailContext: "Run the independent validation commands and verify the protected rollback dump. Execute rollback only when its decision gate is met, not as an automatic next step."
      assetId: "migration/assetcontainer/stackit/rehost-automation-spring-boot-terraform-ansible#validate-and-roll-back"

    - style: "shield"
      id: "verify-acceptance"
      title: "Retain Apply and Acceptance Evidence"
      trailContext: "Distinguish a proposed plan from completed apply and accepted data. Require the final no-op with the same source inputs and retain machine-readable workflow evidence."
      assetId: "migration/assetcontainer/stackit/rehost-automation-spring-boot-terraform-ansible#evidence-and-acceptance"

    - style: "summit"
      id: "stabilize-and-optimize"
      title: "Stabilization"
      splitRatio: 50
      left:
        - assetId: "migration/assetcontainer/stackit/runbook-rehost-spring-boot#handover-to-operations"
      right:
        - assetId: "migration/assetcontainer/stackit/rehost-automation-spring-boot-terraform-ansible#backup-and-recovery-boundary"

    - 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"

    - style: "chart"
      id: "optimize-reference-implementation"
      title: "Continue the Same Reference Implementation"
      trailContext: "Apply the framework Optimize loop to the same Spring Boot and PostgreSQL repository used for provisioning, rehearsal, cutover, and stabilization. No second example or repository is introduced."
      description: "Reuse its Terraform variables, Ansible configuration, STACKIT Observability data, and validation workflows for the following compute and storage decisions."
      assetId: "migration/assetcontainer/stackit/optimize-rehosted-spring-boot-observability-rightsizing#continue-the-reference-implementation"

    - 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"

    - style: "chart"
      id: "optimize-compute"
      title: "Right-size the VM Flavor"
      trailContext: "Change machine_type in env.tfvars only after representative telemetry identifies sustained overprovisioning or overload. Inspect the Terraform plan, apply in an approved window, and compare health, latency, errors, throughput, and cost with the baseline."
      description: "The runnable example demonstrates both downsize and scale-up changes. Revert the previous machine type through the same reviewed IaC workflow when acceptance criteria regress."
      assetId: "migration/assetcontainer/stackit/optimize-rehosted-spring-boot-observability-rightsizing#example-a-downsize-after-sustained-low-utilization"

    - style: "shield"
      id: "optimize-storage"
      title: "Decide the Storage Path"
      trailContext: "Select the storage performance class from measured IOPS, throughput, latency, backup activity, and growth headroom before provisioning. The operating system, application, and PostgreSQL data share the boot volume in this baseline."
      description: "Use a controlled replacement target when the shared boot volume needs another performance class. Use a separate data volume when storage must evolve independently, and migrate verified data to a newly created volume before switching."
      assetId: "migration/assetcontainer/stackit/optimize-rehosted-spring-boot-observability-rightsizing#storage-as-optimization-dimension"

    - style: "gondola"
      id: "replatform-baseline"
      title: "Reuse the Rehost Baseline"
      trailContext: "Separate reuse of the pinned JAR and local sample artifacts from a real export of the running Rehost VM before planning the next platform transition."
      assetId: "migration/assetcontainer/stackit/rehost-automation-spring-boot-terraform-ansible#reuse-as-a-replatform-baseline"
      role: sub

  presentations:

    - id: "technical-rehost-path"
      label: "Technical walkthrough"
      description: "Reproduce the VM reference with source preparation, reviewed Terraform provisioning, rehearsal, cutover, rollback and optional optimization."
      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 after stabilization and acceptance. Rightsizing is not part of the cutover and requires a separate approved change window.
        - 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/migration/trails/stackit/spring-boot-postgresql-rehost-technical-walkthrough/"
source_file: "docs/migration/trails/stackit/spring-boot-postgresql-rehost-technical-walkthrough.mdx"
---

## Steps

### 1. 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`

### 2. 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`

### 3. Reference Implementation

Stage: `rocket`

Move from framework guidance to the concrete Spring Boot and PostgreSQL example. Use the maintained repository as the source of truth for Terraform, Ansible, migration scripts, validation, and runtime configuration; the following steps apply its workflows.

The reference implementation demonstrates one tested Rehost topology. Adapt sizing, security, availability, and operating controls to the workload instead of treating the example as a universal target design.

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

### 4. Prepare the Workspace

Stage: `hut`

Use the pinned repository revision on a prepared Linux lab host. Confirm tools and privileges before generating sample data or deploying resources.

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

### 5. Configure Private Target Inputs

Stage: `shield`

Set project, credentials, SSH trust, ingress and sizing explicitly. Keep source restore disabled for initial provisioning so rehearsal remains a separate gate.

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

### 6. Prepare Source Evidence

Stage: `shield`

Capture and validate the source dump, manifest and data boundary before target provisioning. Keep the source and isolated test data unambiguous.

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

### 7. Provision the Target

Stage: `hut`

Review target inputs and the infrastructure plan, provision the resources, and retain the results before migration rehearsal.

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

### 8. Rehearse and Approve

Stage: `stairs`

### 9. Cutover

Stage: `rocket`

Run the explicitly confirmed cutover workflow. Permit replacement only of the Ansible orchestration resource, restore the final dump, validate the application and data, and require a final Terraform no-op plan.

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

### 10. Run the Approved Cutover

Stage: `rocket`

Set the final source evidence and execute the explicit confirmation gate only within the approved window, with a fresh backup and rollback authority.

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

### 11. Validate or Roll Back

Stage: `shield`

### 12. Verify Data and Runtime

Stage: `shield`

Run the independent validation commands and verify the protected rollback dump. Execute rollback only when its decision gate is met, not as an automatic next step.

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

### 13. Retain Apply and Acceptance Evidence

Stage: `shield`

Distinguish a proposed plan from completed apply and accepted data. Require the final no-op with the same source inputs and retain machine-readable workflow evidence.

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

### 14. Stabilization

Stage: `summit`

### 15. 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`

### 16. Continue the Same Reference Implementation

Stage: `chart`

Apply the framework Optimize loop to the same Spring Boot and PostgreSQL repository used for provisioning, rehearsal, cutover, and stabilization. No second example or repository is introduced.

Reuse its Terraform variables, Ansible configuration, STACKIT Observability data, and validation workflows for the following compute and storage decisions.

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

### 17. 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`

### 18. Right-size the VM Flavor

Stage: `chart`

Change machine_type in env.tfvars only after representative telemetry identifies sustained overprovisioning or overload. Inspect the Terraform plan, apply in an approved window, and compare health, latency, errors, throughput, and cost with the baseline.

The runnable example demonstrates both downsize and scale-up changes. Revert the previous machine type through the same reviewed IaC workflow when acceptance criteria regress.

Asset: [/migration/assetcontainer/stackit/optimize-rehosted-spring-boot-observability-rightsizing/#example-a-downsize-after-sustained-low-utilization](/migration/assetcontainer/stackit/optimize-rehosted-spring-boot-observability-rightsizing/#example-a-downsize-after-sustained-low-utilization) — source: [/raw/migration/assetcontainer/stackit/optimize-rehosted-spring-boot-observability-rightsizing.md](/raw/migration/assetcontainer/stackit/optimize-rehosted-spring-boot-observability-rightsizing.md), section `#example-a-downsize-after-sustained-low-utilization`

### 19. Decide the Storage Path

Stage: `shield`

Select the storage performance class from measured IOPS, throughput, latency, backup activity, and growth headroom before provisioning. The operating system, application, and PostgreSQL data share the boot volume in this baseline.

Use a controlled replacement target when the shared boot volume needs another performance class. Use a separate data volume when storage must evolve independently, and migrate verified data to a newly created volume before switching.

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

### 20. Reuse the Rehost Baseline

Stage: `gondola`

Separate reuse of the pinned JAR and local sample artifacts from a real export of the running Rehost VM before planning the next platform transition.

Asset: [/migration/assetcontainer/stackit/rehost-automation-spring-boot-terraform-ansible/#reuse-as-a-replatform-baseline](/migration/assetcontainer/stackit/rehost-automation-spring-boot-terraform-ansible/#reuse-as-a-replatform-baseline) — source: [/raw/migration/assetcontainer/stackit/rehost-automation-spring-boot-terraform-ansible.md](/raw/migration/assetcontainer/stackit/rehost-automation-spring-boot-terraform-ansible.md), section `#reuse-as-a-replatform-baseline`