Quick Wins — high value, low complexity
Prioritize first. Usually Rehost or Replatform; fast proof points that build momentum and free up data-center capacity.
App Rationalization (6R)
TM Solutions Corp. Inc.
Enterprise Cloud Migration & Architecture Blueprint
Last updated on
TM Solutions Corp. Inc.
Enterprise Cloud Migration & Architecture Blueprint
Structured cross-framework blueprint guiding enterprise migration workflows from initial application analysis down to automated operations on STACKIT.
Strategic Preparation
WIP
Whitepaper
Advisory advisory assessment 6r
STACKIT Partner
TM Solutions Corp. Inc.
Core contributor and technical product owner of the framework, focused on sovereign cloud architecture, automation, and production-ready DevOps pipelines.
Strategy before Migration
Section titled “Strategy before Migration”Not every application should be treated the same. Rationalization is the deliberate step before migration where you decide, per application, whether to move it and how much to change it on the way. Done well, it prevents two classic failures: lifting technical debt straight into the cloud, and over-engineering apps that should simply be switched off.
The 6R model assigns every application in the portfolio exactly one disposition, turning a sprawling estate into a prioritized, fundable roadmap.
The 6 Rs at a glance
Section titled “The 6 Rs at a glance”- Rehost — “Lift & shift” to STACKIT with minimal change.
- Replatform — “Lift, tinker & shift”: swap selected components for managed services.
- Refactor — Re-architect for cloud-native benefits (containers, microservices, autoscaling).
- Retain — Keep where it runs for now (latency, compliance, or weak business case).
- Retire — Decommission redundant or obsolete applications.
- Replace — “Drop & shop”: move to a SaaS alternative.
Choosing the right R
Section titled “Choosing the right R”Each disposition trades migration effort against the cloud value it unlocks. Use this as the working reference when classifying the portfolio:
| Strategy | What you change | Effort | Choose when | Typical STACKIT target |
|---|---|---|---|---|
| Rehost | Infrastructure only (VM-level) | Low | You need to exit a data center fast and optimize later | Compute / IaaS VMs |
| Replatform | Selected components, no rewrite | Low–Medium | A managed service removes ops toil with little code change | Managed PostgreSQL, Object Storage, SKE |
| Refactor | Application architecture | High | Scalability/agility have a strong, funded business case | STACKIT Kubernetes Engine (SKE) + managed data services |
| Retain | Nothing (revisit later) | None now | Latency, data residency, or licensing block a move today | Hybrid connectivity to on-prem |
| Retire | Switch it off | Low | The capability is redundant or unused | — |
| Replace | Vendor / consumption model | Medium | A commodity capability has a strong SaaS fit | SaaS / Marketplace offering |
A simple decision flow
Section titled “A simple decision flow”Run each application through the same questions to land on a defensible disposition:
- Is it still needed? No → Retire.
- Must it stay on-premise (latency, compliance, hardware dependency)? Yes → Retain.
- Does a SaaS product cover this commodity capability well enough? Yes → Replace.
- Does cloud-native architecture have a funded business case (scale, agility, cost)? Yes → Refactor.
- Can a managed service replace a component with little code change? Yes → Replatform.
- Otherwise → Rehost now and revisit modernization later.
Value vs. Complexity
Section titled “Value vs. Complexity”Map every application on two axes — Business Value and Technical Complexity — to sequence the roadmap and protect your modernization budget:
Strategic Bets — high value, high complexity
Fund deliberately as Refactor programs with clear milestones; this is where cloud-native ROI is realized.
Cleanup — low value, low complexity
Resolve cheaply via Retire or Replace to reduce sprawl and licensing cost.
Question Marks — low value, high complexity
Default to Retain and reassess; avoid spending scarce modernization effort here.
Decide the Migration Path
Turn the rationalization results into an explicit R-strategy decision per application. The decision criteria clarify when Relocate, Rehost, Replatform, Repurchase, Refactor, or Retain/Retire is the right route.
What this module delivers
Section titled “What this module delivers”The Design module creates the executable migration design for each application identified in Discovery. It is not a generic architecture exercise. The target is a concrete design package that a migration factory can run with predictable quality.
Target design per application
Defines workload architecture, service choices, integration approach, and constraints in the STACKIT context.
R-strategy-backed decision record
Documents the selected migration strategy and why alternatives were rejected.
Factory-ready migration runbook
Provides a step-by-step procedure for run teams, including rollback and validation checkpoints.
Handover package
Delivers all required inputs to Migration Factory Setup, Landing Zone, and Migration Plan.
Module boundaries and dependencies
Section titled “Module boundaries and dependencies”These modules are connected, but they have different responsibilities:
Design (this module)
Decides target design and migration strategy per application and creates executable runbooks.
Migration Factory Setup
Enables delivery by selecting and preparing the right factory model, partner setup, and tooling stack.
Landing Zone
Provides the platform foundation and governance controls that target designs must comply with.
Migration Plan
Converts completed designs into realistic waves, sequencing, dependencies, and delivery milestones.
R-strategy as core design method
Section titled “R-strategy as core design method”The R-strategy model is the core decision framework in this module. For each application, the selected R-strategy must be justified with architecture, business, risk, and operability evidence.
Decision Criteria by R-Strategy
Section titled “Decision Criteria by R-Strategy”- Relocate: Choose when moving virtualization stacks is faster than redesign and governance constraints still allow conversion to cloud-native operations.
- Rehost: Choose for low change tolerance and strict timelines, where speed is prioritized over immediate modernization.
- Replatform: Choose when moderate changes unlock major benefits through STACKIT managed platform capabilities.
- Repurchase: Choose only for services available in the STACKIT ecosystem, including SaaS options such as ServiceNow, SAP, and partner offerings when they better fit business needs.
- Refactor: Choose for strategic applications where cloud-native redesign creates clear value in resilience, agility, or cost profile.
- Retain: Choose retain when timing or dependencies block migration now.
- Retire: Choose retire when business value no longer justifies operational effort.
Cross-path steps in the diagram
Section titled “Cross-path steps in the diagram”The diagram is not only an orientation aid. It is the shared decision and handover spine across Design, Landing Zones, Migration Factory Setup, and Migration Plan.
1. Discovery input
Section titled “1. Discovery input”Consolidate inventory, dependency map, risk profile, and non-functional constraints before strategy branching starts.
2. Evaluate and prioritize
Section titled “2. Evaluate and prioritize”Prioritize workload candidates by criticality, effort, and wave feasibility to focus design capacity where delivery risk is highest.
3. Determine migration path
Section titled “3. Determine migration path”Select the right R-strategy per workload and route into the dedicated strategy page with explicit rationale and alternatives considered.
4. Validation
Section titled “4. Validation”Run a shared quality gate across architecture, security/compliance, runbook quality, and operating readiness before approving wave execution.
5. Transition
Section titled “5. Transition”Prepare controlled handover into migration execution with release readiness, communication model, and clearly assigned ownership for wave run and escalation paths.
6. Production
Section titled “6. Production”Finalize production handover criteria and Day-1 operating baseline so migrated workloads enter run operations with clear accountability and evidence.
How to build the target design per application
Section titled “How to build the target design per application”- Confirm the application scope and baseline from Discovery (dependencies, usage, criticality, constraints).
- Define business and technical design goals, including availability, security, compliance, and performance targets.
- Evaluate the R-strategy options against objective criteria and record the selected strategy with rationale.
- Map the target to STACKIT products and platform capabilities, including networking, identity, data, and operations patterns.
- Specify migration approach details (cutover model, data movement, integration transition, rollback strategy).
- Create the migration run book for the factory with explicit tasks, quality checks, and acceptance criteria.
- Validate design assumptions with architecture, security, platform, and business owners.
- Hand over the approved design package to Migration Factory Setup and Migration Plan.
Design package required for factory run
Section titled “Design package required for factory run”At minimum, each application package should include:
- Target architecture definition: Workload placement, service mapping, integration model, and non-functional requirements.
- R-strategy decision record: Selected strategy, decision criteria, alternatives considered, and key risks.
- Migration run book: Sequenced run steps, checks before run, rollback path, validation steps, and go-live criteria.
- Dependency and interface impact: Required coordination with upstream/downstream systems and transition windows.
- Compliance and security controls: Mandatory controls and evidence requirements for release readiness.
Cloud design patterns for typical STACKIT applications
Section titled “Cloud design patterns for typical STACKIT applications”Use a dedicated pattern page to define a concrete target architecture before selecting the migration runbook.
Workload use-case lens for migration variants
Section titled “Workload use-case lens for migration variants”In addition to R-strategy, use the workload lens to classify what is migrated and to select feasible implementation variants with explicit boundary conditions.
AI-assisted design assets
Section titled “AI-assisted design assets”AI-assisted design assets support architects in turning application requirements, source-service context, and R-strategy options into reviewable target-design proposals. Use their outputs as input for architecture, security, platform, and business validation before approving a migration path.
Asset title
Framework
Asset type
Migration
Runbook
Migration
Blueprint
Migration
Blueprint
Migration
Guide
Migration
Software
Migration
Software
Migration
Software
Migration
Runbook
Migration
Blueprint
Migration
Blueprint
Migration
Blueprint
Adoption
Service
Advisory
Service
Migration
Software
Migration
Service
Migration
Guide
Runbook assets
Section titled “Runbook assets”Asset title
Framework
Asset type
Migration
Runbook
Migration
Runbook
Migration
Runbook
How design drives the migration plan
Section titled “How design drives the migration plan”Migration planning quality depends on design quality. Wave sequencing, factory throughput, and delivery risk are directly influenced by how precise the target designs and run books are. In practice, incomplete designs lead to unstable waves and avoidable delivery delays.
Infrastructure as Code Foundation
WIP
Guide
TM1: Infrastructure as Code (Terraform Basics)
TM Solutions Corp. Inc.
Architecture iac terraform automation
STACKIT Partner
TM Solutions Corp. Inc.
Core contributor and technical product owner of the framework, focused on sovereign cloud architecture, automation, and production-ready DevOps pipelines.
Why Infrastructure as Code (IaC)?
Section titled “Why Infrastructure as Code (IaC)?”In modern sovereign cloud environments, infrastructure is never provisioned via manual user-interface interactions. Instead, infrastructure is treated with the same rigor as software source code. Utilizing Terraform within a centralized pipeline framework provides four foundational advantages:
- Idempotency: The structural guarantee that executing the same configuration files multiple times always yields the exact same live environment state.
- Version control: The tracking of all infrastructure mutations within Git repositories, establishing auditability via pull requests and peer code reviews.
- Speed and scale: The capability to deploy hundreds of identical environments across regions with the same minimal operational effort as a single instance.
- Compliance enforcement: The validation of security guardrails, cost controls, and organizational policies before any physical resource is instantiated.
The STACKIT Terraform Provider
Section titled “The STACKIT Terraform Provider”The official STACKIT Terraform Provider acts as the primary declarative gateway to the STACKIT API platform. It interprets high-level configuration files (.tf) and translates them into predictable, authenticated API requests against sovereign endpoints.
The complete comprehensive schema documentation for all supported resources and data sources is maintained in the official STACKIT Provider Registry .
Provider Core Capabilities
Section titled “Provider Core Capabilities”- Resource coverage: Full lifecycle management of high-performance compute instances, virtual private clouds (VPC), block storage, and managed platform services like the STACKIT Kubernetes Engine (SKE).
- Centralized authentication: Native support for short-lived service account tokens, eliminating the risk of hardcoded credentials within engineering environments.
- State isolation: Cryptographically secured state management supporting remote state backends to guarantee a single source of truth and prevent concurrent write collisions.
The Automated Pipeline Flow
Section titled “The Automated Pipeline Flow”Within the STACKIT Cloud Framework, execution of Terraform binaries from local developer machines is restricted. All structural modifications must proceed through an isolated, identity-vetted CI/CD pipeline.
- Code: Define your target state configuration (e.g., SKE clusters, object storage buckets) using standard HCL syntax in
.tffiles. - Plan: The pipeline initiates a
terraform planexecution to compute the structural delta, creating a transparent preview of additions, modifications, and deletions. - Review: A peer cloud engineer structurally validates the generated execution plan within the pull request interface.
- Apply: Upon a successful merge to the main branch, the pipeline executes
terraform applyto materialize the defined resources on STACKIT. - State Preservation: The updated state snapshot is securely pushed back to a centralized remote storage backend.
Hands-on: Initializing a Project
Section titled “Hands-on: Initializing a Project”To interact with STACKIT resources, the provider must be explicitly declared and authenticated using service account credentials injected via the pipeline context.
1. Provider Configuration
Section titled “1. Provider Configuration”Create a standard main.tf file and specify the required provider block and version constraints:
terraform { required_providers { stackit = { source = "stackitcloud/stackit" version = "~> 0.0" } }}
provider "stackit" { # Authentication is handled via pipeline-injected environment variables: # STACKIT_SERVICE_ACCOUNT_TOKEN}2. Project Resource Definition
Section titled “2. Project Resource Definition”The stackit_project resource establishes the logical organizational tenant container within the sovereign STACKIT platform topology:
resource "stackit_project" "enterprise_core" { name = "Framework-Core-Infrastructure" container_id = "your-target-parent-folder-or-org-id"}3. Optional Enterprise Security and Network Integration
Section titled “3. Optional Enterprise Security and Network Integration”Depending on your organization’s specific compliance blueprints, projects can be enhanced with advanced framework security patterns at the customer’s discretion:
- SNA architecture patterns: Integration with the Secure Network Architecture can be implemented if specific customer governance models require strict network isolation.
- Supply chain scanning: Pipeline configurations can integrate automatic Helm and Terraform scanning engines (such as Snyk) to identify configuration drift and vulnerabilities.
Official Provider Reference
Section titled “Official Provider Reference”Secure Network Connectivity
Software
pfSense Firewall Connectivity Pattern
STACKIT
Migration design-and-mobilize landing-zone network network-area routing firewall vpn
STACKIT
The sovereign European cloud provider behind the framework, delivering IaaS and PaaS from German and Austrian data centers with full digital independence.
Overview
Section titled “Overview”This asset describes how the STACKIT Quick Deployment pfSense firewall can be used as a reusable connectivity control point in migration landing zones.
It is especially relevant for hub-and-spoke network designs where multiple projects connect through a central security and routing layer.
Primary use context
Section titled “Primary use context”- Network Area governance: A shared enterprise network is centrally governed and projects are attached in a controlled way.
- Routing Tables design: Routing behavior between projects is explicitly steered through approved route patterns.
- Connectivity controls: Security domains, inspection points, and north-south / east-west flow controls are defined before onboarding workloads.
Product reference
Section titled “Product reference”- STACKIT Quick Deployments pfSense firewall: Documentation
Review the STACKIT deployment inputs before using the appliance in a migration landing zone. Protect service-account key files and review the required permissions against your automation policy. Deployment preparation does not replace route design or firewall-rule approval.
From the STACKIT docsSetup pfSense › Preparation
For the pfSense installation please download the GitHub repository containing the deployment scripts for Terraform.
Terraform is going to create these networks vpc_network and wan_network the subnets for the VPC and WAN network get provisioned automatically.
In the file [01-config.tf](http://01-config.tf/) are settings such as the Availability Zone, Network ranges or the VM size (Machine Type) which can all be changed.
Configuration options:
- Project ID (required)
- Availability Zone
- Machine Type
- Network Range & IP Address
To create a service account and grant admin permissions refer to the Service account documentation.
You also need to Create a service account key as described and save the output as JSON into the secrets.json (overwrite all the content in the file).
The versions can be retrieved from the image repository: https://pfsense.object.storage.eu01.onstackit.cloud/index.html
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.
When to use
Section titled “When to use”- Central firewall requirement: You need an explicit inspection and control point between spokes and shared services.
- Migration phase isolation: Different migration waves require controlled inter-project communication.
- Hybrid integration path: Connectivity to external environments must be structured and auditable.
Implementation note
Section titled “Implementation note”Use this asset as a connectivity building block within the broader landing zone network architecture, together with Network Area, Routing Tables, DNS, and VPN standards.
Automated Migration Execution
Runbook
Rehost Spring Boot with Terraform and Ansible
STACKIT
Migration design-and-mobilize design runnable-example rehost automation terraform ansible spring-boot
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
Section titled “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.
STACKIT CMF Rehost Spring Boot repository Open the runnable Terraform and Ansible reference implementation for the Spring Boot and PostgreSQL Rehost path. Open the repositoryMigration context and scope
Section titled “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
systemdwithout 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
Section titled “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
Section titled “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
Section titled “Validated target architecture”The following diagram shows the implemented and tested target, not a future high-availability variant.
Prepare the walkthrough workspace
Section titled “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
Section titled “Configure the target inputs”Create the private variable file only when it does not already exist:
umask 077test -e env.tfvars || cp env.tfvars.example env.tfvarschmod 600 env.tfvarsEdit 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
Section titled “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.shThe 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
Section titled “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=tfplanStop 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 tfplanTerraform 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.shRehearse the migration
Section titled “Rehearse the migration”Run the rehearsal against a temporary database on the target VM:
./scripts/run_migration_rehearsal.shThe 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
Section titled “Execute cutover”Set the expected source evidence in env.tfvars:
enable_local_postgresql = truepostgresql_source_dump_local_path = "artifacts/source-postgresql.dump"postgresql_restore_after_copy = truepostgresql_expected_album_count = 8postgresql_expected_album_fingerprint = "<source-fingerprint>"Then execute the explicit approval gate:
./scripts/run_cutover.sh --confirmThe 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
Section titled “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.shIf 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 --confirmBackup and recovery boundary
Section titled “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.
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
Section titled “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
Section titled “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 = falseandproject_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 = trueand provideparent_container_idwith an existing folder/container where the service account has sufficient permissions.
For landing-zone design guidance, see Application Landing Zone.
Minimal configuration example
Section titled “Minimal configuration example”Use this as a minimal starting point in env.tfvars.
create_project = truetarget_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 = trueenable_observability = trueenable_server_backup = trueDeployment artifact behavior
Section titled “Deployment artifact behavior”- Default artifact path:
ansible/files/springboot-app.jar - Default variable:
jar_local_pathpoints 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
Section titled “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.shterraform plan -var-file=env.tfvars -detailed-exitcodeUse 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
Section titled “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
Section titled “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.
- Keep operational procedures aligned with the runbook and migration governance.
- For production usage, adapt security controls, sizing, image selection, and life cycle automation.
Wave Delivery at Factory Scale
Scale the automated migration pattern from a single application to governed waves: the end-to-end factory flow connects intake, run paths per migration strategy, and quality gates per wave.
Understanding the Migrate module
Section titled “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
Section titled “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
Section titled “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
Section titled “Run path by migration path”Relocate flow
Section titled “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
Section titled “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
Section titled “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
Section titled “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
Section titled “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.
Post-Migration Optimization
Runbook
Optimize Rehost Spring Boot with Observability and VM Rightsizing
STACKIT
Migration migrate optimize rehost observability rightsizing spring-boot
STACKIT
The sovereign European cloud provider behind the framework, delivering IaaS and PaaS from German and Austrian data centers with full digital independence.
Continue the reference implementation
Section titled “Continue the reference implementation”This asset continues the same Spring Boot and PostgreSQL reference implementation used for provisioning, migration, cutover, and stabilization. It does not introduce another example or repository. The existing Terraform variables, Ansible configuration, Observability instance, and validation workflows remain the technical baseline for Optimize.
The Optimize extension answers one practical question: how to detect overprovisioning or underprovisioning and then change VM or storage capacity through a controlled IaC workflow.
STACKIT CMF Rehost Spring Boot repository Continue with the same Terraform and Ansible reference implementation used by the preceding Rehost migration steps. Open the repository Rehost implementation assetObservability setup used for optimization
Section titled “Observability setup used for optimization”Use the managed STACKIT Observability stack as evidence source.
- Prometheus: metric collection
- Thanos: long-term metric retention
- Grafana Loki: log analysis
- Grafana Tempo: distributed traces
- Grafana: dashboards and visualization
Architecture reference:
Observability decision dashboard
Section titled “Observability decision dashboard”Use the dashboard to review infrastructure saturation, application health, request behavior, and alert history together before changing VM capacity.
Signals and thresholds for rightsizing
Section titled “Signals and thresholds for rightsizing”Define technical thresholds before changing capacity.
- Candidate for downsizing: CPU p95 under 30% and memory p95 under 50% for at least 14 days.
- Scale-up candidate: CPU p95 over 75% or memory p95 over 80% during business load windows for at least 3 consecutive days.
- Stability guardrail: No unresolved critical alerts and no regression in error-rate SLOs.
Keep thresholds workload-specific and validate with business traffic patterns.
Database visibility for optimize decisions
Section titled “Database visibility for optimize decisions”For stateful Rehost workloads, include database signals in the same dashboard review cycle.
- Connection pressure: active connection trend and burst behavior.
- Database growth: database size progression over time.
- Transaction behavior: commit/rollback trend for stability checks.
Use these metrics together with VM signals to avoid CPU-only or memory-only optimization decisions.
PostgreSQL Flex optimization path for migrated data tiers
Section titled “PostgreSQL Flex optimization path for migrated data tiers”If the Rehost workload later moves its database tier to PostgreSQL Flex, include database-tier rightsizing and tuning in the same optimize cycle.
- Plan the target DB profile: use Plan your PostgreSQL Flex instance to align expected data growth and concurrency.
- Tune flavor and storage class: use Flavors and performance classes of PostgreSQL Flex to adjust CPU, RAM, and storage performance.
- Use the integrated dashboard first: review Dashboard metrics in PostgreSQL Flex for fast checks.
- Use scraped observability metrics for deep analysis: follow Observability metrics in PostgreSQL Flex for alert and threshold design.
Use the offered Flex combinations and storage performance limits to assess a database-tier change. Keep the VM thresholds above workload-specific; the product catalog does not supply acceptance criteria or prove that an infrastructure change is reversible.
From the STACKIT docsFlavors and performance classes › Flavors
| Description | ID | CPU | RAM | max_connections | shared_buffers | work_mem | maintenance_work_mem | effective_cache_size |
|---|---|---|---|---|---|---|---|---|
| Small, Compute optimized | 2.4 | 2 | 4 GB | 95 | 950 MB | 14 MB | 380 MB | 2660 MB |
| Small, Memory optimized | 2.16 | 2 | 16 GB | 385 | 3950 MB | 14 MB | 1580 MB | 11060 MB |
| Medium, Compute optimized | 4.8 | 4 | 8 GB | 195 | 1950 MB | 14 MB | 780 MB | 5460 MB |
| Medium, Memory optimized | 4.32 | 4 | 32 GB | 785 | 7950 MB | 14 MB | 3180 MB | 22260 MB |
| Large, Processor optimized | 8.16 | 8 | 16 GB | 385 | 3950 MB | 14 MB | 1580 MB | 11060 MB |
| X-Large, Compute optimized | 16.32 | 16 | 32 GB | 785 | 7950 MB | 14 MB | 3180 MB | 22260 MB |
| X-Large, Memory optimized | 16.128 | 16 | 128 GB | 3170 | 31950 MB | 14 MB | 12780 MB | 89460 MB |
Notes
- CPU and RAM is always per node.
- The system uses up to 15 connections for internal essential processes such as backup, monitoring, etc. These connections will be counted towards the
max_connectionslimit.
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.
From the STACKIT docsFlavors and performance classes › Performance Classes
| Description | ID | Max. IOPS | Max. throughput (MB/s) |
|---|---|---|---|
| Performance class 2 | premium-perf2-stackit | 1000 | 100 |
| Performance class 4 | premium-perf4-stackit | 2000 | 150 |
| Performance class 6 | premium-perf6-stackit | 5000 | 200 |
| Performance class 8 | premium-perf8-stackit | 10000 | 250 |
| Performance class 10 | premium-perf10-stackit | 15000 | 300 |
| Performance class 12 | premium-perf12-stackit | 20000 | 350 |
Currently, we offer three types of instances. For each type there is a different set of flavors available.
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.
Rightsizing workflow
Section titled “Rightsizing workflow”- Collect baseline metrics and traces for a representative period.
- Confirm optimization candidate with dashboards and alert history.
- Plan capacity change and rollback checkpoint.
- Apply VM size change with Terraform/OpenTofu.
- Re-validate latency, error rates, throughput, and cost.
- Keep or revert based on objective acceptance criteria.
Technical implementation example
Section titled “Technical implementation example”Example A: Downsize after sustained low utilization
Section titled “Example A: Downsize after sustained low utilization”Update VM sizing in env.tfvars:
machine_type = "g3i.2"Apply and inspect plan output:
terraform plan -var-file=env.tfvarsterraform apply -var-file=env.tfvarsThen validate:
- Service health (
systemctl status, synthetic checks) - p95 latency and error-rate trend
- Cost delta in reporting window
Example B: Scale up under sustained overload
Section titled “Example B: Scale up under sustained overload”Update VM sizing in env.tfvars:
machine_type = "g3i.4"Apply and validate with the same post-change checks.
Rollback pattern
Section titled “Rollback pattern”If SLOs regress after rightsizing, roll back by restoring the previous machine_type and re-applying IaC.
Treat rollback as a standard runbook step, not as an emergency-only path.
- Depending on platform constraints and machine type, resize can require restart or replacement. Confirm behavior in
terraform planbefore apply.
Storage as optimization dimension
Section titled “Storage as optimization dimension”In Rehost scenarios, CPU and memory are only one side of rightsizing. Storage performance can also become the limiting factor.
- When to investigate storage: elevated I/O wait, unstable latency under write-heavy load, or throughput saturation despite available CPU.
- What to select: a storage service plan and performance class that matches the observed IOPS and throughput profile.
- Guidance: Block Storage service plans
Select the performance class before provisioning
Section titled “Select the performance class before provisioning”A Block Storage performance class defines the maximum IOPS and throughput available to the complete volume. Application, database, operating-system, and backup access share this performance envelope. Select the class from measured peak demand, latency requirements, backup activity, and explicit growth headroom before creating the volume.
From the STACKIT docsService plans › Currently available Service Plans (performance classes)
The following table lists currently available performance classes for the EU01 region:
| Performance class | Name | Max. IOPS | Max. Throughput (MB/s) |
|---|---|---|---|
| Performance class 0 | storage_premium_perf0 | 120 | 25 |
| Performance class 1 | storage_premium_perf1 | 500 | 50 |
| Performance class 2 | storage_premium_perf2 | 1000 | 100 |
| Performance class 4 | storage_premium_perf4 | 2000 | 150 |
| Performance class 6 | storage_premium_perf6 | 5000 | 200 |
| Performance class 8 | storage_premium_perf8 | 10000 | 250 |
| Performance class 10 | storage_premium_perf10 | 15000 | 300 |
| Performance class 12 | storage_premium_perf12 | 20000 | 350 |
| Performance class 13 | storage_premium_perf13 | 20000 | 700 |
| Performance class 14 | storage_premium_perf14 | 25000 | 400 |
| Performance class 15 | storage_premium_perf15 | 25000 | 800 |
| Performance class 16 | storage_premium_perf16 | 30000 | 450 |
| Performance class 17 | storage_premium_perf17 | 30000 | 900 |
| Performance class 18 | storage_premium_perf18 | 35000 | 500 |
| Performance class 19 | storage_premium_perf19 | 35000 | 1000 |
| Performance class 20 | storage_premium_perf20 | 40000 | 550 |
| Performance class 21 | storage_premium_perf21 | 40000 | 1100 |
| Performance class 29 | storage_premium_perf29 | 60000 | 1500 |
IOPS - Input/Output Operations per second
Throughput - Throughput in Megabytes per second
Thus, the classes used can be distinguished in detail based on the naming. Example: “Block Storage Premium - Performance Class 2” corresponds to SSD hard disks with max. 1000 IOPS and max. 100 Mbyte/s throughput.
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.
For the Rehost baseline, the operating system, Spring Boot application, and PostgreSQL data share the boot volume. Changing its performance class therefore requires a controlled replacement target:
- Select the new class from observed IOPS, throughput, latency, and I/O-wait data.
- Verify backup and database-level rollback readiness.
- Provision the replacement VM and boot volume through IaC with the selected class.
- Reapply the Ansible configuration and restore or migrate the workload data.
- Validate application behavior, data integrity, storage latency, backup coverage, and cost before switching.
Use a separate data volume when storage capacity or performance must evolve independently from the VM lifecycle. To change its performance class, create a new volume in the required availability model with sufficient capacity, stop writes, migrate and verify the data, switch the attachment or mount, and retain the source volume until acceptance and rollback gates have passed.
Migrate data from Block StorageTreat storage checks as part of the same Optimize loop and validate latency, error behavior, recovery, and cost impact after any change.
Trail historyActive 4 of the last 12 weeksTMUpdatedNo updates · 1 bar = 1 week i
Maintainers
- TMTobias M.Head of STACKIT Cloud Framework · STACKITOwnerTobias M.Head of STACKIT Cloud Framework · STACKITOwnerActive 12 of the last 12 weeks · 168 updateswww.linkedin.com/in/tobias-müller-011304172
TMTobias M.Head of STACKIT Cloud Framework · STACKITOwnerActive 12 of the last 12 weeks · 168 updatesSTACKITwww.linkedin.com/in/tobias-müller-011304172Contributed in TM Solutions Corp. Inc.
Tobias M.Head of STACKIT Cloud Framework · STACKITOwnerActive 12 of the last 12 weeks · 168 updatesSTACKITwww.linkedin.com/in/tobias-müller-011304172Contributed in TM Solutions Corp. Inc.Tobias M.
Tobias M.Head of STACKIT Cloud Framework · STACKITOwnerActive 12 of the last 12 weeks · 168 updatesSTACKITwww.linkedin.com/in/tobias-müller-011304172
· Aug 31, 2026Tobias M.
Tobias M.Head of STACKIT Cloud Framework · STACKITOwnerActive 12 of the last 12 weeks · 168 updatesSTACKITwww.linkedin.com/in/tobias-müller-011304172
· Aug 26, 2026Tobias M.
Tobias M.Head of STACKIT Cloud Framework · STACKITOwnerActive 12 of the last 12 weeks · 168 updatesSTACKITwww.linkedin.com/in/tobias-müller-011304172
· Aug 10, 2026
Show full history (5 more)
Tobias M.
Tobias M.Head of STACKIT Cloud Framework · STACKITOwnerActive 12 of the last 12 weeks · 168 updatesSTACKITwww.linkedin.com/in/tobias-müller-011304172
· Jul 29, 2026Tobias M.
Tobias M.Head of STACKIT Cloud Framework · STACKITOwnerActive 12 of the last 12 weeks · 168 updatesSTACKITwww.linkedin.com/in/tobias-müller-011304172
· Jul 16, 2026Tobias M.
Tobias M.Head of STACKIT Cloud Framework · STACKITOwnerActive 12 of the last 12 weeks · 168 updatesSTACKITwww.linkedin.com/in/tobias-müller-011304172
· Jul 15, 2026Tobias M.
Tobias M.Head of STACKIT Cloud Framework · STACKITOwnerActive 12 of the last 12 weeks · 168 updatesSTACKITwww.linkedin.com/in/tobias-müller-011304172
· Jul 13, 2026