Auswahl der Plattform-Komponenten
Festlegen, welche Schichten angepasst werden sollen (zum Beispiel Runtime, Datenbetrieb, Integrationskontrollen).
Überblick: Replatform
Abschnitt betitelt „Ü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
Abschnitt betitelt „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
Abschnitt betitelt „Design-Aspekte im STACKIT-Kontext“Kompatibilitätsgrenzen
Technische Randbedingungen und Fallback-Optionen vorab prüfen.
Risikogesteuerte Sequenzierung
Änderungen so staffeln, dass in einem Cutover-Fenster nicht zu viele Unbekannte zusammenkommen.
Nachweise und Abnahme
Messbare Verbesserungen für Performance, Stabilität und Betriebsaufwand definieren.
Empfohlener Design-Ablauf
Abschnitt betitelt „Empfohlener Design-Ablauf“- Define Landing Zone für den Workload und seine Kontrollgrenzen.
- Map Target Platform für Runtime-, Daten- und Integrationskomponenten.
- Adapt Platform Stack mit Voraussetzungen, Sequenzierung und Rollback-Checkpoints.
- Use migration tools für die Umsetzung über den gemeinsamen Migrationspfad.
- Nicht-funktionale Anforderungen validieren und Übergabe freigeben.
Datenplattform bei Replatform
Abschnitt betitelt „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
Abschnitt betitelt „Erforderliche Ergebnisse“Gemeinsame Ergebnisse für alle Migrationspfade
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „Diagramm-Schrittreferenz“Define Landing Zone
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.
Map Target Platform
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.
Adapt Platform Stack
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.