---
title: Replatform
description: Replatform führt gezielte Plattform-Änderungen während der Migration ein, um Betrieb, Skalierung und Kosten zu verbessern, ohne vollständiges Redesign.
sidebar:
label: Replatform
order: 3
source_url: "https://framework.stackit.cloud/de/migration/design-and-mobilize/design/replatform/"
source_file: "docs/de/migration/design-and-mobilize/design/replatform.mdx"
---
## Überblick: Replatform
Replatform behält das Kernverhalten der Anwendung bei, ändert aber ausgewählte Plattform-Komponenten,
um betriebliche oder wirtschaftliche Vorteile zu erreichen. Der Ansatz liegt zwischen Rehost und Refactor.
## Wann Replatform sinnvoll ist
- **Betriebliche Engpässe** lassen sich durch Plattform-Fähigkeiten reduzieren.
- **Moderate Veränderungen** sind möglich, ein vollständliches Redesign aber nicht.
- **Skalierungs- und Verfügbarkeitsziele** erfordern Infrastruktur-Verbesserungen.
- **Kostenziele** sind mit selektivem Plattformwechsel erreichbar.
## Design-Aspekte im STACKIT-Kontext
Festlegen, welche Schichten angepasst werden sollen (zum Beispiel Runtime, Datenbetrieb,
Integrationskontrollen).
Technische Randbedingungen und Fallback-Optionen vorab prüfen.
Änderungen so staffeln, dass in einem Cutover-Fenster nicht zu viele Unbekannte zusammenkommen.
Messbare Verbesserungen für Performance, Stabilität und Betriebsaufwand definieren.
## Empfohlener Design-Ablauf
1. Define Landing Zone für den Workload und seine Kontrollgrenzen.
2. Map Target Platform für Runtime-, Daten- und Integrationskomponenten.
3. Adapt Platform Stack mit Voraussetzungen, Sequenzierung und Rollback-Checkpoints.
4. Use migration tools für die Umsetzung über den gemeinsamen Migrationspfad.
5. Nicht-funktionale Anforderungen validieren und Übergabe freigeben.
## Datenplattform bei Replatform
Für zustandsbehaftete Workloads müssen Verantwortlichkeiten in Quelle und Ziel der Datenplattform vor dem Runtime-Cutover eindeutig festgelegt werden.
- **Verantwortung in der Quelle**: Zuständigkeit für Export/Dump und Konsistenzprüfungen festlegen.
- **Verantwortung im Ziel**: Zuständigkeit für Managed-DB-Bereitstellung, Zugriffskontrollen und Backup-Baseline festlegen.
- **Ablauf der Migration**: Schema-/Datenübernahme vom Runtime-Wechsel trennen und je Gate separat validieren.
- **Temporäre Zugriffskontrollen**: Temporäre Zugriffe für die Migration plus Rücknahme-Checkpoints explizit planen.
## Erforderliche Ergebnisse
### Gemeinsame Ergebnisse für alle Migrationspfade
- Freigegebener Design-Entscheidungsnachweis mit Scope, Annahmen und Governance-Sign-off.
- Validierungsnachweise für Security, Compliance und Betriebsbereitschaft.
- Entwurf des Migrations-Runbooks je Strategie aus der Design-Phase.
- Übergabepaket für Migration Factory Setup und Wellenplanung.
### Replatform-spezifische Ergebnisse
- Replatform-Entscheidungsmatrix mit ausgewählten Anpassungen.
- Kompatibilitäts- und Randbedingungsanalyse.
- Sequenziertes Migrations- und Rollback-Design.
- Zielbild für den Betrieb.
- Nutzenmetriken und Abnahmekriterien.
## Diagramm-Schrittreferenz
Landing-Zone-Controls und Guardrails als Ausgangspunkt für den Replatform-Pfad festlegen.
Plattformvoraussetzungen für Runtime-, Daten- und Integrations-Schichten früh absichern, damit
Substitutionen ohne Bruch in Governance und Betrieb eingeführt werden können.
- Landing Zones: Übersicht
- Application Landing Zone
- Landing-Zone Security and Compliance
Zielplattform-Mapping für den Replatform-Pfad über Runtime, Daten und Schnittstellen festlegen.
Abhängigkeiten inklusive Identität, Netzwerk und Daten-Verantwortung explizit dokumentieren, damit
jeder Wechsel vor Cutover einzeln validiert werden kann.
- Cloud-Design-Patterns
- Runbook Blueprint
Erforderliche Plattform-Voraussetzungen und Sequenz für den kontrollierten Wechsel definieren.
Rollback-Leitplanken, Readiness-Gates und Run-Ownership festlegen, damit Wellen auch bei mehreren
gleichzeitigen Plattformänderungen planbar bleiben.
- Runbook Blueprint
- Migrationsplan