---
title: "Replatform to STACKIT: Spring Boot and PostgreSQL Overview"
description: "Plan the Spring Boot platform change to SKE and PostgreSQL Flex: discovery, architecture, landing-zone readiness, migration gates, handoff, and optimization."
scfTrail:
  tags: [ "replatform", "spring-boot", "postgresql", "ske", "terraform", "cutover", "gateway-api", "observability" ]
  maintainers:
    - user: "lukas.weberruss"
      role: true
      website: true
  steps:
    - style: "compass"
      id: "replatform-journey"
      title: "Spring Boot Replatform Journey"
      trailContext: "Place the platform change within the complete Migration Framework: assess the workload, design SKE and PostgreSQL Flex, prepare the landing zone, migrate with explicit data gates, and stabilize before optimization. The application JAR stays the same; the runtime and database operating models change."
      imageSrc: "migration/files/migration-framework-overview.svg"
      imageAlt: "STACKIT Migration Framework from Assess through Design and Mobilize and Migrate to Run"

    - style: "compass"
      id: "rapid-discovery"
      title: "Rapid Discovery"
      trailContext: "Establish an initial workload baseline for the Spring Boot VM, PostgreSQL data, dependencies, and capacity. Qualify migration intent and identify the unknowns that detailed Discovery must resolve before a platform decision."
      pageId: "migration/assess/rapid-discovery/overview/#overview"
      imageSrc: "migration/assess/rapid-discovery/files/rapid-discovery-process.svg"
      imageAlt: "Rapid Discovery process from source collection to an initial migration baseline"

    - style: "stairs"
      id: "discovery-evidence"
      title: "Discovery"
      trailContext: "Confirm Java and PostgreSQL compatibility, state handling, scheduled writers, schema dependencies, data volume and change rate, downtime tolerance, recovery objectives, and representative demand. Validate those inputs with the application and database owners before selecting the target."
      pageId: "migration/design-and-mobilize/discovery/overview/#understanding-discovery"
      imageSrc: "migration/design-and-mobilize/discovery/files/discovery-analysis-flow.svg"
      imageAlt: "Discovery analysis combining technical measurements and application-owner evidence"

    - style: "chairlift"
      id: "confirm-replatform"
      title: "Replatform Strategy and Tools"
      trailContext: "Confirm the two deliberate substitutions: a VM service becomes a Kubernetes Deployment, and VM-local PostgreSQL becomes PostgreSQL Flex. Preserve the Spring Music JAR and business behavior; this is Replatform rather than VM Rehost or application Refactor."
      pageId: "migration/design-and-mobilize/design/replatform/#understanding-replatform"
      imageSrc: "migration/files/r-strategy-method.svg"
      imageAlt: "R-strategy method placing Replatform between Rehost and Refactor"

    - style: "stairs"
      id: "automation-approach"
      title: "Automate Platform and Workload"
      trailContext: "Use versioned Terraform for infrastructure and Kubernetes resources, Helm for Envoy Gateway and routes, and a separate approved script for data migration. Keep provisioning and data replacement independently reviewable; this target does not require Ansible host configuration."
      pageId: "migration/design-and-mobilize/landing-zones/automation-iac/#core-automation-building-blocks"

    - style: "chart"
      id: "target-architecture"
      title: "Target Runtime Architecture"
      trailContext: "Review the implemented one-worker reference: the same JAR on SKE, a ClusterIP Service behind Envoy Gateway, managed DNS, PostgreSQL Flex, and Observability. Distinguish this tested topology from optional high-availability and integration-service extensions."
      assetId: "migration/assetcontainer/stackit/architecture-spring-boot-kubernetes-paas-data-object-storage#architecture-diagram"

    - style: "gondola"
      id: "design-data-path"
      title: "Database Migration"
      trailContext: "Design the database move independently of runtime provisioning. Define source freeze, a consistent dump and manifest, isolated rehearsal, a proven target backup, transactional restore, and the rollback deadline. Traffic switching and source failback remain explicit operator decisions."
      pageId: "migration/design-and-mobilize/design/replatform/#data-platform-guidance-in-replatform"
      imageSrc: "migration/files/migrate-wave-flow.svg"
      imageAlt: "Migration-wave control points from readiness through cutover, validation, and handover"

    - style: "hut"
      id: "landing-zone"
      title: "Landing Zone"
      trailContext: "Establish governance, identity, security, network, cost controls, and automation before the target depends on them. Confirm project permissions, operator access, DNS delegation, SKE capacity, database access boundaries, and protected Terraform state."
      pageId: "migration/design-and-mobilize/landing-zones/overview/#understanding-landing-zones"
      imageSrc: "migration/design-and-mobilize/landing-zones/files/landing-zone-core-components-map-en.svg"
      imageAlt: "Six core components of a governed STACKIT landing zone"

    - role: "sub"
      id: "landing-zone-accelerator"
      title: "Accelerate the Foundation as Code"
      trailContext: "Use the Landing Zone Accelerator where appropriate for the governed project and platform foundation. Keep responsibility separate: the application team owns the SKE workload, data migration, Gateway, telemetry, and workload recovery."
      imageSrc: "contributors/stackit/files/migration/landing-zone-accelerator-architecture.svg"
      imageAlt: "Landing Zone Accelerator separating platform foundation and application workload responsibilities"

    - style: "rocket"
      id: "migration-flow"
      title: "Migration Framework"
      trailContext: "Enter the migration wave with an approved target design, a ready Application Landing Zone, a tested runbook, and assigned decision owners. Follow readiness, migration, cutover, validation, stabilization, and handover as one controlled flow."
      pageId: "migration/migrate/migrate/overview/#end-to-end-factory-flow"

    - style: "shield"
      id: "migration-checkpoints"
      title: "Migration Decisions and Gates"
      trailContext: "Explain the decisions that protect the platform change, from source freeze and rehearsal to acceptance, recovery, and handover. Keep command execution in the technical walkthrough."
      assetId: "migration/assetcontainer/stackit/runbook-replatform-spring-boot#migration-decision-gates"
    - style: hut
      id: technical-implementation
      title: Technical Implementation
      center:
        trailId: migration/trails/stackit/spring-boot-postgresql-replatform-technical-walkthrough
    - style: summit
      id: operating-handoff
      title: Accept and Hand Over to Operations
      trailContext: Release the migrated system only after technical and business acceptance. Hand over ownership, monitoring, recovery and source retention; stabilize before optimization changes.
      assetId: migration/assetcontainer/stackit/runbook-replatform-spring-boot#handover-to-operations

    - style: "summit"
      id: "optimize-framework"
      title: "Stabilize and Optimize"
      trailContext: "Return to the Migration Framework's Optimize loop: collect representative operating evidence, identify the limiting layer, implement one controlled change, and validate reliability, performance, and cost before keeping it."
      pageId: "migration/migrate/optimize/overview/#understanding-the-optimize-module"

    - role: "sub"
      id: "optimize-target"
      title: "Select an Optimization Candidate"
      trailContext: "Use the eight-panel dashboard as a starting point, verify actual scrape health, and correlate cluster, application, and database pressure with business evidence. Do not infer zero load from fallback values or production SLOs from mean request duration."
      assetId: "migration/assetcontainer/stackit/optimize-replatformed-spring-boot-kubernetes-rightsizing#observability-decision-dashboard"

  presentations:
    - id: "standard-replatform-path"
      label: "Replatform overview"
      description: "Present the rationale, target architecture, migration decisions, verified results, and optimization outlook without command execution."
      default: true
      launch: true
      preset: "standard"
      fullscreen: true
      steps:
        - { id: "replatform-journey", role: "hidden" }
        - "rapid-discovery"
        - { id: "discovery-evidence", role: "hidden" }
        - "confirm-replatform"
        - { id: "automation-approach", role: "hidden" }
        - "target-architecture"
        - { id: "design-data-path", role: "hidden" }
        - "landing-zone"
        - { id: "landing-zone-accelerator", role: "hidden" }
        - "migration-flow"
        - { id: "migration-checkpoints", role: "hidden" }
        - id: technical-implementation
          role: hidden
        - operating-handoff
        - "optimize-framework"
        - { id: "optimize-target", role: "hidden" }
source_url: "https://framework.stackit.cloud/migration/trails/stackit/spring-boot-postgresql-replatform-to-stackit/"
source_file: "docs/migration/trails/stackit/spring-boot-postgresql-replatform-to-stackit.mdx"
---

## Steps

### 1. Spring Boot Replatform Journey

Stage: `compass`

Place the platform change within the complete Migration Framework: assess the workload, design SKE and PostgreSQL Flex, prepare the landing zone, migrate with explicit data gates, and stabilize before optimization. The application JAR stays the same; the runtime and database operating models change.

### 2. Rapid Discovery

Stage: `compass`

Establish an initial workload baseline for the Spring Boot VM, PostgreSQL data, dependencies, and capacity. Qualify migration intent and identify the unknowns that detailed Discovery must resolve before a platform decision.

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

### 3. Discovery

Stage: `stairs`

Confirm Java and PostgreSQL compatibility, state handling, scheduled writers, schema dependencies, data volume and change rate, downtime tolerance, recovery objectives, and representative demand. Validate those inputs with the application and database owners before selecting the target.

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

### 4. Replatform Strategy and Tools

Stage: `chairlift`

Confirm the two deliberate substitutions: a VM service becomes a Kubernetes Deployment, and VM-local PostgreSQL becomes PostgreSQL Flex. Preserve the Spring Music JAR and business behavior; this is Replatform rather than VM Rehost or application Refactor.

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

### 5. Automate Platform and Workload

Stage: `stairs`

Use versioned Terraform for infrastructure and Kubernetes resources, Helm for Envoy Gateway and routes, and a separate approved script for data migration. Keep provisioning and data replacement independently reviewable; this target does not require Ansible host configuration.

Page: [/migration/design-and-mobilize/landing-zones/automation-iac/#core-automation-building-blocks](/migration/design-and-mobilize/landing-zones/automation-iac/#core-automation-building-blocks) — source: [/raw/migration/design-and-mobilize/landing-zones/automation-iac.md](/raw/migration/design-and-mobilize/landing-zones/automation-iac.md), section `#core-automation-building-blocks`

### 6. Target Runtime Architecture

Stage: `chart`

Review the implemented one-worker reference: the same JAR on SKE, a ClusterIP Service behind Envoy Gateway, managed DNS, PostgreSQL Flex, and Observability. Distinguish this tested topology from optional high-availability and integration-service extensions.

Asset: [/migration/assetcontainer/stackit/architecture-spring-boot-kubernetes-paas-data-object-storage/#architecture-diagram](/migration/assetcontainer/stackit/architecture-spring-boot-kubernetes-paas-data-object-storage/#architecture-diagram) — source: [/raw/migration/assetcontainer/stackit/architecture-spring-boot-kubernetes-paas-data-object-storage.md](/raw/migration/assetcontainer/stackit/architecture-spring-boot-kubernetes-paas-data-object-storage.md), section `#architecture-diagram`

### 7. Database Migration

Stage: `gondola`

Design the database move independently of runtime provisioning. Define source freeze, a consistent dump and manifest, isolated rehearsal, a proven target backup, transactional restore, and the rollback deadline. Traffic switching and source failback remain explicit operator decisions.

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

### 8. Landing Zone

Stage: `hut`

Establish governance, identity, security, network, cost controls, and automation before the target depends on them. Confirm project permissions, operator access, DNS delegation, SKE capacity, database access boundaries, and protected Terraform state.

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

### 9. Accelerate the Foundation as Code

Use the Landing Zone Accelerator where appropriate for the governed project and platform foundation. Keep responsibility separate: the application team owns the SKE workload, data migration, Gateway, telemetry, and workload recovery.

### 10. Migration Framework

Stage: `rocket`

Enter the migration wave with an approved target design, a ready Application Landing Zone, a tested runbook, and assigned decision owners. Follow readiness, migration, cutover, validation, stabilization, and handover as one controlled flow.

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

### 11. Migration Decisions and Gates

Stage: `shield`

Explain the decisions that protect the platform change, from source freeze and rehearsal to acceptance, recovery, and handover. Keep command execution in the technical walkthrough.

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

### 12. Technical Implementation

Stage: `hut`

### 13. Accept and Hand Over to Operations

Stage: `summit`

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

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

### 14. Stabilize and Optimize

Stage: `summit`

Return to the Migration Framework's Optimize loop: collect representative operating evidence, identify the limiting layer, implement one controlled change, and validate reliability, performance, and cost before keeping it.

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

### 15. Select an Optimization Candidate

Use the eight-panel dashboard as a starting point, verify actual scrape health, and correlate cluster, application, and database pressure with business evidence. Do not infer zero load from fallback values or production SLOs from mean request duration.

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