Platform component selection
Identify which layers should change (for example runtime, database operations, integration controls).
Optimize Replatform Spring Boot on Kubernetes with Rightsizing and Pod Scaling
STACKIT
Understanding Replatform
Section titled “Understanding Replatform”Replatform keeps core application behavior but changes selected platform components to gain operational or economic benefits. It sits between Rehost and Refactor in change intensity.
Comparing Replatform, Rehost, and Refactor
Section titled “Comparing Replatform, Rehost, and Refactor”- Rehost: Move workload location with minimal platform or code change. Example: Spring Boot stays on VM, only cloud target changes.
- Replatform: Keep application behavior, but change selected platform layers. Example: Spring Boot runtime moves from VM to Kubernetes while core business logic remains unchanged.
- Refactor: Change code structure or architecture significantly to unlock additional capabilities. Example: split monolith into services, redesign persistence model, and rework integration contracts.
What counts as a platform change
Section titled “What counts as a platform change”- Runtime platform swap: VM-based application hosting to Kubernetes.
- Data platform swap: Self-managed database on VM to managed PaaS database service.
- Ops capability swap: Host-centric monitoring and deployment model to managed platform-native operations.
- Connectivity/control swap: Ingress, DNS, and service exposure model adapted to managed platform patterns.
These are Replatform changes as long as the core product behavior and major code paths remain mostly stable.
When Replatform is a good fit
Section titled “When Replatform is a good fit”- Operational bottlenecks can be reduced through managed platform capabilities.
- Moderate change tolerance exists, but full redesign is out of scope.
- Scalability and reliability goals require infrastructure-level improvements.
- Cost optimization target can be reached with selective platform substitution.
Design considerations in STACKIT context
Section titled “Design considerations in STACKIT context”Compatibility boundaries
Validate technical constraints and fallback options before introducing platform changes.
Risk-managed sequencing
Stage changes to avoid coupling too many unknowns in one cutover window.
Evidence and acceptance
Define measurable improvements for performance, resilience, and operational load.
Recommended design flow
Section titled “Recommended design flow”- Define Landing Zone for the workload and its control boundaries.
- Map Target Platform components for runtime, data, and integration.
- Adapt Platform Stack prerequisites with sequencing and rollback checkpoints.
- Use migration tools to execute the transition through the shared migration path.
- Validate non-functional requirements and approve handover.
Data platform guidance in Replatform
Section titled “Data platform guidance in Replatform”For stateful workloads, define source and target data platform responsibilities before runtime cutover.
- Source data ownership: Clarify who owns dump/export run and consistency checks.
- Target data ownership: Clarify who owns managed database provisioning, access controls, and backup baseline.
- Migration sequencing: Separate schema/data move from runtime switch and validate each gate independently.
- Temporary access controls: Plan temporary data migration access and explicit rollback/removal checkpoints.
Required outputs
Section titled “Required outputs”Shared outputs across all migration paths
Section titled “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.
Replatform-specific outputs
Section titled “Replatform-specific outputs”- Replatform decision matrix with selected substitutions.
- Compatibility and constraint assessment.
- Sequenced migration and rollback design.
- Target-state operations model.
- Benefit metrics and acceptance criteria.
Concrete example asset
Section titled “Concrete example asset”For a runnable example of a platform swap from VM to Kubernetes with Spring Boot, use:
Asset title
Framework
Asset type
Migration
Runbook
Migration
Runbook
Migration
Blueprint
Migration
Runbook
Migration
Runbook
Migration
Runbook
Migration
Runbook
Migration
Runbook
Migration
Runbook
Migration
Runbook
Migration
Runbook
Migration
Blueprint
Migration
Blueprint
Migration
Service
Migration
Guide
Use the asset for the runnable VM-to-Kubernetes and VM-to-managed-database implementation details.
Diagram step reference
Section titled “Diagram step reference”Define Landing Zone
Define landing zone controls and guardrails as the start condition for the Replatform path. Confirm platform prerequisites for runtime, data, and integration layers so substitutions can be introduced without breaking governance or operability.
Map Target Platform
Define the target platform mapping for the Replatform path across runtime, data, and integration services. Make dependencies explicit, including identity, networking, and data responsibilities, so each change can be validated before cutover.
Adapt Platform Stack
Specify required platform prerequisite changes and sequencing for controlled transition. Define rollback guardrails, readiness checks, and run ownership so wave delivery stays predictable when multiple platform layers change together.