---
title: Replatform
description: Replatform introduces targeted platform changes during migration to improve operations, scalability, and cost without full application redesign.
sidebar:
  label: Replatform
  order: 3
source_url: "https://framework.stackit.cloud/migration/design-and-mobilize/design/replatform/"
source_file: "docs/migration/design-and-mobilize/design/replatform.mdx"
---

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

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

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

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

<CardGrid>
  <Card title="Platform component selection">
    Identify which layers should change (for example runtime, database operations, integration
    controls).
  </Card>
  <Card title="Compatibility boundaries">
    Validate technical constraints and fallback options before introducing platform changes.
  </Card>
  <Card title="Risk-managed sequencing">
    Stage changes to avoid coupling too many unknowns in one cutover window.
  </Card>
  <Card title="Evidence and acceptance">
    Define measurable improvements for performance, resilience, and operational load.
  </Card>
</CardGrid>

## Recommended design flow

<Steps>

1. Define Landing Zone for the workload and its control boundaries.
2. Map Target Platform components for runtime, data, and integration.
3. Adapt Platform Stack prerequisites with sequencing and rollback checkpoints.
4. Use migration tools to execute the transition through the shared migration path.
5. Validate non-functional requirements and approve handover.

</Steps>

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

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

- 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

For a runnable example of a platform swap from VM to Kubernetes with Spring Boot, use:

<ScfAssetLoader
  showFilter={false}
  showSearch={false}
  frameworkSlug="migration"
  filterByTag="replatform"
/>

Use the asset for the runnable VM-to-Kubernetes and VM-to-managed-database implementation details.

## Diagram step reference

<h3 id="replatform-determine-platform">Define Landing Zone</h3>

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.

- <LinkChip href="/migration/design-and-mobilize/landing-zones/overview/">Landing Zones Overview</LinkChip>
- <LinkChip href="/migration/design-and-mobilize/landing-zones/application-landing-zone/">Application Landing Zone</LinkChip>
- <LinkChip href="/migration/design-and-mobilize/landing-zones/security-and-compliance/">Landing Zone Security and Compliance</LinkChip>

<h3 id="replatform-map-target-platform">Map Target Platform</h3>

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.

- <LinkChip href="/migration/design-and-mobilize/design/cloud-design-patterns/">Cloud Design Patterns</LinkChip>
- <LinkChip href="/migration/design-and-mobilize/design/runbook/">Runbook Blueprint</LinkChip>

<h3 id="replatform-adapt-platform-stack">Adapt Platform Stack</h3>

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.

- <LinkChip href="/migration/design-and-mobilize/design/runbook/">Runbook Blueprint</LinkChip>
- <LinkChip href="/migration/design-and-mobilize/migration-plan/overview/">Migration Plan</LinkChip>