--- title: Design description: Design erstellt je Anwendung ein klares Zielbild und ein ausführbares Migrations-Runbook auf Basis der R-Strategie-Entscheidung und des STACKIT Angebots. hero: tagline: Design überführt Discovery-Ergebnisse in umsetzbare Zielarchitekturen und Runbooks je Anwendung für die spätere Factory-Umsetzung. illustration: name: product position: left sidebar: label: Overview order: 0 source_url: "https://framework.stackit.cloud/de/migration/design-and-mobilize/design/overview/" source_file: "docs/de/migration/design-and-mobilize/design/overview.mdx" --- ## Ergebnis Das Modul Design erstellt für jede in Discovery erfasste Anwendung ein ausführbares Design für die Migration. Es geht nicht um ein abstraktes Papier, sondern um ein konkretes Paket, das eine Migration Factory stabil umsetzen kann. Definiert Zielarchitektur, Service-Auswahl, Integrationsansatz und Randbedingungen im STACKIT Kontext. Dokumentiert die gewählte Migrationsstrategie und begründet, warum Alternativen verworfen wurden. Liefert eine Schritt-für-Schritt-Anleitung mit Rückfallpfad und Validierungspunkten. Übergibt alle benötigten Ergebnisse an Migration Factory Setup, Landing Zone und Migrationsplan. ## Abgrenzung Die Module sind stark verzahnt, haben aber unterschiedliche Aufgaben: Entscheidet pro Anwendung Zielbild und Migrationsstrategie und erstellt ausführbare Runbooks. Ermöglicht die Umsetzung durch Auswahl und Vorbereitung des passenden Factory-Modells, Partners und Werkzeugkastens. Liefert die Plattform-Grundlage und Governance Controls, die im Zielbild berücksichtigt werden müssen. Überführt fertige Designs in realistische Wellen, Reihenfolgen, Abhängigkeiten und Meilensteine. ## Methode Die R-Strategie-Methodik ist das zentrale Modell in diesem Modul. Für jede Anwendung muss die gewählte Strategie mit Architektur-, Business-, Risiko- und Argumenten für den Betrieb belegt werden. ### Entscheidungskriterien je R-Strategie - **[Relocate](/de/migration/design-and-mobilize/design/relocate/)**: Sinnvoll, wenn eine schnelle Überführung von Virtualisierungs-Stacks möglich ist; je nach Wellenumfang tool-gestützt oder kontrolliert manuell ausführen. - **[Rehost](/de/migration/design-and-mobilize/design/rehost/)**: Sinnvoll bei geringer Veränderungstoleranz und engem Zeitrahmen, wenn Geschwindigkeit vor sofortiger Modernisierung steht. - **[Replatform](/de/migration/design-and-mobilize/design/replatform/)**: Sinnvoll, wenn begrenzte Anpassungen über die STACKIT Plattform klare Vorteile in Betrieb, Skalierung oder Kosten bringen. - **[Repurchase](/de/migration/design-and-mobilize/design/repurchase/)**: Sinnvoll für passende Angebote im STACKIT Ökosystem, in dieser Phase gezielt für Workspace by STACKIT, ServiceNow, RISE with SAP on STACKIT und STACKIT Domain Solutions. - **[Refactor](/de/migration/design-and-mobilize/design/refactor/)**: Sinnvoll für strategische Anwendungen, wenn eine cloud-native Überarbeitung klaren Mehrwert in Agilität, Resilienz oder Kosten schafft. - **[Retain](/de/migration/design-and-mobilize/design/retain-retire/#retain)**: Retain bei zeitlichen, technischen oder Governance-Hürden in der aktuellen Welle. - **[Retire](/de/migration/design-and-mobilize/design/retain-retire/#retire)**: Retire bei fehlendem Geschäftswert im Verhältnis zum Betriebsaufwand. ## Zentrale Schritte im Diagramm Das Diagramm ist nicht nur eine Visualisierung. Es ist der Referenzablauf für die Übergabe zwischen Modulen und für die zentralen Design-Governance-Checkpoints. ### 1. Discovery Input Ausgangslage und Randbedingungen absichern: fachlicher Kontext, Workload-Inventar, Abhängigkeiten und Restriktionen für die folgenden Design-Entscheidungen. - Discovery: Übersicht ### 2. Bewerten und priorisieren Kandidaten für das Design nach Kritikalität, Risiko, Aufwand und Eignung für Wellen priorisieren. Dieser Schritt steuert, wo Design-Kapazität zuerst eingesetzt wird. - Migrationsplan ### 3. Determine migration path Die passende R-Strategie je Anwendung festlegen und in den jeweiligen Design-Pfad verzweigen (Relocate, Rehost, Replatform, Repurchase, Refactor, Retain oder Retire). - Relocate - Rehost - Replatform - Repurchase - Refactor - Retain/Retire ### 4. Validation Alle Design-Pfade in einem gemeinsamen Qualitäts-Gate betrachten. Annahmen zur Architektur, Security/Compliance, Runbook-Qualität und Betriebsreife validieren. - Security and Compliance - Runbook-Readiness ### 5. Transition Die kontrollierte Übergabe in den Migrationslauf vorbereiten: Release-Reife, Wellen-Fit, Koordinationsfenster und klare Übergabe der Verantwortung. - Migration Factory Setup: Übersicht - Collaboration and Interfaces ### 6. Production Kriterien für den Produktiv-Handover und die Day-1-Betriebsbasis nach erfolgreicher Transition finalisieren. Damit ist der im Diagramm dargestellte Design-Prozess abgeschlossen. - Migrate - Operating Model Handover ## Zielbild 1. Scope und Baseline aus Discovery bestätigen (Abhängigkeiten, Nutzung, Kritikalität, Restriktionen). 2. Fachliche und technische Designziele festlegen, inklusive Verfügbarkeit, Security, Compliance und Performance. 3. R-Strategie-Optionen gegen klare Kriterien bewerten und die gewählte Strategie begründet dokumentieren. 4. Zielbild auf STACKIT Produkte und Plattform-Fähigkeiten abbilden, inklusive Netzwerk, Identität, Daten und Betrieb. 5. Migrationsvorgehen spezifizieren (Cutover-Ansatz, Datenumzug, Integrationswechsel, Rückfallstrategie). 6. Ausführbares Runbook für die Factory mit Aufgaben, Qualitätschecks und Abnahmekriterien erstellen. 7. Design-Annahmen mit Architektur, Security, Plattform und Business-Ownern validieren. 8. Freigegebenes Designpaket an Migration Factory Setup und Migrationsplan übergeben. ## Paket Mindestens folgende Inhalte sollten je Anwendung vorliegen: - **Zielarchitektur-Definition**: Workload-Platzierung, Service-Mapping, Modell für Integrationen und nicht-funktionale Anforderungen. - **R-Strategie-Entscheidungsnachweis**: Gewählte Strategie, Kriterien, geprüfte Alternativen und Haupt-Risiken. - **Migrations-Runbook**: Reihenfolge der Ausführung, Checks vor dem Lauf, Rückfallpfad, Validierung und Go-live-Kriterien. - **Abhängigkeiten und Schnittstellen**: Bedarf für Koordination mit vor- und nachgelagerten Systemen und Übergangsfenstern. - **Compliance- und Security-Controls**: Verpflichtende Controls und Nachweise für Release-Reife. ## Muster Nutzen Sie die dedizierte Pattern-Seite, um vor Auswahl des Migrations-Runbooks ein klares Zielbild zu definieren. - Cloud-Design-Patterns ## Workload-Use-Case-Sicht für Migrationsvarianten Nutzen Sie ergänzend zur R-Strategie die Workload-Sicht, um zu klassifizieren, was migriert wird, und um machbare Umsetzungsvarianten mit expliziten Rahmenbedingungen auszuwählen. - Workload Migration Use Cases - Zielservice-Mappings für AWS und Azure ## KI-gestützte Design-Assets KI-gestützte Design-Assets unterstützen Architekten dabei, Anwendungsanforderungen, Services aus der Ausgangslage und R-Strategie-Optionen in prüfbare Zielbildvorschläge zu überführen. Die Ergebnisse dienen als Input für Architektur-, Security-, Plattform- und Business-Validierung, bevor ein Migrationspfad freigegeben wird. ## Runbook-Assets ## Wirkung Die Qualität der Migrationsplanung hängt direkt von der Design-Qualität ab. Reihenfolge der Wellen, Factory-Durchsatz und Liefer-Risiko werden durch die Präzision der Zielentwürfe und Ablaufpläne bestimmt. Unvollständige Designs führen in der Praxis zu instabilen Wellen und Verzögerungen.