Rehost to STACKIT: Spring Boot and PostgreSQL Overview

Adoption genai modernization discovery roadmap

GenDiscover: AI-Powered Modernization Intelligence

Capgemini

Managed Asset Marketplace

Capgemini's GenDiscover is an AI-powered cockpit that turns raw portfolio data into actionable modernization intelligence for enterprise application landscapes.

GenDiscover: AI-Powered Modernization Intelligence

Adoption

Service

Rapid Discovery Process at a Glance

The following diagram shows why Rapid Discovery is performed: raw source data is processed by tooling into a decision-ready baseline that supports early price indication and initial target sizing.

Swipe sideways to see the whole diagram

Method in Practice

A robust Rapid Discovery typically follows a clear sequence:

Collect data from available sources (CMDB, hypervisor exports, cloud inventories, monitoring, storage reports, database lists).
Standardize and consolidate records into a unified schema.
Classify assets by workload type and technical characteristics.
Aggregate results for management-level decision making.
Validate initial assumptions with responsible stakeholders.

The objective is not a perfect target architecture. The objective is a reliable starting point with enough accuracy for early decisions.

Data Quality and Assumptions

Result quality depends heavily on source quality. Typical issues include duplicates, outdated entries, inconsistent naming, and missing performance data.

Recommended practice for this phase:

Document assumptions: Keep growth rates, consolidation factors, and capacity buffers explicit.
Flag unclear records: Mark uncertain entries instead of removing them too early.
Assign confidence levels: Label findings as high, medium, or low confidence.

This keeps cost indications traceable and allows focused refinement in the subsequent Discovery phase.

Link to Price Indication and TCO

Rapid Discovery provides the volume baseline for early cost modeling. Captured assets are translated into STACKIT-relevant consumption dimensions, for example:

Compute sizing: Use vCPU and RAM as the baseline dimensions.
Storage class selection: Use storage capacity and I/O characteristics.
Managed service options: Use database engine and size classes.
Platform cost estimation: Use cluster and node counts.

Combined with operating assumptions (runtime profile, availability targets, growth trajectory), this produces a solid first price indication and an initial TCO corridor.

Typical Outputs

At the end of Rapid Discovery, the following outputs should be available at a minimum:

Consolidated asset baseline

Quantities per technology domain are consolidated in one baseline.

Meaningful segmentation

Assets are segmented by criticality, environment, and modernization potential.

Traceable assumptions

Assumptions and identified data gaps are documented transparently.

Initial cost indication

Cost ranges and primary drivers are available for early planning.

Prioritized candidates

A prioritized list for deeper Discovery activities is available.

These outputs establish the working baseline for architecture, planning, and governance in the next Assess steps.

Risks and Countermeasures

Common Rapid Discovery risks include over-simplified categorization, incomplete source systems, or overestimating data maturity.

Proven countermeasures:

Combine sources: Use multiple data sources instead of relying on one source.
Review outliers: Check very large or very old systems systematically.
Align perspectives: Align finance and engineering interpretation to reduce bias.

This keeps the phase fast while preserving decision quality.

Transition to the Discovery Phase

The handover point is reached when quantities, technology classes, and primary cost levers are sufficiently visible and open questions are clearly documented.

In Discovery, these open items are addressed through targeted owner interviews, deeper assessments, and dependency/compliance/operations analysis to build the full application-level picture.

STEP

Discovery

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.

In 4 trails

Discovery analysis combining technical and application-owner evidence

Understanding Discovery

Discovery is one of the first and most critical modules in the Design and Mobilize phase. It refines Rapid Discovery results and adds the depth needed to make architecture and migration-wave decisions with confidence.

The primary objective is to establish a realistic, evidence-based understanding of the current IT landscape, business priorities, and organizational readiness before detailed target design and migration planning are finalized.

Core Objectives

Complete baseline

Create a reliable application and infrastructure baseline that goes beyond pure quantities.

Dependency transparency

Identify technical and process dependencies to avoid hidden migration blockers.

Business alignment

Link technical findings with business criticality, timelines, and risk tolerance.

Planning readiness

Produce decision-ready input for target design and migration-wave planning.

What Discovery Typically Captures

Inventory

Comprehensive capture of servers, virtual machines, databases, middleware, and applications.

Dependency analysis

Mapping of communication paths and runtime dependencies between systems and applications.

Resource utilization

Analysis of actual CPU, memory, storage, and I/O behavior over a representative period.

Operational context

Collection of backup, patching, SLA, compliance, and operational constraints.

Application owner input

Structured questionnaires and interviews to validate assumptions and close data gaps.

Typical Delivery Setup

In practice, Discovery is often run together with STACKIT partners. Partners typically use their own tooling landscape to collect and normalize technical data into a central repository. Many programs also trigger targeted questionnaires for application owners directly from these tools to enrich technical findings with business and operational context.

This combined model improves speed and consistency while keeping stakeholder validation built into the process.

Two Evidence Streams: Technical vs. Human-Driven

Discovery intentionally combines two evidence streams that complement each other:

Technically derived evidence: Tooling-generated findings from inventory exports, runtime metrics, and dependency signals. This stream provides scale, consistency, and repeatability.
Application-owner enrichment (human-driven): Validated business criticality, lifecycle intent, release constraints, and operational realities from owner interviews and questionnaires.

Neither stream is sufficient on its own. Technical evidence without owner context can misclassify critical workloads, while human input without technical grounding can hide coupling and capacity risks. Discovery quality depends on reconciling both streams into one decision-ready view.

Discovery Process at a Glance

The following diagram shows how Discovery transforms technical and stakeholder input into decision-ready outputs for the downstream modules.

Swipe sideways to see the whole diagram

Typical Analysis Patterns in Discovery Tooling

During Discovery, tooling commonly applies the following analysis patterns:

Record normalization: Merge heterogeneous exports into one coherent application model.
Dependency mapping: Detect communication paths, data exchange, and coupling patterns.
Criticality and risk scoring: Evaluate business impact, failure domain, and compliance exposure.
Utilization profiling: Build workload demand baselines for right-sizing and target planning.
Segmentation analysis: Cluster applications by readiness, constraints, and migration strategy fit.
Wave simulation: Model move groups and sequence options under dependency constraints.
Gap and assumption tracking: Keep unresolved findings transparent with confidence levels.

These analyses establish the technical fact base. The human-driven stream then validates, prioritizes, and contextualizes these findings for executable migration decisions.

AI-assisted discovery assets

Use AI-assisted discovery assets to structure workload inputs, service mapping, readiness findings, and R-strategy signals before architects validate the resulting discovery baseline.

Asset title

Framework

Asset type

Software

CloudMent AI-Powered Cloud Advisor

CloudMent

Migration assess discovery design-and-mobilize design +5

Open Source In 1 trail

Partner software asset for AI-assisted STACKIT migration assessment, R-strategy selection, target design, business case, and evidence-based migration planning.

CloudMent AI-Powered Cloud Advisor

Migration

Software

Adoption genai modernization discovery roadmap

GenDiscover: AI-Powered Modernization Intelligence

Capgemini

Managed Asset Marketplace

Capgemini's GenDiscover is an AI-powered cockpit that turns raw portfolio data into actionable modernization intelligence for enterprise application landscapes.

GenDiscover: AI-Powered Modernization Intelligence

Adoption

Service

Method in Practice

Aggregate source data from CMDBs, hypervisors, cloud inventories, monitoring, and export files.
Normalize and consolidate records into a common application-centric model.
Discover and validate dependencies (network, data, identity, integration, and batch flows).
Enrich with owner input on criticality, lifecycle, constraints, and migration feasibility.
Classify workloads for migration strategy options and wave sequencing.
Validate findings with architecture, security, platform, and business stakeholders.

Why Discovery Is Critical

Reduces migration risk: Early visibility of hidden dependencies lowers outage and rollback risk.
Improves wave planning: Workloads can be grouped realistically by coupling, criticality, and readiness.
Prevents over/under-sizing: Measured utilization replaces assumptions in target capacity planning.
Supports governance: Security, compliance, and operational constraints are addressed before rollout.
Strengthens stakeholder buy-in: Shared facts improve decision quality across business and IT.

Relevance for Follow-On Modules

Discovery outputs are directly reused by the next modules in Design and Mobilize:

Design

Uses dependency, capacity, and risk insights to shape target architecture options.

Security and Compliance

Uses data classification and control gaps to define prioritized security requirements.

Landing Zone

Uses platform and governance constraints to define foundational setup decisions.

Migration Plan

Uses move groups, criticality, and sequencing constraints for realistic wave planning.

Operating Model and Business Case

Uses ownership, process impact, and value/risk signals for staffing and investment priorities.

Discovery Outputs

At minimum, Discovery should produce the following outputs:

Consolidated application baseline: Mapped inventory by domain, environment, and criticality.
Dependency map: Verified upstream/downstream relationships and integration touchpoints.
Utilization profile: Evidence-based resource behavior and sizing assumptions.
Constraint register: Security, compliance, licensing, and operational constraints.
Migration readiness view: Prioritized candidates, risks, and sequencing recommendations.

These outputs are essential prerequisites for continuing with detailed design work and a credible migration plan.

LIFT

Rehost Strategy

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.

In 2 trails

R-strategy method with Rehost as the application-level lift-and-shift path

Understanding Rehost

Rehost (lift-and-shift) migrates workloads with minimal application change. It is primarily a run strategy to reduce transition risk and accelerate migration throughput.

In practical terms, Rehost is application-wave oriented: each workload gets a defined target runtime mapping, cutover path, and runbook package for repeatable factory delivery.

Rehost compared to Relocate in STACKIT

Relocate and Rehost are often used interchangeably, but in this framework they are separated on purpose.

Rehost in STACKIT: Application-level lift-and-shift with explicit target runtime mapping, cutover, rollback, and runbook standardization.
Relocate in STACKIT: Estate-level move of existing virtualization patterns with minimal reshaping of workload runtime behavior.
When to prefer Rehost: When migration waves require repeatable runbooks and stable run operations at scale across many applications.
When to prefer Relocate: When urgent movement of VM estates is the primary goal and modernization is deferred by design.

When Rehost is a good fit

Strict migration timeline with limited engineering capacity for redesign.
Legacy workloads that are difficult to refactor in the current program phase.
Business stability priority where functional behavior must remain largely unchanged.
Factory scale objective where repeatable migration procedures are required across many systems.

Design considerations in STACKIT context

Infrastructure mapping

Define target compute, storage, and network profiles with explicit compatibility checks.

Data and cutover path

Design transfer windows, consistency checks, and rollback triggers.

Stateful workload handling

Separate application artifact rollout from database migration sequencing to reduce cutover risk.

Security and compliance

Map identity controls, encryption requirements, and evidence checkpoints.

Operational handover

Ensure runbooks cover Day-1 operations and incident workflows after migration.

Recommended design flow

Baseline current runtime dependencies and non-functional requirements.
Define target runtime mapping and migration sequence.
Design data movement and cutover orchestration.
Validate runbook quality with dry-run checkpoints.
Approve production migration with release and business sign-off.

Data migration path in Rehost

In Rehost scenarios, the data migration path depends on whether the workload is stateless or stateful:

Stateless workloads: Focus on application deployment and configuration.
Stateful workloads: Require a coordinated data movement strategy alongside the application migration.

For stateful migration waves, split the path into two streams:

Infrastructure and application stream: Provision the target environment, deploy the application, and prepare the target data store.
Data stream: Export source data, transfer to the target, restore, and validate.

Suggested data sequence

Export data from the source system using platform-native or tool-specific methods.
Transfer data to the target environment or intermediate staging area.
Configure the target environment to ingest the migrated data.
Run the restoration process and verify data integrity.
Validate application connectivity and functional behavior before final cutover.

Required outputs

Shared outputs across all migration paths

Approved design decision record with scope, assumptions, and governance sign-off.
Validation evidence package for security, compliance, and operational readiness.
Strategy-specific migration runbook draft from the Design phase.
Handover package for Migration Factory Setup and wave planning.

Rehost-specific outputs

Rehost decision rationale and constraints.
Target runtime mapping.
Data movement and cutover plan.
Runbook with validation and rollback checkpoints.
Post-wave stabilization checklist.

Diagram step reference

Define landing zone

Define landing zone requirements and controls as the start point for Rehost run. Clarify network, identity, backup, and monitoring prerequisites before migration sequencing is approved so Rehost waves can run with predictable operations quality.

Use migration tools

Define the automated Rehost path used for repeatable wave throughput. In the automated Rehost path, infrastructure and application setup are provisioned as code so wave delivery stays repeatable and auditable.

Provision VM target with IaC: Create networks, security groups, compute instances, and base storage through Terraform or OpenTofu.
Install and configure application with automation: Use Ansible playbooks for package install, service setup, and baseline configuration.
Apply environment-specific parameters: Inject target variables, secrets references, and endpoint mappings in a controlled automation run.
Run automated validation and cutover gates: Execute health checks, migration pre-checks, rollback checkpoints, and release approvals before live switch.
Runbook Blueprint
Migration Plan

Asset title

Framework

Asset type

Migration design-and-mobilize design target-architecture rehost spring-boot vm postgresql observability backup

Describe manual installation steps for exception workloads.

Create and prepare target VM manually: Provision the VM through Portal or CLI, attach required storage, and apply OS hardening and patch baseline.
Install runtime and dependencies manually: Install required runtime packages, system libraries, and service users/groups according to product installation guidance.
Install application in the classic way: Perform guided installation steps (for example installer or setup wizard flow) to reproduce the source deployment model on the target VM.
Validate base install readiness: Confirm service startup, file permissions, required ports, DNS reachability, and outbound connectivity.
Cloud Design Patterns
Runbook Blueprint

Config

Define manual runtime configuration and controls.

Mirror source configuration for target context: Recreate application settings from the source environment and adapt them to target endpoints, DNS, certificates, and service integrations.
Apply security and access settings: Configure service credentials, secret handling, and least-privilege access for target operation.
Align operational defaults: Configure logging targets, metrics exporters, backup schedules, and retention baselines.
Validate configuration parity: Run smoke checks to confirm the target instance behaves as a functional equivalent of the source baseline.
Runbook Blueprint

Deploy

Define manual deployment sequencing and release checks.

Plan final migration window: Align freeze windows, communication checkpoints, and rollback authority for production switch.
Run final data migration: Execute last data sync or restore steps and confirm consistency checks before go-live.
Activate production traffic: Perform controlled live switch to the target environment and verify critical user and integration paths.
Confirm handover readiness: Record evidence, close open risks, and transfer ownership for Day-1 operations.
Migration Plan
Runbook Blueprint

STEP

Automate with Terraform and Ansible

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.

In 3 trails

Purpose

Automation ensures that landing-zone capabilities are reproducible, versioned, and tested instead of manually configured.

For migration landing zones, automation is the delivery backbone that connects platform APIs, IaC tools, developer workflows, and release controls into one reliable operating model.

Core automation building blocks

STACKIT API: Use the API as the foundational control surface for platform automation and integration patterns. Documentation
Terraform Provider: Use the official provider for declarative infrastructure provisioning and lifecycle control. Documentation
OpenTofu Provider: Use OpenTofu with the STACKIT provider as an open IaC option with comparable declarative workflows. Documentation
Pulumi: Use Pulumi when teams prefer general-purpose languages for infrastructure automation. Documentation
Ansible: Use Ansible primarily for post-provisioning configuration and operational tasks. In a combined model, Terraform/OpenTofu provision infrastructure while Ansible applies OS and middleware configuration.
STACKIT CLI: Standardize CLI-based operations for scripting, troubleshooting, and repeatable operational run tasks. Documentation
SDKs (Go, Python, Java): Use SDKs for custom automation and service integrations where IaC abstractions are not sufficient. Go SDK , Python SDK , Java SDK .
STACKIT Git: Use Git as the source of truth for IaC modules, policies, and delivery workflows. Documentation
CI/CD Pipeline: Use pipelines for validation, policy checks, controlled promotion, and auditable releases. Documentation
Container Registry: Use a central registry for versioned build artifacts and deployment consistency across environments. Documentation

How these elements work together

Control layer: STACKIT API, CLI, and SDKs provide direct and programmable control interfaces.
Provisioning layer: Terraform/OpenTofu and Pulumi define and reconcile desired infrastructure state.
Configuration layer: Ansible applies host and middleware configuration after infrastructure provisioning.
Delivery layer: Git and CI/CD pipelines enforce quality gates, policy checks, and controlled rollout across environments.
Artifact layer: Container Registry delivers immutable and versioned artifacts for predictable deployments.

Terraform/OpenTofu and Ansible delivery flow

Terraform or OpenTofu and Ansible solve different parts of one delivery workflow. Keep the boundary explicit so infrastructure changes remain reviewable and host configuration remains repeatable.

Terraform / OpenTofu

Own the infrastructure lifecycle: projects, networks, security controls, compute, storage, managed services, and the outputs required by configuration management.

Ansible

Own configuration inside the reachable target: operating-system packages, middleware, application artifacts, service units, and workload-level validation.

Version infrastructure inputs, configuration, and application artifact references in Git.
Validate and review the Terraform/OpenTofu plan, including replacement and security effects.
Apply the approved plan and expose only the target inventory and outputs required by Ansible.
Run Ansible idempotently to configure the operating system, middleware, workload, and telemetry.
Validate infrastructure state, service health, and operational controls, then retain the evidence.
Promote the same versioned workflow through environments instead of repeating manual setup.

Do not use provisioners or ad hoc scripts to blur ownership between both layers. Triggering Ansible from Terraform can be a practical bridge, but each tool must remain independently understandable, testable, and rerunnable.

Recommended operating model

Recommendation 1: Use Git plus CI/CD as default control path and avoid direct manual changes in productive scopes.
Recommendation 2: Choose one primary IaC engine per platform domain (Terraform or OpenTofu) to reduce fragmentation.
Recommendation 3: Use Ansible for configuration management, not as a replacement for declarative infrastructure provisioning.
Recommendation 4: Use SDKs for domain-specific automation where provider resources do not cover required behavior.
Recommendation 5: Version and promote container artifacts through clear environment stages with rollback-ready tags.

Key design decisions

Automation interface strategy: Define where API, CLI, SDK, and IaC tools are used as primary interfaces.
IaC engine strategy: Decide Terraform versus OpenTofu versus Pulumi based on skills, governance, and ecosystem fit.
Module and repository strategy: Define reusable module boundaries, versioning, and ownership.
Pipeline control model: Implement validation, policy checks, approvals, and promotion gates.
Artifact and release strategy: Define registry usage, image versioning, and rollback standards.

Typical outputs

Reusable automation baseline: IaC modules, templates, and configuration playbooks with ownership model.
Delivery blueprint: CI/CD flow with quality gates, policy checks, and staged promotions.
Integration toolkit: Standardized use of CLI and SDK automation for operational and product-specific workflows.
Release baseline: Versioned artifact lifecycle in Container Registry with rollback-ready practices.

Anti-patterns to avoid

Too many automation paradigms: Parallel tool stacks with no clear ownership or governance model.
Provisioning and configuration mixed ad hoc: No clean boundary between IaC provisioning and Ansible configuration.
No artifact discipline: Mutable container tags and unclear release traceability.
CLI scripts without Git and pipeline controls: Operational automation cannot be audited or reproduced reliably.

OPS

Target Architecture

Blueprint

Spring Boot and PostgreSQL on One VM with Observability and Backup

STACKIT

Open Source In 2 trails

Validated Rehost architecture for a Spring Boot JAR and self-managed PostgreSQL on one STACKIT VM with restricted ingress, Observability, and Server Backup.

Owner

STACKIT

The sovereign European cloud provider behind the framework, delivering IaaS and PaaS from German and Austrian data centers with full digital independence.

Overview

This pattern represents the validated low-change target for the Spring Boot Rehost example. The JAR continues to run as a systemd service, while PostgreSQL remains self-managed on the same VM. The runtime and database operating models therefore stay VM-centric.

The baseline is intentionally one VM. It demonstrates repeatable migration controls and operations readiness, not application or database high availability.

Typical use case

Low change tolerance: business behavior must remain stable during migration.
Short migration windows: runtime relocation should be predictable and repeatable.
Operations continuity: teams keep VM-centric operating procedures while moving to STACKIT.

Architecture diagram

Design best practices

Restrict ingress explicitly: allow SSH and application traffic only from approved source CIDRs; allow exporter traffic only from STACKIT service ranges.
Keep credentials out of state and inventory: pass the PostgreSQL password through the process environment and store the generated runtime environment file as root-only.
Define observability minimum set: include infrastructure and application health metrics before go-live.
Separate recovery layers: use the database pre-restore dump for cutover rollback and Server Backup for VM-level disaster recovery.
State the availability boundary: one VM with a local database has a shared failure domain. Add a load balancer or second node only with a separately designed database and consistency model.
Use explicit security groups and ingress rules: expose only required ports and protocols.

Confirm which volumes the backup policy covers and rehearse recovery independently of cutover rollback. The available server-backup features do not by themselves prove PostgreSQL consistency or the application’s recovery objectives.

From the STACKIT docsFeatures and benefits › FeaturesSource updated 13.11.2025 · copied 06.10.2026

Automated, monitored server backups with easy recovery
Create backups for one, multiple, or all volumes connected to a server at any time
The advanced custom backup schedules enable automated backups to be created
Freely select the retention period after which backups are automatically deleted
Partly restore certain files by seamlessly restoring a volume backup to a new volume

What is this?

This section is copied from the STACKIT docs automatically, several times a day. It cannot be changed here. Changes belong in the STACKIT docs.

Runbook Asset: Rehost Spring Boot with Terraform/OpenTofu and Ansible

Repository usage and required settings

Code & registry github.com STACKIT CMF Rehost Spring Boot repository Open the repository

Copy the example file: cp env.tfvars.example env.tfvars
Set required values:

create_project             = true
target_project_name        = "cmf-rehost-springboot"
target_project_owner_email = "owner@sa.stackit.cloud"
parent_container_id        = "cmf-parent-container-id"
service_account_key_path   = "/path/to/stackit-sa-key.json"

run_ansible                = true
jar_local_path             = "ansible/files/springboot-app.jar"
availability_zone          = "eu01-1"
machine_type               = "g2i.2"
ssh_allowed_cidr           = "203.0.113.10/32"
app_allowed_cidr           = "203.0.113.10/32"
enable_observability       = true
enable_node_exporter       = true
enable_local_postgresql    = true
enable_server_backup       = true

Optional CMF feature wrapper (flags.env):

setup_project=true
setup_observability=true
setup_database=false
setup_workload=true
setup_loadgen=false
setup_dns=false

Apply:

terraform init
terraform apply -var-file=env.tfvars

Expected result: application_url serves the Spring Boot app directly from the VM on the configured application port. PostgreSQL listens for the application on localhost, Observability scrapes node exporter, and the boot volume has an enabled daily backup schedule.

Availability boundary and extensions

This baseline has no automatic failover. A load-balancer or multi-VM variant is useful only after application session handling, PostgreSQL placement, write consistency, health checks, TLS, and traffic switching have been designed and tested together. Treat that as a separate architecture decision, not as an implicit property of this Rehost path.

AUTO

Database Migration

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.

In 2 trails

Controlled PostgreSQL Rehost path from source freeze and evidence through rehearsal, transactional cutover, acceptance, or rollback

Understanding Rehost

Rehost (lift-and-shift) migrates workloads with minimal application change. It is primarily a run strategy to reduce transition risk and accelerate migration throughput.

In practical terms, Rehost is application-wave oriented: each workload gets a defined target runtime mapping, cutover path, and runbook package for repeatable factory delivery.

Rehost compared to Relocate in STACKIT

Relocate and Rehost are often used interchangeably, but in this framework they are separated on purpose.

Rehost in STACKIT: Application-level lift-and-shift with explicit target runtime mapping, cutover, rollback, and runbook standardization.
Relocate in STACKIT: Estate-level move of existing virtualization patterns with minimal reshaping of workload runtime behavior.
When to prefer Rehost: When migration waves require repeatable runbooks and stable run operations at scale across many applications.
When to prefer Relocate: When urgent movement of VM estates is the primary goal and modernization is deferred by design.

When Rehost is a good fit

Strict migration timeline with limited engineering capacity for redesign.
Legacy workloads that are difficult to refactor in the current program phase.
Business stability priority where functional behavior must remain largely unchanged.
Factory scale objective where repeatable migration procedures are required across many systems.

Design considerations in STACKIT context

Infrastructure mapping

Define target compute, storage, and network profiles with explicit compatibility checks.

Data and cutover path

Design transfer windows, consistency checks, and rollback triggers.

Stateful workload handling

Separate application artifact rollout from database migration sequencing to reduce cutover risk.

Security and compliance

Map identity controls, encryption requirements, and evidence checkpoints.

Operational handover

Ensure runbooks cover Day-1 operations and incident workflows after migration.

Recommended design flow

Baseline current runtime dependencies and non-functional requirements.
Define target runtime mapping and migration sequence.
Design data movement and cutover orchestration.
Validate runbook quality with dry-run checkpoints.
Approve production migration with release and business sign-off.

Data migration path in Rehost

In Rehost scenarios, the data migration path depends on whether the workload is stateless or stateful:

Stateless workloads: Focus on application deployment and configuration.
Stateful workloads: Require a coordinated data movement strategy alongside the application migration.

For stateful migration waves, split the path into two streams:

Infrastructure and application stream: Provision the target environment, deploy the application, and prepare the target data store.
Data stream: Export source data, transfer to the target, restore, and validate.

Suggested data sequence

Export data from the source system using platform-native or tool-specific methods.
Transfer data to the target environment or intermediate staging area.
Configure the target environment to ingest the migrated data.
Run the restoration process and verify data integrity.
Validate application connectivity and functional behavior before final cutover.

Required outputs

Shared outputs across all migration paths

Approved design decision record with scope, assumptions, and governance sign-off.
Validation evidence package for security, compliance, and operational readiness.
Strategy-specific migration runbook draft from the Design phase.
Handover package for Migration Factory Setup and wave planning.

Rehost-specific outputs

Rehost decision rationale and constraints.
Target runtime mapping.
Data movement and cutover plan.
Runbook with validation and rollback checkpoints.
Post-wave stabilization checklist.

Diagram step reference

Define landing zone

Define landing zone requirements and controls as the start point for Rehost run. Clarify network, identity, backup, and monitoring prerequisites before migration sequencing is approved so Rehost waves can run with predictable operations quality.

Use migration tools

Define the automated Rehost path used for repeatable wave throughput. In the automated Rehost path, infrastructure and application setup are provisioned as code so wave delivery stays repeatable and auditable.

Provision VM target with IaC: Create networks, security groups, compute instances, and base storage through Terraform or OpenTofu.
Install and configure application with automation: Use Ansible playbooks for package install, service setup, and baseline configuration.
Apply environment-specific parameters: Inject target variables, secrets references, and endpoint mappings in a controlled automation run.
Run automated validation and cutover gates: Execute health checks, migration pre-checks, rollback checkpoints, and release approvals before live switch.
Runbook Blueprint
Migration Plan

Asset title

Framework

Asset type

Open Platform Landing Zone

Describe manual installation steps for exception workloads.

Create and prepare target VM manually: Provision the VM through Portal or CLI, attach required storage, and apply OS hardening and patch baseline.
Install runtime and dependencies manually: Install required runtime packages, system libraries, and service users/groups according to product installation guidance.
Install application in the classic way: Perform guided installation steps (for example installer or setup wizard flow) to reproduce the source deployment model on the target VM.
Validate base install readiness: Confirm service startup, file permissions, required ports, DNS reachability, and outbound connectivity.
Cloud Design Patterns
Runbook Blueprint

Config

Define manual runtime configuration and controls.

Mirror source configuration for target context: Recreate application settings from the source environment and adapt them to target endpoints, DNS, certificates, and service integrations.
Apply security and access settings: Configure service credentials, secret handling, and least-privilege access for target operation.
Align operational defaults: Configure logging targets, metrics exporters, backup schedules, and retention baselines.
Validate configuration parity: Run smoke checks to confirm the target instance behaves as a functional equivalent of the source baseline.
Runbook Blueprint

Deploy

Define manual deployment sequencing and release checks.

Plan final migration window: Align freeze windows, communication checkpoints, and rollback authority for production switch.
Run final data migration: Execute last data sync or restore steps and confirm consistency checks before go-live.
Activate production traffic: Perform controlled live switch to the target environment and verify critical user and integration paths.
Confirm handover readiness: Record evidence, close open risks, and transfer ownership for Day-1 operations.
Migration Plan
Runbook Blueprint

BASE

Landing Zone

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.

In 5 trails

Six core components of a secure STACKIT landing zone: governance, identity, security, network, cost control, and automation

Understanding Landing Zones

A landing zone is the structured cloud foundation that defines how your organization operates on STACKIT from day 1. It combines governance, identity, security, network design, cost controls, and automation into one coherent baseline.

Without this foundation, migration waves typically stall due to missing approvals, inconsistent controls, and repeated platform decisions.

Core components

The following visual summarizes the core components that should be addressed for a reliable platform baseline.

Why you need a landing zone

Control and risk reduction: Enforce security and compliance controls consistently across teams.
Scalable delivery baseline: Enable repeatable provisioning patterns for multiple migration waves.
Clear responsibilities: Define ownership boundaries for platform, security, and application teams.
Faster migration throughput: Avoid redesigning core controls for each application move.

When to start

Start the landing-zone stream as early as possible, in parallel with discovery.

Too late: Productive migrations are blocked because mandatory controls are not yet available.
Too early without discovery feedback: Application constraints are missed and later cause rework.

The practical model is a dual track: establish the platform baseline early, then refine application landing zone templates as discovery insights mature.

Two layers: Platform and Application Landing Zones

Platform Landing Zone

Company-wide foundation for governance, identity, security, networking, cost controls, and automation.

Application Landing Zone

Workload-specific implementation patterns derived from the platform baseline and discovery findings.

Open Application Landing Zone

Typical enterprise inputs

To design a landing zone effectively, enterprises usually provide:

Organization and ownership model: Entities, project boundaries, and accountability model.
Compliance and policy requirements: Regulatory obligations and internal control policies.
Security requirements: IAM standards, network segmentation, encryption, and logging expectations.
Operations and support constraints: Incident handling, escalation paths, and handover model.
Application portfolio insights: Discovery findings about workload archetypes and dependencies.

Delivery model

Define enterprise guardrails and target control model.
Build and validate the platform landing zone baseline as code.
Derive application landing zone templates from discovery and migration design.
Pilot with selected workloads, then scale through migration factory runbooks.

STACKIT acceleration assets

To accelerate delivery, STACKIT provides concrete best practices and reusable templates:

Asset title

Framework

Asset type

Blueprint

STACKIT

Migration design-and-mobilize landing-zone dev-platform backstage +3

Migration design-and-mobilize landing-zone dev-platform terragrunt +2

Discover how Backstage and Port provide developers with customizable software catalogs, golden paths, and centralized visibility for STACKIT deployments.

Developer Portals & Catalogs

Migration

Guide

IaC Orchestration

STACKIT

Migration design-and-mobilize landing-zone dev-platform terraform +3

Keep your Infrastructure as Code DRY and seamlessly manage complex multi-environment STACKIT deployments with Terragrunt for advanced IaC orchestration.

IaC Orchestration

Migration

Guide

Infrastructure as Code (IaC)

STACKIT

Learn to provision fundamental STACKIT landing zone resources like SKE clusters and networks using Terraform, OpenTofu, and Pulumi for reliable setups.

Infrastructure as Code (IaC)

Migration

Guide

Migration design-and-mobilize landing-zone managed-service opentofu +1

Managed Landing Zone Service

STACKIT

Managed Asset Marketplace In 1 trail

STACKIT managed service for consulting, setup, and implementation of enterprise landing zones using OpenTofu, `Terragrunt`, and boilerplate accelerators.

Managed Landing Zone Service

Migration

Service

Blueprint

meshStack Self-Service Landing Zone

meshcloud

Migration design-and-mobilize landing-zone dev-platform opentofu

Migration design-and-mobilize landing-zone network network-area +3

Reference architecture that adds governed self-service on top of a STACKIT landing zone, so application teams order projects and routed networks themselves.

meshStack Self-Service Landing Zone

Migration

Blueprint

Software

pfSense Firewall Connectivity Pattern

STACKIT

Guidance for using the STACKIT Quick Deployment pfSense firewall as the central control point in hub-and-spoke network area architectures on the STACKIT Cloud.

pfSense Firewall Connectivity Pattern

Migration

Software

Migration design-and-mobilize landing-zone caf managed-service +1

CAF Landing Zones Implementation (PRODYNA)

PRODYNA

Managed Asset Marketplace In 1 trail

CAF landing zones implementation by PRODYNA: managed landing zone delivery service for enterprise cloud adoption and migration enablement on the STACKIT Cloud.

CAF Landing Zones Implementation (PRODYNA)

Migration

Service

Guide

Full IDPs & Cloud Foundations

STACKIT

Migration design-and-mobilize landing-zone dev-platform crossplane +4

Explore how open source solutions like Crossplane and Backstage provide a fully managed central control plane for landing zone orchestration, automated compliance, and FinOps on STACKIT.

Full IDPs & Cloud Foundations

Migration

Guide

Advisory landing-zone setup governance security

5-Day STACKIT Landing Zone Integration & Setup

REWION

Managed Asset

REWION delivers a rapid five-day STACKIT landing zone setup with organization, IAM, network, security, governance, automation, and onboarding foundations.

5-Day STACKIT Landing Zone Integration & Setup

Advisory

Service

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.

Landing Zone Accelerator architecture separating platform, application landing zone, and workload responsibilities

LIVE

Migration Framework

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.

In 4 trails

Understanding the Migrate module

This module executes the actual migration delivery in the Migration Factory. By this point, design decisions are approved, landing zones are ready, and wave plans are defined.

Migrate focuses on repeatable technical run patterns for:

Relocate: Move workloads with minimal change in platform assumptions.
Rehost: Lift and shift workloads to STACKIT with controlled cutover and rollback readiness.
Replatform: Apply targeted platform changes during migration without a full application redesign.

Upstream dependencies

Migrate starts after Design and Mobilize has produced implementable inputs:

Application design per workload: Target-state scope, interface decisions, data handling, and non-functional requirements are defined.
Wave assignment: Every workload is assigned to an approved migration wave with timing and dependency logic.
Runbook availability: A validated runbook exists per migration path and workload archetype, including go/no-go, cutover, and rollback criteria.
Application Landing Zone mapping: Workloads are mapped to the correct target landing zone and ownership model.
Decision and communication model: Decision paths, escalation process, and communication with the Application Owner are defined, including whether cutover must be performed jointly.

Reference modules:

End-to-end factory flow

Confirm wave scope, cutover window, rollback criteria, and runbook ownership.
Freeze wave baseline (application version, dependencies, data scope, and interface contracts).
Run pre-migration technical readiness checks in source and target environments.
Run migration runbook steps per workload archetype and R-strategy path.
Perform cutover and route traffic to the STACKIT target according to the wave plan.
Validate technical, functional, and operational acceptance criteria.
Stabilize incidents and known defects in short feedback loops.
Hand over stabilized workloads to Optimize and Operate.

Run path by migration path

Relocate flow

Recreate workload placement in STACKIT with equivalent topology assumptions.
Migrate data and state with consistency checks.
Cut over traffic with rollback guardrails.
Validate business continuity and operational telemetry.

Rehost flow

Move application and data components largely unchanged.
Reconfigure infrastructure bindings and connectivity on STACKIT.
Run controlled cutover and smoke tests.
Complete stabilization and baseline performance validation.

Replatform flow

Introduce selected managed services or platform capabilities during migration.
Adapt configuration, deployment packaging, and operational controls.
Cut over with compatibility and data integrity checks.
Validate SLO behavior and operating model readiness.

Core outputs per wave

Runbook evidence

Completed runbook records, decision logs, and rollback checkpoints for each migrated workload.

Cutover report

Time-stamped cutover outcome with acceptance results, defects, and mitigation actions.

Operational baseline

Initial monitoring, alerting, ownership, and incident procedures in the target setup.

Optimize backlog

Structured list of rightsizing, performance, and cost measures for post-cutover tuning.

Boundary to optimize, repurchase, and refactor

Optimize starts directly after stable cutover and uses production telemetry to tune performance and cost: Optimize.
Repurchase follows a different SaaS transition logic and is treated as a dedicated module outside wave-based factory mechanics: Repurchase.
Refactor is typically run as a separate transformation stream: Refactor.

Post-cutover care can overlap with Optimize after cutover, but it is handled in the Run phase.

SAFE

Migration Decision Gates

Migration design-and-mobilize design runnable-example rehost automation terraform ansible spring-boot

Rehost Spring Boot with Terraform and Ansible

STACKIT

Open Source In 2 trails

Runnable Rehost automation for a Spring Boot JAR on one STACKIT VM with local PostgreSQL, rehearsed cutover, rollback evidence, Observability, and Server Backup.

Owner

STACKIT

The sovereign European cloud provider behind the framework, delivering IaaS and PaaS from German and Austrian data centers with full digital independence.

Reference implementation

The Migration Framework defines the strategy, design, landing-zone, migration, and operations principles for Rehost workloads. This asset applies those principles to one concrete, runnable Spring Boot and PostgreSQL implementation on STACKIT.

The maintained repository is the source of truth for Terraform, Ansible, application artifacts, migration scripts, validation, and runtime configuration. This asset explains how to use that implementation without duplicating its complete source code.

Code & registry github.com STACKIT CMF Rehost Spring Boot repository Open the runnable Terraform and Ansible reference implementation for the Spring Boot and PostgreSQL Rehost path. Open the repository

Migration context and scope

This example represents an application Rehost path for a Spring Boot workload (Spring Music sample). The migration focus is the runtime relocation of the application to STACKIT:

Infrastructure Rehost: Terraform provisions one STACKIT VM, its boot volume, network, public IP, security group, SSH key, Observability resources, and an optional Server Backup schedule.
Application Rehost: Ansible installs Java, deploys the Spring Boot JAR, and manages it with systemd without changing the application runtime model.
Stateful Rehost: Ansible installs self-managed PostgreSQL on the same VM. The database engine is not changed to a managed service as part of this path.
Controlled migration: The repository provides separate rehearsal, cutover, validation, and rollback workflows with machine-readable evidence.

The validated baseline deliberately does not include an application load balancer, DNS switch, multiple VMs, Kubernetes, Cloud Foundry, or PostgreSQL Flex. Add those only as separately designed and tested extensions; they are not implied by this Rehost example.

What is included in the repository

Provisioning: Terraform resources for network, security, one VM, boot volume, SSH key, and public IP.
Configuration bridge: Terraform triggers Ansible after infrastructure provisioning.
Application deployment: Ansible deploys a concrete Spring Boot artifact and configures a systemd service.
VM-local database path: PostgreSQL installation, application role and database bootstrap, and a dump-based restore with ownership and data-integrity checks.
Operations baseline: Node exporter metrics are scraped by STACKIT Observability, and Terraform can enable daily Server Backup for the VM boot volume.
Migration controls: Source dump generation, independent restore validation, rehearsal, cutover, rollback verification, rollback execution, and evidence capture.
Deployable sample artifact: A ready-to-run JAR is included in the repository and used by default deployment settings.

Unified automation flags

To keep automation behavior consistent across CMF examples, use this common flag model in your Terraform variable set:

setup_project: create/use project context.
setup_observability: enable/disable observability resources.
setup_database: enable/disable optional VM-local PostgreSQL path.
setup_workload: enable/disable workload installation on VM.
setup_loadgen: enable/disable optional synthetic load generation.
setup_dns: accepted by the shared wrapper but unsupported in this baseline.

In the current Rehost repository, these map to existing switches (create_project, enable_observability, enable_local_postgresql, and load-generation related flags).

Validated target architecture

The following diagram shows the implemented and tested target, not a future high-availability variant.

Prepare the walkthrough workspace

Use an isolated Linux lab with Git, Terraform, Ansible, ShellCheck, SSH/SCP, curl, jq, and PostgreSQL server/client tools including pg_config. The sample dump scripts use runuser and the local postgres OS account and require root privileges in that lab. When Server Backup is enabled, the cutover workflow also needs an authenticated STACKIT CLI. Use the Terraform version that created an existing saved plan; plan files are version-specific.

Start in a parent directory without an existing checkout of the same name. This revision contains the migration workflows and declarative Observability management. Its JAR is unchanged from the artifact pinned by the Replatform reference:

umask 077 &&
  git clone https://github.com/stackitcloud/stackit-cmf-Rehost-springboot.git &&
  git -C stackit-cmf-Rehost-springboot checkout --detach b9225eb35c64b9ef4761c208fadb9a2356431793 &&
  test -f stackit-cmf-Rehost-springboot/scripts/run_cutover.sh &&
  cd stackit-cmf-Rehost-springboot &&
  printf '%s\n' "Workspace ready. Continue from this Rehost checkout." || {
    printf '%s\n' "Preparation failed. Resolve the error before continuing." >&2
    false
  }

Run the following steps from that checkout only after preparation succeeds. Preserve an existing checkout, state and evidence rather than replacing them. Keep credentials, plans, state, dumps, inventory and evidence private and outside version control; do not enable shell tracing.

Configure the target inputs

Create the private variable file only when it does not already exist:

umask 077
test -e env.tfvars || cp env.tfvars.example env.tfvars
chmod 600 env.tfvars

Edit the file before planning. Configure the approved existing project or project-creation scope, service-account key path, SSH key pair, available image, availability zone, VM flavor and storage. Restrict SSH and application ingress to the source CIDRs actually observed on the target path. Verify the SSH host key through a trusted channel before migration scripts use strict host checking. Set SSH_KEY and SSH_USER for those scripts when they differ from ~/.ssh/id_rsa and ubuntu; keep them consistent with Terraform’s private_ssh_key_path and ssh_user.

Enable VM-local PostgreSQL, Observability and Server Backup for this walkthrough. For the initial runtime deployment, leave postgresql_restore_after_copy = false and the source dump path empty: provisioning must not import the source before rehearsal and cutover approval. Supply the database password through the approved secret mechanism as TF_VAR_postgresql_app_password and retain it securely for subsequent plans; do not put it in the variable file, shell history or documentation.

Confirm permissions, quota, cost approval and the private Terraform backend before initialization. This workflow assumes a prepared execution host, not a complete lab installation procedure.

Prepare source evidence

Create a custom-format source dump and record its SHA-256 checksum, expected row count, and a workload-specific deterministic fingerprint. The repository includes a reproducible eight-row sample:

./scripts/create_source_dump.sh
./scripts/validate_source_dump.sh

The validation script restores into a separate local PostgreSQL cluster before the dump can enter a migration rehearsal. These scripts generate the bundled sample in temporary local clusters; they do not export a running application or the STACKIT VM. Use a fresh artifact directory and do not overwrite a dump already approved for migration. For a real source, export it under the agreed write-freeze procedure and record equivalent checksum, count and fingerprint evidence.

Provision the target

Configure an existing STACKIT project or project creation, restrict SSH and application ingress to approved source CIDRs, and pass the database password through TF_VAR_postgresql_app_password rather than a variable file. Review a saved plan before apply.

terraform init &&
  ./scripts/check.sh &&
  terraform plan -input=false -var-file=env.tfvars -out=tfplan

Stop if initialization, checks or planning fail. Review resource changes, target project, ingress, cost and the disabled initial restore before explicitly applying that saved plan:

terraform apply tfplan

Terraform runs Ansible after provisioning. A successful apply proves completion of that orchestration, not acceptance of migrated data. Check the runtime before beginning rehearsal:

./scripts/validate_deployment.sh

Rehearse the migration

Run the rehearsal against a temporary database on the target VM:

./scripts/run_migration_rehearsal.sh

The rehearsal checks the source evidence, restores the dump, compares row count and fingerprint, and removes its temporary database without changing the production springmusic database.

Execute cutover

Set the expected source evidence in env.tfvars:

enable_local_postgresql                  = true
postgresql_source_dump_local_path        = "artifacts/source-postgresql.dump"
postgresql_restore_after_copy            = true
postgresql_expected_album_count          = 8
postgresql_expected_album_fingerprint    = "<source-fingerprint>"

Then execute the explicit approval gate:

./scripts/run_cutover.sh --confirm

The script requires a fully available Server Backup no older than 24 hours, creates a saved Terraform plan that replaces only the Ansible orchestration resource, rejects unrelated infrastructure changes, applies the restore, validates data and runtime behavior, and requires a final no-op Terraform plan. Retries of the same source-dump hash preserve the original database rollback point.

Validate and roll back

Validation checks the source row count and fingerprint, table ownership, a transactionally rolled-back write as the application role, application reachability, services, and the protected rollback dump.

./scripts/validate_migration.sh
./scripts/validate_deployment.sh
./scripts/verify_rollback.sh

If an approved rollback trigger is met during the rollback window, preserve the current target database and restore the original pre-cutover dump:

./scripts/rollback_postgresql.sh --confirm

Backup and recovery boundary

With enable_server_backup = true, Terraform enables STACKIT Server Backup and a daily schedule for the VM boot volume. The default retention is 14 days. Cutover requires a fully available backup no older than 24 hours. Backup creation and status were validated against the real target; an in-place Server Backup restore remains a disruptive disaster-recovery operation and must be rehearsed in a separate recovery environment.

The Server Backup complements the PostgreSQL pre-restore dump. It does not replace database-level consistency checks or the application rollback procedure.

Usage

Follow workspace preparation, private target configuration, source evidence and reviewed provisioning in that order. Rehearse before the approved cutover and retain the acceptance evidence afterwards. The repository scripts invoke terraform explicitly; an OpenTofu-only execution host needs a separately reviewed adaptation, not just replacement of commands in this page.

Monitoring and dashboard snapshot

The implementation provisions STACKIT Observability and scrapes node exporter. The Grafana provider manages the included dashboard in the SCF Rehost folder with the existing Thanos datasource, waiting for instance readiness instead of silently skipping dashboard creation.

Verify live VM, Spring Boot and PostgreSQL metrics through grafana_dashboard_url, then require a no-op plan. Seven panels cover the active baseline; the synthetic request panel is included only when the local load generator is enabled. Synthetic requests do not represent all application traffic. The deployment validation also checks exporter metrics and service health after apply and database restore.

Initial Grafana admin credentials remain a temporary authentication dependency. Protect state and saved plans. Notification receivers, alert-routing ownership, application logs and distributed tracing require separate configuration and acceptance before production use.

Application landing zone alignment

This example can be run in two valid setup modes.

With an existing Application Landing Zone: Reuse the already defined project context and service account setup from your landing zone implementation. Use the known project ID as deployment target (for example with create_project = false and project_id = "...") and the service account JSON configured for that landing zone scope.
Standalone without existing landing zone project: Let the example create a dedicated project. In this mode, set create_project = true and provide parent_container_id with an existing folder/container where the service account has sufficient permissions.

For landing-zone design guidance, see Application Landing Zone.

Minimal configuration example

Use this as a minimal starting point in env.tfvars.

create_project              = true
target_project_name         = "cmf-rehost-springboot"
target_project_owner_email  = "owner@example.com"
parent_container_id         = "cmf-xxxxxxxx"
service_account_key_path    = "~/.ssh/cmf-sa.json"
public_ssh_key_path         = "~/.ssh/id_rsa.pub"
private_ssh_key_path        = "~/.ssh/id_rsa"
availability_zone          = "eu01-1"
machine_type               = "g2i.2"
ssh_allowed_cidr           = "203.0.113.10/32"
app_allowed_cidr           = "203.0.113.10/32"
enable_local_postgresql    = true
enable_observability       = true
enable_server_backup       = true

Deployment artifact behavior

Default artifact path: ansible/files/springboot-app.jar
Default variable: jar_local_path points to the same file.
Alternative artifact: Replace the file or override jar_local_path.

When the artifact changes, Terraform detects the checksum difference and re-runs the Ansible deployment step.

Evidence and acceptance

Every rehearsal, cutover, and rollback writes an evidence.env file below artifacts/evidence/<timestamp>-<mode>/. Accept a cutover only when the evidence records the expected checksum, row count, fingerprint, target VM, successful runtime validation, and final Terraform no-op.

./scripts/validate_migration.sh
./scripts/validate_deployment.sh
terraform plan -var-file=env.tfvars -detailed-exitcode

Use the same approved source path, restore flag, expected count and fingerprint as the completed cutover. Exit code 0 means no changes, 2 means changes are proposed, and 1 means an error. A plan alone is not proof of apply. The cutover workflow records status=passed and terraform_noop=true only after applying its saved plan and completing data and runtime validation.

Migration decision gates

Prepare: Approve the target design, access paths, source evidence and recovery responsibilities.
Provision: Review and apply the infrastructure plan, then verify the VM runtime independently.
Rehearse: Restore into an isolated database and verify integrity without changing the application database.
Cut over: Freeze source writes, approve the final dump and allow only the intended orchestration change.
Accept or recover: Require data, runtime and no-op evidence; invoke the agreed rollback before its deadline when acceptance fails.
Handover: Transfer monitoring, backup ownership, evidence and source-retention decisions before optimization.

Reuse as a Replatform baseline

The Replatform reference reuses this repository’s pinned Spring Music JAR and sample-data generator. Its sample walkthrough therefore needs this checkout and validated dump artifacts, but not a newly provisioned Rehost VM. Do not create another VM solely to generate the local sample.

For an actual migration from the Rehost VM to SKE and PostgreSQL Flex, verify that the VM is currently healthy, freeze its application writes, export its real PostgreSQL database and qualify that export. A historical successful Rehost apply does not establish current reachability or make the local sample equivalent to live VM data. Source export, acceptance and source failback need their own approved procedure.

Notes

Keep operational procedures aligned with the runbook and migration governance.
For production usage, adapt security controls, sizing, image selection, and life cycle automation.

BASE

Technical Implementation

STACKIT New

Rehost to STACKIT: Spring Boot with Terraform and Ansible

Rehost Spring Boot and PostgreSQL to a STACKIT VM with Terraform and Ansible: prepare inputs, provision, rehearse, cut over, validate, and hand over operations.

Migration rehost spring-boot postgresql terraform +2

Trail Steps

Rehost Strategy
Target Architecture
Reference Implementation
Prepare the Workspace

+ 16 more steps

GOAL

Accept and Hand Over to Operations

Migration design-and-mobilize design runnable-example rehost spring-boot migration vm

Rehost Spring Boot Service to VM

STACKIT

Open Source In 2 trails

Executable migration runbook for rehosting a Spring Boot JAR and PostgreSQL to one STACKIT VM with rehearsal, evidence-based cutover, validation, and rollback.

Owner

STACKIT

The sovereign European cloud provider behind the framework, delivering IaaS and PaaS from German and Austrian data centers with full digital independence.

Use Case

Migration strategy: Rehost (lift and shift)
Application type: Spring Boot service (JAR), no Kubernetes target
Target platform: VM-based runtime on STACKIT
Data backend: PostgreSQL

Scope and Assumptions

In scope: Terraform provisioning, Ansible configuration, source dump evidence, temporary-database rehearsal, controlled restore, runtime validation, rollback, Observability, and Server Backup schedule.
Out of scope: Code refactoring, database engine change, load balancing, DNS switch, TLS termination, multi-VM availability, Kubernetes, Cloud Foundry, and PostgreSQL Flex.
Assumptions: The source uses a PostgreSQL version compatible with the target restore tools, and approved source CIDRs are known for SSH and application access.

Roles and Ownership

Migration lead: Coordinates timeline, checkpoints, and go/no-go decision.
Application owner: Validates app behavior and business-critical user journeys.
Platform engineer: Prepares the VM, restricted network rules, monitoring, and backup schedule.
DB owner: Executes DB backup, restore, consistency checks, and rollback trigger.
Operations owner: Accepts handover and owns Day-1/Day-2 incident response.

Pre-Migration Checks

Access readiness: SSH, deployment credentials, DB access, secrets access validated.
Baseline captured: Current versions, environment variables, ports, certificates, scheduled jobs documented.
Capacity validated: CPU, RAM, disk IOPS, and storage capacity on target VM confirmed.
Security controls ready: Firewall rules, IAM mapping, TLS cert chain, and logging in place.
Source evidence ready: Dump checksum, expected record count, and deterministic data fingerprint recorded.
Rollback readiness: Pre-restore dump path, expected original record count, authority, and deadline agreed.

Run Plan (Cutover Window)

Phase 1: Prepare target runtime

Create target app user and required filesystem layout.
Install Java runtime and supporting OS packages.
Deploy app artifact to target path.
Configure service unit (systemd) and environment file.
Install self-managed PostgreSQL, create the application role and database, and restrict access to localhost.
Enable node exporter, Observability scraping, and the Server Backup schedule.

Phase 2: Data and config alignment

Create a custom-format PostgreSQL dump without source ownership or privileges.
Record and validate its checksum, expected row count, and deterministic fingerprint.
Run ./scripts/run_migration_rehearsal.sh against a temporary target database.
Confirm that rehearsal removed its temporary database and left the production target database unchanged.
Verify the original target rollback dump in a separate temporary database.

Phase 3: Cutover and release

Freeze source writes and create the final approved dump.
Run ./scripts/run_cutover.sh --confirm with the approved source evidence.
Require the saved Terraform plan to change only the Ansible orchestration resource.
Validate row count, fingerprint, ownership, application-role write behavior, services, and endpoint.
Require a final Terraform no-op plan, record acceptance, and start stabilization watch.

Validation Checklist

Technical health: Spring Boot, PostgreSQL, and node exporter active; local and approved public HTTP checks pass.
Functional checks: The application returns the migrated Spring Music records.
Data checks: Expected row count and fingerprint match; table ownership belongs to the application role.
Security checks: Runtime environment and rollback dump have root-only or database-owner-only permissions.
Operations checks: Observability scrape, Server Backup schedule, evidence files, and escalation ownership verified.

Rollback Criteria and Steps

Rollback triggers

Critical functional failure: Core business flow unavailable after fix window.
Data integrity risk: Mismatch in critical records with no fast remediation.
Operational instability: Repeated restarts or unresolved severe alerts.

Rollback steps

Invoke the approved rollback decision before the deadline and preserve logs and evidence.
Run ./scripts/rollback_postgresql.sh --confirm to stop Spring Boot and preserve the current target database.
Restore the protected pre-cutover dump and validate the expected original row count.
Restart Spring Boot and validate local and approved public reachability.
Resume the agreed source or target operating state and publish the rollback evidence and decision.

Handover to Operations

Artifacts delivered: Final config set, deployment manifest, validation evidence, rollback log.
Ownership transfer: Named on-call owner and escalation route confirmed.
Stabilization period: 24-72 hours with enhanced monitoring and daily status check.
Exit criteria: No critical alerts, stable key metrics, and business owner sign-off.

Evidence Log Template

Swipe sideways to see the whole table

Checkpoint	Owner	Timestamp	Result	Evidence Link
Target VM runtime prepared	Platform engineer	YYYY-MM-DD HH:MM	Pass/Fail	link
Rehearsal completed	DB owner	YYYY-MM-DD HH:MM	Pass/Fail	link
DB restore and integrity check	DB owner	YYYY-MM-DD HH:MM	Pass/Fail	link
Terraform no-op confirmed	Platform engineer	YYYY-MM-DD HH:MM	Pass/Fail	link
Post-cutover business checks	Application owner	YYYY-MM-DD HH:MM	Pass/Fail	link
Handover accepted	Operations owner	YYYY-MM-DD HH:MM	Pass/Fail	link

GOAL

Optimization

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.

In 7 trails

Understanding the Optimize module

Optimize starts when workloads run on STACKIT and real operating data is available. The module converts post-cutover observations into measurable improvements for performance, stability, and cost efficiency.

Optimize is not a one-time task. It is an iterative cycle that can overlap with early stabilization and post-cutover care.

Why optimization happens after migration

Many right-sizing and tuning decisions are only reliable under real load patterns. After cutover, teams can use production telemetry to separate assumptions from actual behavior.

Optimization loop

Collect runtime evidence: utilization, latency, error rates, throughput, and cost drivers.
Identify bottlenecks and waste patterns at workload, platform, and data layers.
Prioritize actions by business impact, risk reduction, and FinOps effect.
Implement tuning changes in controlled increments.
Validate outcomes against SLO, reliability, and cost targets.
Feed lessons learned into future migration waves and operating standards.

Typical optimization focus areas

Rightsizing: Align compute, storage, and network capacity with actual demand profiles.
Performance tuning: Improve latency and throughput through configuration, scaling, and architecture adjustments.
Reliability hardening: Reduce incident frequency through better resilience, observability, and failure handling.
FinOps controls: Improve cost transparency, remove waste, and optimize run-rate efficiency.

From theory to implementation

Optimization decisions should be based on runtime evidence, not assumptions. For practical implementation, combine workload telemetry, alerting, and controlled infrastructure changes.

Managed observability baseline: Use STACKIT Observability to collect metrics, logs, and traces with Grafana, Prometheus, Thanos, Loki, and Tempo.
Detection logic: Define explicit thresholds and observation windows for low utilization and overload conditions.
Run path: Apply rightsizing through IaC changes (for example VM flavor changes) with rollback checkpoints.
Validation loop: Re-measure SLO, error rates, and run-cost after each tuning increment.