Belastbare Basis
Eine belastbare Basis für Umfang, Risiken und Kostentreiber schaffen.
CloudMent AI-Powered Cloud Advisor
CloudMent
Migration Framework Walkthrough
Zuletzt aktualisiert am
STACKIT
Migration Framework Walkthrough
Vollständiger Migrations-Walkthrough für Vortragende von Assess über Design and Mobilize und Migrate bis Run, mit den zentralen Grafiken des Frameworks.
Migrationsphasen
Starten Sie mit dem Ende-zu-Ende-Framework und seinem visuellen Modell, damit das Publikum jede folgende Aktivität in der Reise von Assess über Design and Mobilize und Migrate bis Run einordnen kann.
Einordnung
Abschnitt betitelt „Einordnung“Die folgende Übersicht zeigt, wie das Framework als durchgängiger Steuerungsrahmen über alle Migrationsphasen eingesetzt wird.
Framework-Übersicht
Abschnitt betitelt „Framework-Übersicht“Die folgende Übersicht fasst den Migrationslebenszyklus von der ersten Bewertung bis zum stabilen Betrieb zusammen. Sie schafft ein gemeinsames Verständnis zu Verantwortlichkeiten, Abhängigkeiten und erwarteten Ergebnissen über alle Phasen hinweg.
Zweck und Ziele
Abschnitt betitelt „Zweck und Ziele“Das Migration Framework reduziert Unsicherheit in Cloud-Transformationsvorhaben und schafft einen klaren Pfad von Strategie bis Umsetzung. Es verbindet Business-Prioritäten mit technischer Planung, damit Migrationsentscheidungen nicht isoliert getroffen werden.
Typische Ziele sind:
Skalierbare Zielausrichtung
Zielarchitektur und Operating Model für langfristiges Wachstum definieren.
Kontrollierte Migrationswellen
Migration in kontrollierten Wellen mit messbarem Fortschritt umsetzen.
Stabiler Run-Betrieb
Stabilen Run-Betrieb mit kontinuierlicher Optimierung etablieren.
So nutzen Sie das Framework effektiv
Abschnitt betitelt „So nutzen Sie das Framework effektiv“Nutzen Sie das Diagramm als Navigationskarte und nicht nur als lineare Abfolge von Boxen. Jede Phase enthält Module, die eine konkrete Entscheidungsfrage adressieren.
Empfohlene Vorgehensweise:
- Starten Sie mit Assess, um eine faktenbasierte Ausgangslage und einen gemeinsamen Business-Kontext zu schaffen.
- Nutzen Sie Design and Mobilize, um Architektur-, Governance- und Fähigkeitsentscheidungen explizit zu machen.
- Verstehen Sie Migrate als iterative Umsetzung mit Rückkopplungen in Planung und Optimierung.
- Verankern Sie langfristigen Nutzen in Run durch das Zusammenspiel aus Operations, Customer Success und Support.
Praktische Hinweise
Abschnitt betitelt „Praktische Hinweise“Die besten Ergebnisse entstehen, wenn Business, Architektur, Plattform, Security und Operations als gemeinsames Programmteam mit regelmäßigen Entscheidungszyklen arbeiten. Halten Sie Annahmen transparent, verfolgen Sie Abhängigkeiten zwischen Modulen und definieren Sie klare Ein- und Austrittskriterien je Phase. So bleibt die Migration planbar und gleichzeitig anpassbar bei neuen Erkenntnissen.
Typische Migrations-Use-Cases
Abschnitt betitelt „Typische Migrations-Use-Cases“Organisationen nutzen das Framework häufig in einem von zwei Basisszenarien:
- On-Premises nach STACKIT: Bestehende Infrastruktur wird in eine souveräne Cloud-Zielumgebung auf STACKIT überführt.
- Von einer anderen Cloud nach STACKIT: Workloads werden von einem anderen Hyperscaler oder Cloud-Provider migriert.
In beiden Szenarien stehen je nach Programm unterschiedliche Motivatoren im Vordergrund:
- Kostenfokus: Kostentransparenz verbessern, langfristige Betriebskosten senken und Verbrauchsmodelle optimieren.
- Modernisierungsfokus: Agilität steigern, Managed Services nutzen und Liefergeschwindigkeit erhöhen.
In der Praxis treten beide Motivatoren oft gleichzeitig auf. Das Framework unterstützt die Balance, indem Workloads entlang der R-Strategie-Systematik bewertet und je Applikation der passende Weg ausgewählt wird:
- Rehost: Workloads mit minimalen Änderungen schnell migrieren.
- Replatform: Gezielte Optimierungen an der Plattform ohne vollständiges Redesign umsetzen.
- Repurchase: Auf eine SaaS-Alternative wechseln, wenn der Geschäftswert steigt.
- Refactor: Workloads für cloud-native Fähigkeiten teilweise oder vollständig neu gestalten.
- Retain: Workloads vorerst beibehalten, wenn eine Migration aktuell keinen Vorteil bringt.
- Retire: Workloads stilllegen, die keinen relevanten Geschäftswert mehr liefern.
Die explizite Anwendung dieser R-Strategie-Optionen hilft, pauschale Migrationsentscheidungen zu vermeiden und jeden Workload-Übergang auf Business Value, Risikoprofil und Umsetzungsaufwand auszurichten.
Assess
Positionieren Sie Assess als die schnelle Phase mit geringem Aufwand, die eine erste Faktenbasis schafft und die Migrationsabsicht qualifiziert, bevor die tiefere Design-Arbeit beginnt.
Überblick: Diese Phase
Abschnitt betitelt „Überblick: Diese Phase“Assess ist die erste Phase des STACKIT Migration Frameworks. Sie schafft eine belastbare, faktenbasierte Grundlage für Migrationsentscheidungen, bevor Zielbilder und Migrationswellen detailliert ausgearbeitet werden.
Die Phase verbindet technische Bewertung, kommerzielle Transparenz und organisatorische Abstimmung, damit die nachfolgende Umsetzung mit klaren Prioritäten startet.
Wann Assess startet und endet
Abschnitt betitelt „Wann Assess startet und endet“Assess startet typischerweise dann, wenn ein Vorhaben strategisch priorisiert ist, aber noch keine belastbare Grundlage für Entscheidungen vorliegt.
- Start mit grob definiertem Scope, Business-Treibern und benannten Entscheidungsträgern.
- Aufbau der Basis durch Rapid Discovery, Readiness-Bewertung, Kostenmodellierung und Workshops.
- Abschluss, sobald Scope-Annahmen, Migrationsreife und wirtschaftliche Leitplanken belastbar sind.
Assess ist abgeschlossen, wenn der Übergang in Design and Mobilize auf einer gemeinsamen Sicht zu Kosten, Risiken und Umsetzbarkeit freigegeben werden kann.
Warum diese Phase wichtig ist
Abschnitt betitelt „Warum diese Phase wichtig ist“Assess reduziert Unsicherheit in einem frühen Stadium und richtet Business und IT aus, bevor umfangreiche Umsetzungsaufwände entstehen.
Finanzielle Transparenz
Eine erste Kostenbandbreite und TCO-Sicht liegt für Investitionsentscheidungen vor.
Klarheit zur Readiness
Lücken in Technologie, Governance, Fähigkeiten und Betriebsmodell werden früh sichtbar.
Stakeholder-Alignment
Führung, Delivery-Teams und technische Verantwortliche einigen sich auf Ziele und Erwartungen.
Risikoreduktion
Kritische Annahmen und Restriktionen werden dokumentiert, bevor das Zielbild detailliert wird.
Module in dieser Phase
Abschnitt betitelt „Module in dieser Phase“- Rapid Discovery: Liefert Mengen und Daten für frühe Kostenabschätzungen.
- TCO Report: Bewertet die Gesamtkosten und den wirtschaftlichen Verlauf der Migration.
- Readiness Assessment: Bewertet die Bereitschaft zur Migration in Technologie und Organisation.
- Deepdive Workshop: Macht die technischen Teams früh mit der STACKIT Plattform und relevanten Services vertraut.
- Briefings and Workshops: Stimmt Kunde und STACKIT zu Anforderungen, Verantwortlichkeiten und der vorvertraglichen Zusammenarbeit ab.
Typische Ergebnisse
Abschnitt betitelt „Typische Ergebnisse“Am Ende von Assess sollten mindestens folgende Ergebnisse vorliegen:
- Entscheidungsreife Ausgangsbasis: Dokumentierte Sicht auf Ist-Landschaft, Umfang und Kandidaten für die Migration.
- Erste Kostenübersicht: Kostenindikation und TCO-Richtung mit transparenten Annahmen.
- Readiness und Sicht auf Risiken: Priorisierte Lücken und notwendige Maßnahmen für die Mobilisierung.
- Übergabekriterien: Klare Entry-Kriterien für Design and Mobilize.
Übergang zu Design and Mobilize
Abschnitt betitelt „Übergang zu Design and Mobilize“Assess finalisiert nicht die gesamte Zielarchitektur. Die Phase liefert die validierten Eingaben, um in Design and Mobilize die detaillierte Planung, Wellenplanung und Factory-Vorbereitung umzusetzen.
Überblick
Abschnitt betitelt „Überblick“Rapid Discovery liefert in kurzer Zeit eine schnelle, automatisierte Ausgangsbasis über bestehende Umgebungen in On-Premises- und Cloud-Landschaften. Der Fokus liegt auf der quantitativen Erfassung des IT-Portfolios, damit frühe Migrations- und kommerzielle Entscheidungen fundiert getroffen werden können.
In dieser Phase sind Mengen und Verteilung wichtiger als die detaillierten Abhängigkeiten einzelner Anwendungen.
Welche Informationen Rapid Discovery erfasst
Abschnitt betitelt „Welche Informationen Rapid Discovery erfasst“Rapid Discovery erstellt ein initiales Inventar von Infrastruktur- und Plattform-Assets, unter anderem:
Compute-Basis
Anzahl virtueller Maschinen und Hosts.
Storage-Basis
Speicherkapazitäten und Storage-Klassen.
Betriebssystem-Landschaft
Betriebssystemfamilien und Versionen.
Kubernetes-Basis
Anzahl und Basiseigenschaften von Kubernetes-Clustern.
Datenbank-Inventar
Datenbank-Engines, Größen und Instanzanzahlen.
Diese Kennzahlen bilden die erste belastbare Sicht auf den Umfang der Migration.
Warum es in der Assess-Phase wichtig ist
Abschnitt betitelt „Warum es in der Assess-Phase wichtig ist“Die Ergebnisse aus Rapid Discovery sind eine zentrale Grundlage für:
- Frühe Preisindikation: Eine erste STACKIT-nahe Kostenindikation erzeugen.
- Erste TCO-Sicht: Einen initialen TCO-Korridor ableiten.
- Kapazitätsannahmen: Erste Annahmen zur Zielkapazität und Landing Zone definieren.
Dadurch können sich Programm-Stakeholder frühzeitig auf eine finanzielle Richtung und eine technische Ausgangsbasis einigen.
Abgrenzung zur Discovery-Phase
Abschnitt betitelt „Abgrenzung zur Discovery-Phase“Rapid Discovery ist bewusst keine vollständige Analyse auf Applikationsebene. Es umfasst weder tiefgehende Interviews mit allen Application Ownern noch eine vollständige Abbildung aller Laufzeitabhängigkeiten.
Diese Tiefe wird in der anschließenden Discovery-Phase erreicht: Dort werden Infrastruktur-Exporte durch gezielte Assessments und Informationen der Application Owner ergänzt, um ein vollständiges Applikationsbild zu erstellen.
Typische Eingaben und zukünftige Assets
Abschnitt betitelt „Typische Eingaben und zukünftige Assets“Typische Eingabequellen sind Exporte wie Tabellen oder ähnliche Inventardateien aus bestehenden Umgebungen. Die Phase kann durch KI-gestützte Tools beschleunigt werden, die aus hochgeladenen Datensätzen die benötigten Baseline-Kennzahlen extrahieren.
Rapid Discovery ist damit eine wichtige Voraussetzung für eine strukturierte Kostenindikation sowie für die Entwicklung einer realistischen Strategie für die Cloud-Zielumgebung.
KI-gestützte Discovery-Assets
Abschnitt betitelt „KI-gestützte Discovery-Assets“KI-gestützte Discovery-Assets können helfen, Workload-Beschreibungen und Daten aus Inventaren in erste Assessment- und Design-Artefakte für die fachliche Prüfung zu überführen.
Asset-Titel
Framework
Asset-Typ
Migration
Software
Rapid-Discovery-Prozess auf einen Blick
Abschnitt betitelt „Rapid-Discovery-Prozess auf einen Blick“Das folgende Diagramm zeigt den Kern von Rapid Discovery: Rohdaten aus Quellsystemen werden durch Tooling in eine entscheidungsreife Baseline überführt, die frühe Preisindikationen und erste Sizing-Annahmen ermöglicht.
Methodik in der Praxis
Abschnitt betitelt „Methodik in der Praxis“Eine belastbare Rapid Discovery folgt typischerweise einem klaren Ablauf:
- Datensammlung aus vorhandenen Quellen (CMDB, Hypervisor-Exporte, Cloud-Inventare, Monitoring, Storage-Reports, Datenbanklisten).
- Standardisierung und Konsolidierung der Daten in ein einheitliches Schema.
- Kategorisierung nach Workload-Typen und technischen Merkmalen.
- Aggregation auf Management-Ebene für schnelle Entscheidungsfindung.
- Erste Plausibilisierung mit Fachverantwortlichen.
Ziel ist kein perfektes Zielbild, sondern ein verlässlicher Startpunkt mit ausreichender Genauigkeit für frühe Entscheidungen.
Datenqualität und Annahmen
Abschnitt betitelt „Datenqualität und Annahmen“Die Aussagekraft der Ergebnisse hängt stark von der Datenqualität ab. Typische Herausforderungen sind Dubletten, veraltete Einträge, inkonsistente Benennungen und fehlende Leistungsdaten.
Empfehlung für diese Phase:
- Annahmen dokumentieren: Wachstumsraten, Konsolidierungsfaktoren und Reserven transparent halten.
- Unklare Datensätze markieren: Unsichere Datensätze kennzeichnen statt früh zu verwerfen.
- Konfidenzniveau vergeben: Ergebnisse als hoch, mittel oder niedrig einstufen.
So bleibt die Kostenindikation nachvollziehbar und später in der Discovery-Phase gezielt verfeinerbar.
Verbindung zu Preisindikation und TCO
Abschnitt betitelt „Verbindung zu Preisindikation und TCO“Rapid Discovery liefert die Mengengerüste für erste Kostenmodelle. Dafür werden die erfassten Bestände in STACKIT-nahe Verbrauchseinheiten überführt, zum Beispiel:
- Compute-Sizing: vCPU und RAM als Grundlage nutzen.
- Storage-Klassen: Storage-Kapazität und I/O-Profile verwenden.
- Managed Services: Datenbanktyp und Größenklassen zuordnen.
- Plattformkosten: Cluster- und Node-Anzahlen einbeziehen.
In Kombination mit Betriebsannahmen (Betriebszeiten, Verfügbarkeit, Wachstumspfad) entsteht daraus eine belastbare Preisindikation und ein erster TCO-Korridor.
Typische Ergebnisse
Abschnitt betitelt „Typische Ergebnisse“Am Ende der Rapid-Discovery-Phase sollten mindestens folgende Ergebnisse vorliegen:
Konsolidierte Asset-Baseline
Mengen je Technologiebereich liegen konsolidiert vor.
Sinnvolle Segmentierung
Assets sind nach Kritikalität, Umgebung und Modernisierungsbedarf segmentiert.
Nachvollziehbare Annahmen
Annahmen und erkannte Datenlücken sind transparent dokumentiert.
Erste Kostenindikation
Eine erste Kostenbandbreite mit den wichtigsten Treibern liegt vor.
Priorisierte Kandidaten
Eine priorisierte Liste für die vertiefende Discovery-Phase ist verfügbar.
Diese Ergebnisse bilden die Arbeitsgrundlage für Architektur, Planung und Governance der nächsten Assess-Schritte.
Risiken und Gegenmaßnahmen
Abschnitt betitelt „Risiken und Gegenmaßnahmen“Häufige Risiken in Rapid Discovery sind zu grobe Kategorisierung, unvollständige Quellsysteme oder eine Überschätzung der Datenreife.
Bewährte Gegenmaßnahmen:
- Datenquellen kombinieren: Mehrere Quellen nutzen statt nur einer Quelle.
- Ausreißer prüfen: Sehr große oder sehr alte Systeme systematisch bewerten.
- Perspektiven abstimmen: Finanz- und Technikblick gemeinsam ausrichten, um Fehlinterpretationen zu vermeiden.
Damit bleibt die Phase schnell, ohne an Entscheidungsqualität zu verlieren.
Übergang in die Discovery-Phase
Abschnitt betitelt „Übergang in die Discovery-Phase“Der Übergang ist erreicht, wenn ein belastbarer Überblick über Mengen, Technologietypen und Kostenhebel vorliegt und die offenen Punkte klar benannt sind.
In der Discovery-Phase werden diese offenen Punkte gezielt geschlossen, unter anderem durch Interviews mit Application Ownern, vertiefende Assessments und die Analyse von Abhängigkeiten, Compliance- und Betriebsanforderungen.
Übersicht
Abschnitt betitelt „Übersicht“CloudMent AI-Powered Cloud Advisor unterstützt Migrationsteams in Assess sowie Design and Mobilize. Die Lösung kombiniert CloudMent Deck für strukturierte Assessment-Ergebnisse mit CloudMent Essential für interaktive STACKIT Beratung.
Architekten und Portfolio-Teams können Anforderungen erfassen, Services aus der Ausgangslage auf STACKIT Optionen abbilden, R-Strategien auswählen, Zielbilder entwerfen und STACKIT Laufkosten abschätzen. Empfehlungen basieren auf STACKIT Dokumentation und enthalten Quellenhinweise für die fachliche Prüfung.
Einordnung im Migration Framework
Abschnitt betitelt „Einordnung im Migration Framework“- Rapid Discovery und Readiness Assessment: Erfasst Anwendungen sowie funktionale und nicht-funktionale Anforderungen für erste Readiness- und Portfolio-Sichten.
- Discovery und Design: Ordnet Services von AWS, Azure und Google Cloud passenden STACKIT Optionen zu und unterstützt die R-Strategie-Auswahl im Design.
- Business Case: Schätzt monatliche STACKIT Laufkosten anhand von Preisinformationen und erzeugt Grundlagen für die Migrationsplanung.
- Enablement: Unterstützt Teams mit einer geführten Advisory-Oberfläche zu STACKIT Service-Optionen, Terraform-Mustern und Architekturentscheidungen.
Typische Fähigkeiten
Abschnitt betitelt „Typische Fähigkeiten“- Bewertung auf Basis von Anforderungen: Erstellt aus Workload-Beschreibungen, Inventaren oder CMDB-Quellen Entwürfe für Readiness, R-Strategie, Zielbild und Business Case.
- Nachvollziehbare Beratung: Nutzt STACKIT Dokumentation und Provider-Kontext, damit Empfehlungen über Quellen geprüft werden können.
- Source-to-Target-Mapping: Vergleicht Hyperscaler-Services mit STACKIT Alternativen und kennzeichnet direkte Fits, Teil-Fits und Lücken.
- Interaktive Design-Unterstützung: Erstellt und verfeinert Zielarchitektur-Optionen mit Service-Mapping, Kostenschätzung und Terraform-Entwürfen.
Typische Eingaben und Ergebnisse
Abschnitt betitelt „Typische Eingaben und Ergebnisse“- Eingaben: Workload-Beschreibungen, Inventare, Anforderungen, Unterlagen zur Architektur, CSV- oder Excel-Exporte und optionale CMDB-Quellen wie ServiceNow oder LeanIX.
- Ergebnisse: Readiness Assessment, R-Strategie-Klassifikation, Service-Mapping, Zielarchitektur, Business-Case-Schätzung, Terraform-Entwurf und Quellenhinweise.
- Prüfbedarf: Ergebnisse dienen als Entscheidungsunterstützung und müssen durch qualifizierte Experten für Migration, Architektur, Security und Betrieb validiert werden.
Typische Eignungskriterien
Abschnitt betitelt „Typische Eignungskriterien“- Hyperscaler-zu-STACKIT-Migrationen: Gute Eignung für Portfolios, die von AWS, Azure oder Google Cloud nach STACKIT migrieren.
- Große oder unklare Portfolios: Hilfreich, wenn viele Anwendungen, unvollständige Dokumentation oder Service-Mapping-Arbeit Assessment und Design verlangsamen.
- Souveränitätsanforderungen: Relevant für regulierte Organisationen, die nachvollziehbare Empfehlungen und EU-basierte Verarbeitung auf STACKIT benötigen.
Einschränkungen
Abschnitt betitelt „Einschränkungen“- Keine Ausführungsautomatisierung: CloudMent migriert keine Workloads, führt keine Cutover aus und provisioniert keine Infrastruktur des Kunden.
- Kein agentenbasierter Scan: Die Analyse basiert auf bereitgestellten Eingabedaten statt auf direktem Scanning der bestehenden Umgebung.
- Prüfung durch Experten erforderlich: R-Strategie, Kosten, Compliance, Terraform und Architektur müssen vor der Nutzung geprüft werden.
Referenz
Abschnitt betitelt „Referenz“- Produktseite: CloudMent
- Dokumentation: Öffentliche Produktdokumentation ist in Vorbereitung.
- Marketplace-Listing: STACKIT Marketplace Listing ist in Arbeit.
What TCO analysis is actually for
Section titled “What TCO analysis is actually for”A TCO analysis is not primarily a cost-reduction argument. It is a decision-making tool. Its purpose is to make visible all costs — including those that are currently invisible — so that a comparison between the current state and the cloud target state is honest and complete.
The most common mistake in TCO analysis is treating it as a budget exercise: comparing the invoice from the cloud provider against the invoice from the current hosting provider. That comparison is almost always misleading, because it ignores the majority of relevant costs on the on-premises side.
The sixteen cost categories
Section titled “The sixteen cost categories”A complete TCO model covers sixteen categories across four groups.
Direct infrastructure costs include hardware acquisition and depreciation, data centre space (power, cooling, space), network infrastructure, and storage systems. These are the costs most organisations can already see — but even here, the fully loaded cost is often underestimated because hardware refresh cycles are treated as capital expenditure rather than operating cost.
Software and licensing costs include operating system licences, virtualisation licences (VMware, Hyper-V), database licences, monitoring and management tooling, and backup and recovery software. Licensing is often the category where the largest surprises occur in cloud migration projects: licences that were purchased once and amortised over many years appear as a large one-time cost when they must be replaced or renegotiated.
Operations and personnel costs include IT operations staff (system administration, network operations, storage management), on-call costs, and the opportunity cost of skilled staff spending time on infrastructure rather than on business-value work. Personnel costs are typically the largest single category in a complete TCO model — and the one most frequently omitted from cloud business cases.
Compliance and risk costs include security tooling and personnel, compliance audit preparation and execution, insurance, and the cost of maintaining certifications (ISO 27001, BSI IT-Grundschutz). These costs are frequently invisible in the current state because they are distributed across multiple cost centres and headcount — but they are real, and cloud platforms that provide compliance features as a managed service reduce them materially.
The hidden costs
Section titled “The hidden costs”Beyond the sixteen standard categories, there are costs that most TCO analyses miss entirely. Downtime cost — the financial impact of system outages, calculated as revenue at risk per hour multiplied by historical availability figures. Technical debt amortisation — the cost of maintaining increasingly outdated infrastructure that cannot be fully modernised within current budgets. Talent acquisition premium — the cost of recruiting and retaining infrastructure engineers in a market where cloud skills command a premium over legacy infrastructure skills. Shadow IT — the cost of business units buying cloud services outside the official IT budget because official IT is too slow, which creates uncontrolled cloud spend and security gaps.
Building the comparison
Section titled “Building the comparison”The comparison between on-premises and cloud should cover a three-year period, since that is the typical payback horizon for cloud transformation investments. Both the current state and the cloud target state should be modelled on a year-by-year basis, because cloud costs are not constant: they typically decrease as reserved capacity is optimised, as workloads are right-sized, and as FinOps practices mature.
The current state model should include all sixteen cost categories, including the ones that are currently hidden. The cloud target state model should include provider costs (compute, storage, network, managed services), migration investment, staff retraining, and ongoing FinOps operations — but should credit back the infrastructure costs that will be retired.
The migration investment — the one-time cost of the transformation itself — should be presented separately from the ongoing run cost, so that the board can evaluate it as a capital decision distinct from the operational efficiency improvement.
Überblick
Abschnitt betitelt „Überblick“Der Deepdive Workshop ist ein ein- bis zweitägiger technischer Workshop für die Personen, die Workloads später auf STACKIT entwickeln, migrieren, betreiben oder unterstützen. Er vermittelt frühzeitig die Grundlagen der Plattform und schafft ein gemeinsames technisches Verständnis, bevor detailliertes Design und die Migrationsumsetzung beginnen.
Im Workshop werden relevante STACKIT Services und Konzepte im Kontext der geplanten Migration vorgestellt. Abhängig von Agenda und verfügbarer Umgebung können die Teilnehmenden ausgewählte Services auch direkt ausprobieren.
Der Workshop hilft technischen Teams dabei,
- die STACKIT Plattform und ihre grundlegenden Konzepte kennenzulernen;
- für ihre Workloads und ihr Betriebsmodell relevante Services zu verstehen;
- technische Fragen und Annahmen frühzeitig mit STACKIT Expertinnen und Experten zu besprechen; und
- Themen zu erkennen, die in den folgenden Phasen weiter vertieft werden müssen.
Typische Workshop-Themen
Abschnitt betitelt „Typische Workshop-Themen“Die konkrete Agenda wird auf den Migrationsumfang und die teilnehmenden Rollen zugeschnitten. Typische Themen sind:
- Plattform-Grundlagen: Regionen, Projekte, Identity und Access Management, Netzwerk- und Security-Konzepte.
- Relevante Services: Compute, Storage, Kubernetes, Datenbanken und weitere für die Ziel-Workloads passende Services.
- Betriebskonzepte: Monitoring, Logging, Automatisierung, Verantwortlichkeiten und Support-Modelle.
- Migrationskontext: Wie sich bestehende Workloads, Abhängigkeiten und technische Anforderungen auf STACKIT berücksichtigen lassen.
- Praktische Erprobung: Optionale angeleitete Übungen in einer vorbereiteten Umgebung, um ausgewählte Services und Abläufe kennenzulernen.
Teilnehmende und Vorbereitung
Abschnitt betitelt „Teilnehmende und Vorbereitung“Laden Sie die technischen Personen ein, die nach der Migration mit der Plattform arbeiten, zum Beispiel Application Teams, Infrastruktur- und Platform Engineers sowie Fachleute für Betrieb, Security und Netzwerk. Der Workshop ist besonders wirksam, wenn das Team eine erste Sicht auf Workloads, technische Rahmenbedingungen und zu klärende Fragen einbringt.
Stimmen Sie vorab Agenda, teilnehmende Rollen, verfügbare Testumgebung und notwendige Zugänge ab. So konzentrieren sich die Sessions auf die für die Migration relevanten Services und Konzepte.
Erwartete Ergebnisse
Abschnitt betitelt „Erwartete Ergebnisse“Nach dem Workshop verfügen die Teilnehmenden über:
- ein gemeinsames Grundverständnis der STACKIT Plattform;
- eine erste Sicht auf die für ihre Migration relevanten Services und Konzepte;
- dokumentierte technische Fragen, Annahmen und Folgethemen; und
- klarere Eingaben für Discovery, Zielarchitektur und Migrationsplanung.
Abgrenzung und nächste Schritte
Abschnitt betitelt „Abgrenzung und nächste Schritte“Der Deepdive Workshop ist ein Format zur Orientierung und Zusammenarbeit. Er ersetzt kein strukturiertes Enablement und keine vollständige technische Schulung. Planen Sie auf Grundlage der Workshop-Ergebnisse die erforderlichen rollenspezifischen Trainings- und Enablement-Aktivitäten in den folgenden Phasen.
Überblick
Abschnitt betitelt „Überblick“Briefings and Workshops sind gezielte Austauschformate zwischen Kunde und STACKIT, bevor die Vertragsbeziehung beginnt. Sie kommen zum Einsatz, wenn eine Selbstregistrierung für die geplante Nutzung der Plattform, den Migrationsumfang oder die erforderliche kommerzielle und betriebliche Ausgestaltung nicht ausreicht.
Die Sessions schaffen ein gemeinsames Verständnis zu den Zielen und Anforderungen des Kunden sowie zu den Services, Verantwortlichkeiten und dem Zusammenarbeitsmodell, das STACKIT bereitstellen kann. Ziel ist eine für beide Seiten klare, praktikable und passende Vertragsbeziehung.
Wann das Modul eingesetzt wird
Abschnitt betitelt „Wann das Modul eingesetzt wird“Nutzen Sie Briefings and Workshops, wenn die geplante Zusammenarbeit über ein standardisiertes Self-Service-Setup hinausgehende Abstimmungen erfordert, etwa bei einer größeren Migration, spezifischen Compliance-Anforderungen, mehreren Kundenorganisationen oder individuellen kommerziellen und betrieblichen Rahmenbedingungen.
Das Format kann aus einem kurzen Briefing, mehreren Arbeitssessions oder einem gemeinsamen Workshop bestehen. Umfang und Teilnehmende richten sich nach der Komplexität und dem Entscheidungsbedarf der Zusammenarbeit.
Themen zur Klärung und Synchronisierung
Abschnitt betitelt „Themen zur Klärung und Synchronisierung“Die Sessions schaffen eine gemeinsame und dokumentierte Grundlage für folgende Themen:
- Geschäftsziele und Scope: Geplante Plattformnutzung, Migrationsziele, Prioritäten, erwartete Größenordnung und relevante Workloads.
- Organisationen und Verantwortlichkeiten: Kundenansprechpersonen, Entscheidungsträger, technische Teams, Einkauf sowie die jeweiligen Verantwortlichkeiten von Kunde und STACKIT.
- Account- und Projektstruktur: Benötigte Organisationen, Projekte, Zugriffsrollen, Ownership-Modell und die für die Nutzung erforderliche Einrichtung.
- Security, Compliance und Datenschutz: Regulatorische Anforderungen, Datenklassifikation, Datenresidenz, Security-Erwartungen und erforderliche Nachweise für interne Freigaben.
- Kommerzielles Modell und Vertrag: Erforderlicher Vertragsumfang, Preis- und Abrechnungserwartungen, Commitments, Beschaffungsprozess und notwendige vertragliche Klärungen.
- Betrieb und Support: Service-Erwartungen, Support-Modell, Eskalationswege, betriebliche Verantwortlichkeiten und relevante Verfügbarkeitsanforderungen.
- Lieferplanung: Voraussetzungen, Abhängigkeiten, Zeitplan, Entscheidungspunkte und die nächsten Schritte zu Onboarding, Design und Migration.
Teilnehmende und Vorbereitung
Abschnitt betitelt „Teilnehmende und Vorbereitung“Beziehen Sie die Personen ein, die die relevanten geschäftlichen, technischen, rechtlichen und betrieblichen Fragen klären können. Abhängig von der Zusammenarbeit gehören dazu Kundensponsoren, Einkauf, Legal, Vertretungen für Security und Compliance, technische Verantwortliche sowie die entsprechenden Ansprechpersonen bei STACKIT.
Bereiten Sie die Sessions mit einer ersten Beschreibung der geplanten Nutzung, bekannter Anforderungen, erwarteter Größenordnung und offener Fragen vor. So konzentriert sich die Abstimmung auf Entscheidungen und ungeklärte Annahmen statt auf reine Grundlagenklärung.
Erwartete Ergebnisse
Abschnitt betitelt „Erwartete Ergebnisse“Am Ende des Moduls sollten beide Seiten über Folgendes verfügen:
- ein gemeinsames Verständnis der geplanten Plattformnutzung und des Umfangs der Zusammenarbeit;
- eine dokumentierte Sicht auf Anforderungen, Annahmen, Abhängigkeiten und offene Punkte;
- Einigkeit über die erforderliche Account-, Security-, Support- und kommerzielle Ausgestaltung;
- klare Verantwortlichkeiten und Entscheidungsverantwortliche für die nächsten Schritte; und
- einen gegenseitig verstandenen Weg zu Vertrag und anschließendem Onboarding.
Einordnung zu weiteren Assess-Aktivitäten
Abschnitt betitelt „Einordnung zu weiteren Assess-Aktivitäten“Briefings and Workshops ersetzen weder die technische Discovery noch einen Deepdive Workshop oder ein detailliertes Solution Design. Sie sorgen dafür, dass die kommerzielle, organisatorische und betriebliche Grundlage abgestimmt ist und diese Aktivitäten mit klaren Erwartungen sowie einer passenden vertraglichen Basis beginnen können.
Zweck und Umfang
Abschnitt betitelt „Zweck und Umfang“Das Readiness Assessment bewertet, ob die notwendigen Grundlagen für eine Cloud-Migration vorhanden sind. Es umfasst technische, prozessuale, personelle, finanzielle und Governance-Readiness. Die Ergebnisse bestimmen die Tiefe der Discovery, Migrationswellen, Besetzung, Plattformvoraussetzungen und Risikobehandlung.
Eingaben aus den Readiness-Workshops
Abschnitt betitelt „Eingaben aus den Readiness-Workshops“Das STACKIT Cloud Readiness Assessment beginnt mit einem Fragebogen und einer Qualitätsprüfung. Anschließend werden die Nachweise in gemeinsamen Expertenworkshops validiert und technische sowie organisatorische Lücken identifiziert. In der Planungsphase entstehen daraus Entscheidungen zu Zielarchitektur, Migrationsmethode, Proof of Concept, Training und Roadmap.
Übernehmen Sie diese Eingaben in die Migrationsplanung:
- den validierten Fragebogen und dokumentierte Annahmen;
- die Readiness-Scorecard über fünf Dimensionen mit offenen Punkten, Verantwortlichen und Zielterminen;
- Kritikalität und Abhängigkeiten der Workloads sowie erste Hypothesen zur R-Strategie;
- identifizierte Kompetenzlücken und den daraus abgeleiteten Trainingsbedarf;
- freigegebene Voraussetzungen für Plattform, Governance, Budget und Besetzung.
Die fünf Dimensionen auf die Migration anwenden
Abschnitt betitelt „Die fünf Dimensionen auf die Migration anwenden“| Dimension | Frage für die Migrationsplanung | Typische Maßnahme |
|---|---|---|
| Technik | Sind Kontenstruktur, IAM, Netzwerk, Automatisierung, Guardrails und Observability für die geplanten Workloads bereit? | Plattformabhängigkeiten, Proofs of Concept oder Landing-Zone-Arbeiten vor der betroffenen Welle einplanen. |
| Prozesse | Können Teams Onboarding, Änderungen, Wiederherstellung und Ausnahmen einheitlich bearbeiten? | Runbooks, Qualitätsgates, Eskalationswege und Übergabekriterien definieren. |
| Personal | Sind CCoE-, Plattform-, Anwendungs-, Sicherheits- und Betriebsrollen besetzt und befähigt? | Rollenbasierte Lernpfade, Coaching und benannte Verantwortliche vor dem Delivery-Start einplanen. |
| Finanzen | Sind Finanzierung, Kostenzuordnung und Wertbeitrag-Tracking freigegeben? | Wellenumfang mit Business Case, FinOps-Kontrollen und Budget-Gates abstimmen. |
| Governance | Sind Sicherheits-, Compliance-, Datenschutz- und Reporting-Kontrollen freigegeben? | Verbindliche Kontrollen und Nachweise in Designs, Runbooks und Abnahmekriterien der Wellen dokumentieren. |
Migrationsergebnisse
Abschnitt betitelt „Migrationsergebnisse“Überführen Sie jeden offenen Befund in ein Migrationsartefakt, statt ihn als allgemeine Beobachtung weiterzuführen:
- Betroffene Workloads und Wellen dokumentieren.
- Eine verantwortliche Person und einen Zieltermin zuweisen.
- Die erforderlichen Nachweise für den Abschluss definieren.
- Den Befund als Blocker, Maßnahme vor der Welle oder akzeptiertes Risiko kennzeichnen.
- Die Readiness am passenden Design- oder Wellen-Gate erneut prüfen.
Das entstehende Readiness-Backlog fließt in Discovery, den Migrationsplan, Enablement und das Migration Factory Setup ein.
Detaillierte Anleitung zum Assessment
Abschnitt betitelt „Detaillierte Anleitung zum Assessment“Die vollständigen Akzeptanzkriterien, Schwellenwerte, die Scorecard und den formalen Go-/No-Go-Prozess finden Sie hier:
Readiness Assessment in fünf Dimensionen Seite öffnenDesign and Mobilize
Positionieren Sie Design and Mobilize als die Phase mit dem größten inhaltlichen Gewicht: Sie überführt Assess-Signale in einen ausführbaren, factory-fähigen Lieferplan.
Überblick: Diese Phase
Abschnitt betitelt „Überblick: Diese Phase“Design and Mobilize ist die Planungs- und Befähigungsphase zwischen Assess und Migrate. Sie überführt die Ergebnisse aus Assess in umsetzbare Zielbilder, Governance, Migrationsplanung und operative Readiness.
Damit schafft die Phase die Voraussetzungen, um Migration in Wellen kontrolliert, skalierbar und sicher umzusetzen.
Wann Design and Mobilize startet und endet
Abschnitt betitelt „Wann Design and Mobilize startet und endet“Die Phase startet, sobald Assess Scope, Readiness und wirtschaftliche Richtung bestätigt hat.
- Start mit vertiefter Erfassung von Anwendungen, Abhängigkeiten und Restriktionen.
- Ausarbeitung von Zieldesigns, Business Cases und Wellenplanung bei gleichzeitigem Factory-Aufbau.
- Abschluss, sobald die ersten Wellen freigegeben sind und Runbooks, Governance und Teams einsatzbereit sind.
Design and Mobilize ist abgeschlossen, wenn Migrationswellen mit stabilen Eingaben, klaren Verantwortlichkeiten und definierten Kontrollen gestartet werden können.
Warum diese Phase wichtig ist
Abschnitt betitelt „Warum diese Phase wichtig ist“Diese Phase macht aus strategischer Ausrichtung eine belastbare Umsetzungsfähigkeit und verhindert ungeplante oder nicht steuerbare Migrationsläufe.
Architektur-Readiness
Zielbilder und Migrationspfade je Anwendung werden nachvollziehbar definiert.
Factory-Befähigung
Rollen, Prozesse, Tooling und Runbook-Governance stehen vor der Skalierung bereit.
Security by Design
Security- und Compliance-Anforderungen werden früh in Design und Planung verankert.
Hohe Umsetzungsqualität
Wellen werden abhängigkeitsbewusst, realistisch und operativ belastbar geplant.
Module in dieser Phase
Abschnitt betitelt „Module in dieser Phase“- Discovery: Schafft Transparenz zu Anwendungen, Abhängigkeiten und Randbedingungen.
- Migrationsplan: Überführt Strategie in eine umsetzbare Wellenplanung.
- Design: Definiert den Ansatz für die Migration und Zielbilder je Gruppe von Anwendungen.
- Migration Factory Setup: Etabliert Betriebsmodell, Schnittstellen und Vorgehen.
- Business Case: Konsolidiert Aufwand, Nutzen und die Sicht auf Investitionen pro Scope.
- Enablement: Bündelt Governance, Trainings, Lernpfade und Referenz.
- Landing Zone: Implementiert die sichere und skalierbare Basis der Plattform.
- Target Operating Model: Legt Governance, Verantwortlichkeiten und Fähigkeiten für einen stabilen Cloud-Betrieb fest.
- Security und Compliance: Definiert verbindliche Anforderungen für Kontrollen und Nachweise.
Typische Ergebnisse
Abschnitt betitelt „Typische Ergebnisse“Am Ende von Design and Mobilize sollten mindestens folgende Ergebnisse vorliegen:
- Freigegebene Zielbilder: Architektur- und Migrationsentscheidungen pro Workload-Klasse.
- Migrationsplan bereit für Wellen: Sequenzierte, abhängigkeitsbewusste Wellen mit priorisiertem Backlog.
- Etabliertes Factory-Modell: Governance-Taktung, Runbook-Standards und Delivery-Ownership.
- Plattform und Rahmen für Kontrollen: Landing Zone und Security-/Compliance-Leitplanken für die Umsetzung.
Übergang zu Migrate
Abschnitt betitelt „Übergang zu Migrate“Design and Mobilize kann sich mit den ersten Migrationswellen überlappen. Sobald der Zuschnitt der Wellen und Runbooks für die ersten Umsetzungen validiert sind, startet Migrate und die detaillierte Planung wird iterativ für Folgewellen fortgeführt.
Discovery
Gehen Sie hier in die Tiefe: Discovery macht aus der schnellen Bewertung migrationsreife Evidenz zu Workloads, Abhängigkeiten, Randbedingungen und Stakeholdern.
Überblick: Discovery
Abschnitt betitelt „Überblick: Discovery“Discovery ist eines der ersten und wichtigsten Module in der Phase Design and Mobilize. Es verfeinert die Ergebnisse aus Rapid Discovery und liefert die notwendige Tiefe, um Entscheidungen zur Architektur und die Reihenfolge der Migration belastbar zu planen.
Das primäre Ziel ist ein realistisches, auf Fakten gestütztes Verständnis der bestehenden IT-Landschaft, der Business-Prioritäten und der organisatorischen Bereitschaft, bevor Zielbild und Migrationsplan im Detail festgelegt werden.
Zentrale Ziele
Abschnitt betitelt „Zentrale Ziele“Vollständige Basis
Eine belastbare Sicht auf Anwendungen und Infrastruktur schaffen, die über reine Mengen hinausgeht.
Transparente Abhängigkeiten
Technische und prozessuale Abhängigkeiten identifizieren, um versteckte Migrationsblocker zu vermeiden.
Business-Abgleich
Technische Erkenntnisse mit Kritikalität, Zeitrahmen und Risikoprofil des Business verknüpfen.
Planungsreife
Eine entscheidungsreife Grundlage für Zielbild und Migrationswellen erstellen.
Was Discovery typischerweise erfasst
Abschnitt betitelt „Was Discovery typischerweise erfasst“Inventarisierung
Vollständige Erfassung von Servern, virtuellen Maschinen, Datenbanken, Middleware und Anwendungen.
Abhängigkeitsanalyse
Abbildung von Kommunikationspfaden und Laufzeitabhängigkeiten zwischen Systemen und Anwendungen.
Ressourcennutzung
Analyse von CPU-, RAM-, Storage- und I/O-Verhalten über einen repräsentativen Zeitraum.
Betriebskontext
Erhebung von Anforderungen zu Backup, Patch, SLA, Compliance und betrieblichen Randbedingungen.
Input der Application Owner
Strukturierte Fragebögen und Interviews zur Validierung von Annahmen und zum Schließen von Datenlücken.
Typisches Vorgehen
Abschnitt betitelt „Typisches Vorgehen“In der Praxis wird Discovery häufig gemeinsam mit STACKIT Partnern durchgeführt. Partner nutzen dabei meist eigene Tool-Landschaften, um technische Daten zu sammeln, zu normalisieren und in einer zentralen Sammlung zu konsolidieren.
Häufig werden aus diesen Tools heraus auch gezielte Rückfragen an Application Owner gestellt, um technische Befunde um Business und Betrieb zu ergänzen.
Dieses kombinierte Modell erhöht Geschwindigkeit und Konsistenz und verankert Stakeholder-Validierung direkt im Prozess.
Zwei Evidence-Streams: technisch vs. human-driven
Abschnitt betitelt „Zwei Evidence-Streams: technisch vs. human-driven“Discovery kombiniert bewusst zwei sich ergänzende Evidence-Streams:
- Technisch ermittelte Evidenz: Tooling-basierte Befunde aus Inventar-Exporten und Abhängigkeits-Signalen. Dieser Stream liefert Skalierbarkeit, Konsistenz und Wiederholbarkeit.
- Application-Owner-Anreicherung (human-driven): Validierte Angaben zu Business-Kritikalität, Lifecycle-Absicht, Release-Restriktionen und betrieblicher Realität aus Interviews und Fragebögen.
Keiner der beiden Streams ist alleine ausreichend. Technische Evidenz ohne Owner-Kontext kann kritische Workloads falsch einordnen. Human-Input ohne technische Grundlage kann Kopplungen und Kapazitätsrisiken verdecken. Die Qualität von Discovery entsteht aus der Zusammenführung beider Streams in eine belastbare Basis für Entscheidungen.
Discovery-Prozess auf einen Blick
Abschnitt betitelt „Discovery-Prozess auf einen Blick“Die folgende Darstellung zeigt, wie Discovery technische und menschliche Eingaben in entscheidungsreife Ergebnisse für die nachgelagerten Module überführt.
Typische Analyse-Muster im Discovery-Tooling
Abschnitt betitelt „Typische Analyse-Muster im Discovery-Tooling“Im Discovery werden typischerweise die folgenden Analyse-Muster angewendet:
- Daten normalisieren: Heterogene Exporte in ein konsistentes, auf Anwendungen ausgerichtetes Modell überführen.
- Abhängigkeiten abbilden: Kommunikation, Datenaustausch und Kopplungen erkennen.
- Kritikalitäts- und Risiko-Bewertung: Business-Impact, Ausfall-Domänen und Compliance-Exposition bewerten.
- Analyse der Nutzung: Daten zu CPU, RAM und Storage für Right-Sizing und die Planung der Zielumgebung belastbar ableiten.
- Segmentierung: Anwendungen nach Reifegrad, Restriktionen und Strategie-Fit gruppieren.
- Wellen-Simulation: Move Groups und Optionen für die Reihenfolge unter Abhängigkeitsrestriktionen modellieren.
- Gap- und Annahmen-Tracking: Offene Punkte transparent mit einer Einschätzung führen.
Diese Analysen bilden die technische Grundlage. Der human-driven Stream validiert, priorisiert und ordnet diese Befunde für umsetzbare Migrationsentscheidungen ein.
KI-gestützte Discovery-Assets
Abschnitt betitelt „KI-gestützte Discovery-Assets“KI-gestützte Discovery-Assets können Workload-Eingaben, Service-Mapping, Readiness-Befunde und R-Strategie-Signale strukturieren, bevor Architekten die Discovery-Baseline validieren.
Asset-Titel
Framework
Asset-Typ
Migration
Software
Methodik in der Praxis
Abschnitt betitelt „Methodik in der Praxis“- Quelldaten aus CMDB, Hypervisor, Cloud-Inventaren, Monitoring und Exportdateien zusammenführen.
- Datensätze normalisieren und in ein gemeinsames, applikationsorientiertes Modell überführen.
- Abhängigkeiten erfassen und validieren (Netzwerk, Daten, Identität, Integrationen und Batch-Flows).
- Erkenntnisse mit Input der Owner zu Kritikalität, Lifecycle, Restriktionen und Migrationsfähigkeit anreichern.
- Workloads für Migrationsstrategie-Optionen und Wellenplanung klassifizieren.
- Ergebnisse mit Architektur, Security, Plattform und Business-Stakeholdern abstimmen.
Warum Discovery kritisch ist
Abschnitt betitelt „Warum Discovery kritisch ist“- Risiko der Migration reduzieren: Frühe Sichtbarkeit auf verdeckte Abhängigkeiten senkt Ausfall- und Rollback-Risiken.
- Planung der Wellen verbessern: Workloads lassen sich realistisch nach Kopplung, Kritikalität und Reifegrad gruppieren.
- Falsche Dimensionierung vermeiden: Gemessene Nutzung ersetzt Annahmen in der Zielkapazitätsplanung.
- Governance absichern: Security-, Compliance- und Betriebsanforderungen werden vor der Umsetzung adressiert.
- Stakeholder-Buy-in stärken: Gemeinsame Fakten verbessern die Entscheidungsqualität zwischen Business und IT.
Relevanz für nachgelagerte Module
Abschnitt betitelt „Relevanz für nachgelagerte Module“Die Ergebnisse aus Discovery werden direkt in den nachgelagerten Modulen wiederverwendet:
Design
Nutzt Abhängigkeits-, Kapazitäts- und Risikosignale zur Ausgestaltung tragfähiger Zielarchitekturen.
Security und Compliance
Nutzt Datenklassifizierung und Control-Gaps zur Priorisierung von Sicherheitsanforderungen.
Landing Zone
Nutzt Plattform- und Governance-Restriktionen für grundlegende Setup-Entscheidungen.
Migrationsplan
Nutzt Move Groups, Kritikalität und Sequenzrestriktionen für realistische Wellenplanung.
Operating Model und Business Case
Nutzt Ownership-, Prozess- und Value/Risk-Signale für Rollenbild und Investitionspriorisierung.
Ergebnisse aus Discovery
Abschnitt betitelt „Ergebnisse aus Discovery“Mindestens folgende Ergebnisse sollten aus Discovery vorliegen:
- Konsolidierte Applikations-Basis: Inventar nach Domäne, Umgebung und Kritikalität.
- Abhängigkeitskarte: Verifizierte Upstream-/Downstream-Beziehungen und wichtige Integrationen.
- Profil der Nutzung: Belastbare Daten zur Auslastung und Sizing-Annahmen.
- Constraint-Register: Security-, Compliance-, Lizenz- und Einschränkungen im Betrieb.
- Migrationsreife-Sicht: Priorisierte Kandidaten, Risiken und Empfehlungen für die Reihenfolge.
Diese Ergebnisse sind unverzichtbare Voraussetzungen für das nachfolgende detaillierte Design und einen realistischen Migrationsplan.
Evidenz und Muster validieren
Überblick: Discovery
Abschnitt betitelt „Überblick: Discovery“Discovery ist eines der ersten und wichtigsten Module in der Phase Design and Mobilize. Es verfeinert die Ergebnisse aus Rapid Discovery und liefert die notwendige Tiefe, um Entscheidungen zur Architektur und die Reihenfolge der Migration belastbar zu planen.
Das primäre Ziel ist ein realistisches, auf Fakten gestütztes Verständnis der bestehenden IT-Landschaft, der Business-Prioritäten und der organisatorischen Bereitschaft, bevor Zielbild und Migrationsplan im Detail festgelegt werden.
Zentrale Ziele
Abschnitt betitelt „Zentrale Ziele“Vollständige Basis
Eine belastbare Sicht auf Anwendungen und Infrastruktur schaffen, die über reine Mengen hinausgeht.
Transparente Abhängigkeiten
Technische und prozessuale Abhängigkeiten identifizieren, um versteckte Migrationsblocker zu vermeiden.
Business-Abgleich
Technische Erkenntnisse mit Kritikalität, Zeitrahmen und Risikoprofil des Business verknüpfen.
Planungsreife
Eine entscheidungsreife Grundlage für Zielbild und Migrationswellen erstellen.
Was Discovery typischerweise erfasst
Abschnitt betitelt „Was Discovery typischerweise erfasst“Inventarisierung
Vollständige Erfassung von Servern, virtuellen Maschinen, Datenbanken, Middleware und Anwendungen.
Abhängigkeitsanalyse
Abbildung von Kommunikationspfaden und Laufzeitabhängigkeiten zwischen Systemen und Anwendungen.
Ressourcennutzung
Analyse von CPU-, RAM-, Storage- und I/O-Verhalten über einen repräsentativen Zeitraum.
Betriebskontext
Erhebung von Anforderungen zu Backup, Patch, SLA, Compliance und betrieblichen Randbedingungen.
Input der Application Owner
Strukturierte Fragebögen und Interviews zur Validierung von Annahmen und zum Schließen von Datenlücken.
Typisches Vorgehen
Abschnitt betitelt „Typisches Vorgehen“In der Praxis wird Discovery häufig gemeinsam mit STACKIT Partnern durchgeführt. Partner nutzen dabei meist eigene Tool-Landschaften, um technische Daten zu sammeln, zu normalisieren und in einer zentralen Sammlung zu konsolidieren.
Häufig werden aus diesen Tools heraus auch gezielte Rückfragen an Application Owner gestellt, um technische Befunde um Business und Betrieb zu ergänzen.
Dieses kombinierte Modell erhöht Geschwindigkeit und Konsistenz und verankert Stakeholder-Validierung direkt im Prozess.
Zwei Evidence-Streams: technisch vs. human-driven
Abschnitt betitelt „Zwei Evidence-Streams: technisch vs. human-driven“Discovery kombiniert bewusst zwei sich ergänzende Evidence-Streams:
- Technisch ermittelte Evidenz: Tooling-basierte Befunde aus Inventar-Exporten und Abhängigkeits-Signalen. Dieser Stream liefert Skalierbarkeit, Konsistenz und Wiederholbarkeit.
- Application-Owner-Anreicherung (human-driven): Validierte Angaben zu Business-Kritikalität, Lifecycle-Absicht, Release-Restriktionen und betrieblicher Realität aus Interviews und Fragebögen.
Keiner der beiden Streams ist alleine ausreichend. Technische Evidenz ohne Owner-Kontext kann kritische Workloads falsch einordnen. Human-Input ohne technische Grundlage kann Kopplungen und Kapazitätsrisiken verdecken. Die Qualität von Discovery entsteht aus der Zusammenführung beider Streams in eine belastbare Basis für Entscheidungen.
Discovery-Prozess auf einen Blick
Abschnitt betitelt „Discovery-Prozess auf einen Blick“Die folgende Darstellung zeigt, wie Discovery technische und menschliche Eingaben in entscheidungsreife Ergebnisse für die nachgelagerten Module überführt.
Typische Analyse-Muster im Discovery-Tooling
Abschnitt betitelt „Typische Analyse-Muster im Discovery-Tooling“Im Discovery werden typischerweise die folgenden Analyse-Muster angewendet:
- Daten normalisieren: Heterogene Exporte in ein konsistentes, auf Anwendungen ausgerichtetes Modell überführen.
- Abhängigkeiten abbilden: Kommunikation, Datenaustausch und Kopplungen erkennen.
- Kritikalitäts- und Risiko-Bewertung: Business-Impact, Ausfall-Domänen und Compliance-Exposition bewerten.
- Analyse der Nutzung: Daten zu CPU, RAM und Storage für Right-Sizing und die Planung der Zielumgebung belastbar ableiten.
- Segmentierung: Anwendungen nach Reifegrad, Restriktionen und Strategie-Fit gruppieren.
- Wellen-Simulation: Move Groups und Optionen für die Reihenfolge unter Abhängigkeitsrestriktionen modellieren.
- Gap- und Annahmen-Tracking: Offene Punkte transparent mit einer Einschätzung führen.
Diese Analysen bilden die technische Grundlage. Der human-driven Stream validiert, priorisiert und ordnet diese Befunde für umsetzbare Migrationsentscheidungen ein.
KI-gestützte Discovery-Assets
Abschnitt betitelt „KI-gestützte Discovery-Assets“KI-gestützte Discovery-Assets können Workload-Eingaben, Service-Mapping, Readiness-Befunde und R-Strategie-Signale strukturieren, bevor Architekten die Discovery-Baseline validieren.
Asset-Titel
Framework
Asset-Typ
Migration
Software
Methodik in der Praxis
Abschnitt betitelt „Methodik in der Praxis“- Quelldaten aus CMDB, Hypervisor, Cloud-Inventaren, Monitoring und Exportdateien zusammenführen.
- Datensätze normalisieren und in ein gemeinsames, applikationsorientiertes Modell überführen.
- Abhängigkeiten erfassen und validieren (Netzwerk, Daten, Identität, Integrationen und Batch-Flows).
- Erkenntnisse mit Input der Owner zu Kritikalität, Lifecycle, Restriktionen und Migrationsfähigkeit anreichern.
- Workloads für Migrationsstrategie-Optionen und Wellenplanung klassifizieren.
- Ergebnisse mit Architektur, Security, Plattform und Business-Stakeholdern abstimmen.
Warum Discovery kritisch ist
Abschnitt betitelt „Warum Discovery kritisch ist“- Risiko der Migration reduzieren: Frühe Sichtbarkeit auf verdeckte Abhängigkeiten senkt Ausfall- und Rollback-Risiken.
- Planung der Wellen verbessern: Workloads lassen sich realistisch nach Kopplung, Kritikalität und Reifegrad gruppieren.
- Falsche Dimensionierung vermeiden: Gemessene Nutzung ersetzt Annahmen in der Zielkapazitätsplanung.
- Governance absichern: Security-, Compliance- und Betriebsanforderungen werden vor der Umsetzung adressiert.
- Stakeholder-Buy-in stärken: Gemeinsame Fakten verbessern die Entscheidungsqualität zwischen Business und IT.
Relevanz für nachgelagerte Module
Abschnitt betitelt „Relevanz für nachgelagerte Module“Die Ergebnisse aus Discovery werden direkt in den nachgelagerten Modulen wiederverwendet:
Design
Nutzt Abhängigkeits-, Kapazitäts- und Risikosignale zur Ausgestaltung tragfähiger Zielarchitekturen.
Security und Compliance
Nutzt Datenklassifizierung und Control-Gaps zur Priorisierung von Sicherheitsanforderungen.
Landing Zone
Nutzt Plattform- und Governance-Restriktionen für grundlegende Setup-Entscheidungen.
Migrationsplan
Nutzt Move Groups, Kritikalität und Sequenzrestriktionen für realistische Wellenplanung.
Operating Model und Business Case
Nutzt Ownership-, Prozess- und Value/Risk-Signale für Rollenbild und Investitionspriorisierung.
Ergebnisse aus Discovery
Abschnitt betitelt „Ergebnisse aus Discovery“Mindestens folgende Ergebnisse sollten aus Discovery vorliegen:
- Konsolidierte Applikations-Basis: Inventar nach Domäne, Umgebung und Kritikalität.
- Abhängigkeitskarte: Verifizierte Upstream-/Downstream-Beziehungen und wichtige Integrationen.
- Profil der Nutzung: Belastbare Daten zur Auslastung und Sizing-Annahmen.
- Constraint-Register: Security-, Compliance-, Lizenz- und Einschränkungen im Betrieb.
- Migrationsreife-Sicht: Priorisierte Kandidaten, Risiken und Empfehlungen für die Reihenfolge.
Diese Ergebnisse sind unverzichtbare Voraussetzungen für das nachfolgende detaillierte Design und einen realistischen Migrationsplan.
Überblick: Discovery
Abschnitt betitelt „Überblick: Discovery“Discovery ist eines der ersten und wichtigsten Module in der Phase Design and Mobilize. Es verfeinert die Ergebnisse aus Rapid Discovery und liefert die notwendige Tiefe, um Entscheidungen zur Architektur und die Reihenfolge der Migration belastbar zu planen.
Das primäre Ziel ist ein realistisches, auf Fakten gestütztes Verständnis der bestehenden IT-Landschaft, der Business-Prioritäten und der organisatorischen Bereitschaft, bevor Zielbild und Migrationsplan im Detail festgelegt werden.
Zentrale Ziele
Abschnitt betitelt „Zentrale Ziele“Vollständige Basis
Eine belastbare Sicht auf Anwendungen und Infrastruktur schaffen, die über reine Mengen hinausgeht.
Transparente Abhängigkeiten
Technische und prozessuale Abhängigkeiten identifizieren, um versteckte Migrationsblocker zu vermeiden.
Business-Abgleich
Technische Erkenntnisse mit Kritikalität, Zeitrahmen und Risikoprofil des Business verknüpfen.
Planungsreife
Eine entscheidungsreife Grundlage für Zielbild und Migrationswellen erstellen.
Was Discovery typischerweise erfasst
Abschnitt betitelt „Was Discovery typischerweise erfasst“Inventarisierung
Vollständige Erfassung von Servern, virtuellen Maschinen, Datenbanken, Middleware und Anwendungen.
Abhängigkeitsanalyse
Abbildung von Kommunikationspfaden und Laufzeitabhängigkeiten zwischen Systemen und Anwendungen.
Ressourcennutzung
Analyse von CPU-, RAM-, Storage- und I/O-Verhalten über einen repräsentativen Zeitraum.
Betriebskontext
Erhebung von Anforderungen zu Backup, Patch, SLA, Compliance und betrieblichen Randbedingungen.
Input der Application Owner
Strukturierte Fragebögen und Interviews zur Validierung von Annahmen und zum Schließen von Datenlücken.
Typisches Vorgehen
Abschnitt betitelt „Typisches Vorgehen“In der Praxis wird Discovery häufig gemeinsam mit STACKIT Partnern durchgeführt. Partner nutzen dabei meist eigene Tool-Landschaften, um technische Daten zu sammeln, zu normalisieren und in einer zentralen Sammlung zu konsolidieren.
Häufig werden aus diesen Tools heraus auch gezielte Rückfragen an Application Owner gestellt, um technische Befunde um Business und Betrieb zu ergänzen.
Dieses kombinierte Modell erhöht Geschwindigkeit und Konsistenz und verankert Stakeholder-Validierung direkt im Prozess.
Zwei Evidence-Streams: technisch vs. human-driven
Abschnitt betitelt „Zwei Evidence-Streams: technisch vs. human-driven“Discovery kombiniert bewusst zwei sich ergänzende Evidence-Streams:
- Technisch ermittelte Evidenz: Tooling-basierte Befunde aus Inventar-Exporten und Abhängigkeits-Signalen. Dieser Stream liefert Skalierbarkeit, Konsistenz und Wiederholbarkeit.
- Application-Owner-Anreicherung (human-driven): Validierte Angaben zu Business-Kritikalität, Lifecycle-Absicht, Release-Restriktionen und betrieblicher Realität aus Interviews und Fragebögen.
Keiner der beiden Streams ist alleine ausreichend. Technische Evidenz ohne Owner-Kontext kann kritische Workloads falsch einordnen. Human-Input ohne technische Grundlage kann Kopplungen und Kapazitätsrisiken verdecken. Die Qualität von Discovery entsteht aus der Zusammenführung beider Streams in eine belastbare Basis für Entscheidungen.
Discovery-Prozess auf einen Blick
Abschnitt betitelt „Discovery-Prozess auf einen Blick“Die folgende Darstellung zeigt, wie Discovery technische und menschliche Eingaben in entscheidungsreife Ergebnisse für die nachgelagerten Module überführt.
Typische Analyse-Muster im Discovery-Tooling
Abschnitt betitelt „Typische Analyse-Muster im Discovery-Tooling“Im Discovery werden typischerweise die folgenden Analyse-Muster angewendet:
- Daten normalisieren: Heterogene Exporte in ein konsistentes, auf Anwendungen ausgerichtetes Modell überführen.
- Abhängigkeiten abbilden: Kommunikation, Datenaustausch und Kopplungen erkennen.
- Kritikalitäts- und Risiko-Bewertung: Business-Impact, Ausfall-Domänen und Compliance-Exposition bewerten.
- Analyse der Nutzung: Daten zu CPU, RAM und Storage für Right-Sizing und die Planung der Zielumgebung belastbar ableiten.
- Segmentierung: Anwendungen nach Reifegrad, Restriktionen und Strategie-Fit gruppieren.
- Wellen-Simulation: Move Groups und Optionen für die Reihenfolge unter Abhängigkeitsrestriktionen modellieren.
- Gap- und Annahmen-Tracking: Offene Punkte transparent mit einer Einschätzung führen.
Diese Analysen bilden die technische Grundlage. Der human-driven Stream validiert, priorisiert und ordnet diese Befunde für umsetzbare Migrationsentscheidungen ein.
KI-gestützte Discovery-Assets
Abschnitt betitelt „KI-gestützte Discovery-Assets“KI-gestützte Discovery-Assets können Workload-Eingaben, Service-Mapping, Readiness-Befunde und R-Strategie-Signale strukturieren, bevor Architekten die Discovery-Baseline validieren.
Asset-Titel
Framework
Asset-Typ
Migration
Software
Methodik in der Praxis
Abschnitt betitelt „Methodik in der Praxis“- Quelldaten aus CMDB, Hypervisor, Cloud-Inventaren, Monitoring und Exportdateien zusammenführen.
- Datensätze normalisieren und in ein gemeinsames, applikationsorientiertes Modell überführen.
- Abhängigkeiten erfassen und validieren (Netzwerk, Daten, Identität, Integrationen und Batch-Flows).
- Erkenntnisse mit Input der Owner zu Kritikalität, Lifecycle, Restriktionen und Migrationsfähigkeit anreichern.
- Workloads für Migrationsstrategie-Optionen und Wellenplanung klassifizieren.
- Ergebnisse mit Architektur, Security, Plattform und Business-Stakeholdern abstimmen.
Warum Discovery kritisch ist
Abschnitt betitelt „Warum Discovery kritisch ist“- Risiko der Migration reduzieren: Frühe Sichtbarkeit auf verdeckte Abhängigkeiten senkt Ausfall- und Rollback-Risiken.
- Planung der Wellen verbessern: Workloads lassen sich realistisch nach Kopplung, Kritikalität und Reifegrad gruppieren.
- Falsche Dimensionierung vermeiden: Gemessene Nutzung ersetzt Annahmen in der Zielkapazitätsplanung.
- Governance absichern: Security-, Compliance- und Betriebsanforderungen werden vor der Umsetzung adressiert.
- Stakeholder-Buy-in stärken: Gemeinsame Fakten verbessern die Entscheidungsqualität zwischen Business und IT.
Relevanz für nachgelagerte Module
Abschnitt betitelt „Relevanz für nachgelagerte Module“Die Ergebnisse aus Discovery werden direkt in den nachgelagerten Modulen wiederverwendet:
Design
Nutzt Abhängigkeits-, Kapazitäts- und Risikosignale zur Ausgestaltung tragfähiger Zielarchitekturen.
Security und Compliance
Nutzt Datenklassifizierung und Control-Gaps zur Priorisierung von Sicherheitsanforderungen.
Landing Zone
Nutzt Plattform- und Governance-Restriktionen für grundlegende Setup-Entscheidungen.
Migrationsplan
Nutzt Move Groups, Kritikalität und Sequenzrestriktionen für realistische Wellenplanung.
Operating Model und Business Case
Nutzt Ownership-, Prozess- und Value/Risk-Signale für Rollenbild und Investitionspriorisierung.
Ergebnisse aus Discovery
Abschnitt betitelt „Ergebnisse aus Discovery“Mindestens folgende Ergebnisse sollten aus Discovery vorliegen:
- Konsolidierte Applikations-Basis: Inventar nach Domäne, Umgebung und Kritikalität.
- Abhängigkeitskarte: Verifizierte Upstream-/Downstream-Beziehungen und wichtige Integrationen.
- Profil der Nutzung: Belastbare Daten zur Auslastung und Sizing-Annahmen.
- Constraint-Register: Security-, Compliance-, Lizenz- und Einschränkungen im Betrieb.
- Migrationsreife-Sicht: Priorisierte Kandidaten, Risiken und Empfehlungen für die Reihenfolge.
Diese Ergebnisse sind unverzichtbare Voraussetzungen für das nachfolgende detaillierte Design und einen realistischen Migrationsplan.
Design
Gehen Sie hier in die Tiefe: Nutzen Sie die R-Strategie-Grafik als Ankerpunkt, um zu erklären, wie der Migrationsansatz je Anwendung gewählt und begründet wird.
Ergebnis
Abschnitt betitelt „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.
Zielbild je Anwendung
Definiert Zielarchitektur, Service-Auswahl, Integrationsansatz und Randbedingungen im STACKIT Kontext.
R-Strategie-Entscheidungsnachweis
Dokumentiert die gewählte Migrationsstrategie und begründet, warum Alternativen verworfen wurden.
Factory-fähiges Migrations-Runbook
Liefert eine Schritt-für-Schritt-Anleitung mit Rückfallpfad und Validierungspunkten.
Handover-Paket
Übergibt alle benötigten Ergebnisse an Migration Factory Setup, Landing Zone und Migrationsplan.
Abgrenzung
Abschnitt betitelt „Abgrenzung“Die Module sind stark verzahnt, haben aber unterschiedliche Aufgaben:
Design (dieses Modul)
Entscheidet pro Anwendung Zielbild und Migrationsstrategie und erstellt ausführbare Runbooks.
Migration Factory Setup
Ermöglicht die Umsetzung durch Auswahl und Vorbereitung des passenden Factory-Modells, Partners und Werkzeugkastens.
Landing Zone
Liefert die Plattform-Grundlage und Governance Controls, die im Zielbild berücksichtigt werden müssen.
Migrationsplan
Überführt fertige Designs in realistische Wellen, Reihenfolgen, Abhängigkeiten und Meilensteine.
Methode
Abschnitt betitelt „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
Abschnitt betitelt „Entscheidungskriterien je R-Strategie“- 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: Sinnvoll bei geringer Veränderungstoleranz und engem Zeitrahmen, wenn Geschwindigkeit vor sofortiger Modernisierung steht.
- Replatform: Sinnvoll, wenn begrenzte Anpassungen über die STACKIT Plattform klare Vorteile in Betrieb, Skalierung oder Kosten bringen.
- 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: Sinnvoll für strategische Anwendungen, wenn eine cloud-native Überarbeitung klaren Mehrwert in Agilität, Resilienz oder Kosten schafft.
- Retain: Retain bei zeitlichen, technischen oder Governance-Hürden in der aktuellen Welle.
- Retire: Retire bei fehlendem Geschäftswert im Verhältnis zum Betriebsaufwand.
Zentrale Schritte im Diagramm
Abschnitt betitelt „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
Abschnitt betitelt „1. Discovery Input“Ausgangslage und Randbedingungen absichern: fachlicher Kontext, Workload-Inventar, Abhängigkeiten und Restriktionen für die folgenden Design-Entscheidungen.
2. Bewerten und priorisieren
Abschnitt betitelt „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.
3. Determine migration path
Abschnitt betitelt „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).
4. Validation
Abschnitt betitelt „4. Validation“Alle Design-Pfade in einem gemeinsamen Qualitäts-Gate betrachten. Annahmen zur Architektur, Security/Compliance, Runbook-Qualität und Betriebsreife validieren.
5. Transition
Abschnitt betitelt „5. Transition“Die kontrollierte Übergabe in den Migrationslauf vorbereiten: Release-Reife, Wellen-Fit, Koordinationsfenster und klare Übergabe der Verantwortung.
6. Production
Abschnitt betitelt „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.
Zielbild
Abschnitt betitelt „Zielbild“- Scope und Baseline aus Discovery bestätigen (Abhängigkeiten, Nutzung, Kritikalität, Restriktionen).
- Fachliche und technische Designziele festlegen, inklusive Verfügbarkeit, Security, Compliance und Performance.
- R-Strategie-Optionen gegen klare Kriterien bewerten und die gewählte Strategie begründet dokumentieren.
- Zielbild auf STACKIT Produkte und Plattform-Fähigkeiten abbilden, inklusive Netzwerk, Identität, Daten und Betrieb.
- Migrationsvorgehen spezifizieren (Cutover-Ansatz, Datenumzug, Integrationswechsel, Rückfallstrategie).
- Ausführbares Runbook für die Factory mit Aufgaben, Qualitätschecks und Abnahmekriterien erstellen.
- Design-Annahmen mit Architektur, Security, Plattform und Business-Ownern validieren.
- Freigegebenes Designpaket an Migration Factory Setup und Migrationsplan übergeben.
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.
Nutzen Sie die dedizierte Pattern-Seite, um vor Auswahl des Migrations-Runbooks ein klares Zielbild zu definieren.
Workload-Use-Case-Sicht für Migrationsvarianten
Abschnitt betitelt „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.
KI-gestützte Design-Assets
Abschnitt betitelt „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.
Asset-Titel
Framework
Asset-Typ
Migration
Blueprint
Migration
Anleitung
Migration
Software
Migration
Software
Migration
Software
Migration
Runbook
Migration
Blueprint
Migration
Runbook
Migration
Blueprint
Migration
Blueprint
Migration
Blueprint
Migration
Software
Migration
Service
Migration
Anleitung
Runbook-Assets
Abschnitt betitelt „Runbook-Assets“Asset-Titel
Framework
Asset-Typ
Migration
Runbook
Migration
Runbook
Migration
Runbook
Wirkung
Abschnitt betitelt „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.
STACKIT Serviceportfolio erkunden
Allgemein
STACKIT Serviceportfolio-Karte
STACKIT
Architecture portfolio reference services architecture
STACKIT
Der souveräne europäische Cloud-Anbieter hinter dem Framework, mit IaaS und PaaS aus deutschen und österreichischen Rechenzentren und voller Unabhängigkeit.
Erkunden Sie mit dieser interaktiven Karte das STACKIT Serviceportfolio. Wählen Sie ein Produkt oder Zugriffstool aus, um die aktuelle Dokumentation oder das zugehörige Cloud-Framework-Asset zu öffnen.
Interaktives Serviceportfolio
Abschnitt betitelt „Interaktives Serviceportfolio“Nutzungshinweise
Abschnitt betitelt „Nutzungshinweise“Die Karte dient als Navigationshilfe und stellt keine Lifecycle-Zusage dar. Prüfen Sie auf den verlinkten Produktseiten die aktuellen Regionen, Verfügbarkeiten, Service Levels und Release-Status.
Gesamte STACKIT Produktdokumentation durchsuchen Dokumentation öffnenWarum diese Seite existiert
Abschnitt betitelt „Warum diese Seite existiert“Die R-Strategie erklärt, wie migriert wird. Diese Seite ergänzt die Workload-Sicht und klärt, was migriert wird. Sie ist bewusst lösungsneutral und fokussiert auf transparente Kategorisierung, Machbarkeitsgrenzen und Entscheidungskontext.
Use-Case-Kategorien im Scope
Abschnitt betitelt „Use-Case-Kategorien im Scope“Application-Runtime-Migration
Migration kompletter Anwendungs-Runtimes über VM- und Plattform-Ziele hinweg, inklusive Abhängigkeiten, Cutover-Verhalten und Betriebs-Handover.
Container-Plattform-Migration
Migration zwischen Kubernetes-Plattformen mit getrennter Behandlung von stateless und stateful Workload-Profilen.
Datenmigration
Migration großer Dateibestände, Datenbanken und Datenplattform-Workloads mit expliziten Konsistenz-, Performance- und Integritätsgrenzen.
Identity- und Access-Migration
Migration von IAM-Grundlagen wie SSO, Föderation, Rollen, Service-Accounts und Berechtigungsmodellen.
Netzwerk- und Konnektivitäts-Migration
Migration von Routing, DNS, Firewall-Regeln, Segmentierung, privater Konnektivität und umgebungsübergreifenden Kommunikationspfaden.
Integrations- und API-Migration
Migration von API-Verträgen, Messaging, Eventing und Integrations-Endpunkten über Quell- und Zielumgebungen hinweg.
Migration von Security- und Compliance-Controls
Migration von Controls, Nachweisketten, Schlüsselmaterial und Audit-Anforderungen für regulierte Produktionsreife.
Operations- und Observability-Migration
Migration von Monitoring, Alerting, Logging, Incident-Workflows und Service-Level-Baselines für den Betrieb.
Delivery- und Resilienz-Migration
Migration von CI/CD-Pipelines, Automatisierungs-Controls, Backup-Ketten und Disaster-Recovery-Fähigkeiten.
Wie sich die aktuellen Kategorien in dieses Modell einfügen
Abschnitt betitelt „Wie sich die aktuellen Kategorien in dieses Modell einfügen“- Application-Stack-Migration ist Teil der Application-Runtime-Migration.
- Migration großer Dateibestände ist Teil der Datenmigration.
- Kubernetes-zu-Kubernetes-Migration ist Teil der Container-Plattform-Migration.
Migrations-Use-Cases von AWS und Azure zu STACKIT
Abschnitt betitelt „Migrations-Use-Cases von AWS und Azure zu STACKIT“STACKIT unterstützt Migrationspfade von AWS und Azure über Anwendungs-Runtimes, Daten, Netzwerk, Identität, Betrieb und Delivery hinweg. Der Zielpfad wird je Workload anhand von Architektur, Datenprofil, Verfügbarkeitsanforderungen und Betriebsmodell ausgewählt.
| Use Case | Migrationsmöglichkeit zu STACKIT |
|---|---|
| Landing-Zone-Migration | AWS-Account- und Azure-Subscription-Strukturen, Netzwerksegmentierung, Identity- und Access-Controls, Security-Policies, Logging, Monitoring und Governance-Leitplanken werden vor Beginn der Applikationswellen auf eine STACKIT Landing Zone abgebildet. Der STACKIT Landing Zone Accelerator liefert eine wiederverwendbare, automatisierte Grundlage, um diese Controls konsistent und skalierbar umzusetzen. |
| VM-basierte Anwendungen | AWS-EC2- und Azure-VM-Workloads können zu STACKIT Compute Engine migriert werden, einschließlich Betriebssystemen, Middleware, Anwendungen, Konfigurationen und angebundenen Daten. |
| VM-Landschaften mit hohen Verfügbarkeitsanforderungen | Die toolgestützte Relocate-Migration unterstützt kontinuierliche Replikation, kontrollierte Validierung und geplanten Cutover für große VM-Landschaften und wiederholbare Migrationswellen. |
| Container- und Kubernetes-Workloads | AWS EKS, Azure AKS und selbstbetriebene Kubernetes-Cluster können zu STACKIT Kubernetes Engine migriert werden. Stateless Anwendungen werden deklarativ neu ausgerollt; stateful Anwendungen nutzen Backup und Restore oder Datenreplikation mit schrittweiser Traffic-Verlagerung. |
| PaaS- und Web-Anwendungen | Anwendungen mit gängigen Runtimes wie Java, Node.js, Python oder Ruby können auf STACKIT Cloud Foundry betrieben werden, wenn sie zum Plattformmodell passen. |
| Datenbanken und Datenplattformen | Selbstbetriebene und cloudbasierte Datenbanken können zu STACKIT Managed Database Services oder zunächst auf Compute-Engine-Instanzen migriert werden; die Umsetzung erfolgt über Export/Import, Replikation und kontrollierte Cutover-Verfahren. |
| Object Storage und Dateispeicher | AWS S3 und Azure Blob Storage können zu STACKIT Object Storage migriert werden. AWS EFS, Azure Files und NFS-basierte Dateisysteme können über Erstkopie, Delta-Synchronisation und finalen Konsistenz-Cutover nach STACKIT File Storage migriert werden. |
| Identity und Access Management | AWS IAM, Azure RBAC und Microsoft-Entra-basierte Zugriffsmodelle können auf STACKIT Rollen, Berechtigungen, Service Accounts und Föderation abgebildet werden. |
| Netzwerk, DNS und Konnektivität | AWS VPCs und Azure VNets können auf STACKIT Network Areas, Routing, Security Groups, Load Balancing, DNS und Site-to-Site-VPN-Konnektivität abgebildet werden. |
| Integration, Messaging und APIs | APIs, Integrationsendpunkte und Messaging-Workloads können zusammen mit ihren Verträgen, Sicherheitsmechanismen und Umschaltreihenfolgen migriert werden. STACKIT RabbitMQ unterstützt AMQP- und RabbitMQ-basierte Muster. |
| Security, Compliance und Betrieb | Secrets, Schlüssel, Audit-Anforderungen, Logging, Monitoring, Alerting, Backup und Betriebsprozesse werden vor dem Go-live als Teil der Zielumgebung aufgebaut. |
| CI/CD und Delivery | Deployment-Pipelines, Infrastrukturautomatisierung und Versionsverwaltung können auf STACKIT Git, Terraform oder OpenTofu, CLI, APIs und geeignete Image-Management-Prozesse überführt werden. |
Das servicebezogene Ziel-Mapping finden Sie unter Zielservice-Mappings für AWS und Azure.
Klassifikationsdimensionen
Abschnitt betitelt „Klassifikationsdimensionen“Nutzen Sie diese Dimensionen, um Anfragen vor der Auswahl von Umsetzungsvarianten zu kategorisieren:
- Migrationsobjekt: Application Stack, Datenbestand oder Container-Plattform.
- State-Profil: Stateless, stateful oder gemischt.
- Kritikalitätsprofil: Business-Kritikalität und akzeptiertes Migrationsrisiko.
- Konnektivitätsprofil: Netzwerk-Erreichbarkeit und Protokollkompatibilität zwischen Quelle und Ziel.
- Downtime-Profil: Erlaubte Service-Unterbrechung und Grenzen des Cutover-Fensters.
- Compliance-Profil: Security-, Audit- und regulatorische Grenzen.
Wie eine Migrationsanfrage klassifiziert wird
Abschnitt betitelt „Wie eine Migrationsanfrage klassifiziert wird“- Das primäre Migrationsobjekt identifizieren.
- Workload-State-Profil und Kritikalität bestimmen.
- Konnektivitäts- und Transfer-Einschränkungen erfassen.
- Rahmenbedingungen für Downtime, Konsistenz und Compliance definieren.
- Die Anfrage einer Use-Case-Kategorie zuordnen und Annahmen dokumentieren.
Use-Case-Katalog und Grenzen
Abschnitt betitelt „Use-Case-Katalog und Grenzen“1. Application-Runtime-Migration
Abschnitt betitelt „1. Application-Runtime-Migration“- Umfasst: Application-Stack-Migration (inklusive VM-zentrierter Migrationen).
- Primäres Ziel: Anwendungs-Runtimes mit planbarem Cutover und Betriebs-Handover überführen.
Verbindliche Grenzen:
- Abhängigkeits-Klarheit: Integrationsabhängigkeiten und Übergangsfenster müssen bekannt sein.
- Cutover-Modell: Unterbrechungsmodell und Entscheidungs-Gates müssen freigegeben sein.
- Rollback-Readiness: Trigger und Ownership müssen definiert sein.
2. Container-Plattform-Migration
Abschnitt betitelt „2. Container-Plattform-Migration“- Umfasst: Kubernetes-zu-Kubernetes-Migration.
- Primäres Ziel: Containerisierte Workloads in Ziel-Cluster-Modelle überführen.
Verbindliche Grenzen:
- State-Klassifikation: Stateless-/Stateful-Grenzen müssen je Komponente explizit sein.
- State-Portabilität: Storage- und Datenbank-Kompatibilität müssen validiert sein.
- Traffic-Steuerung: Die Fähigkeit zum progressiven Switch muss bestätigt sein.
3. Datenmigration
Abschnitt betitelt „3. Datenmigration“- Umfasst: Migration großer Dateibestände sowie Datenbank-/Datenplattform-Übergänge.
- Primäres Ziel: Datenbestände mit kontrollierter Konsistenz und Integrität überführen.
Verbindliche Grenzen:
- Konnektivitäts-Machbarkeit: Die erforderliche Endpunkt-Erreichbarkeit muss validiert sein.
- Konsistenzmodell: Freeze-Fenster, Delta-Strategie und Validierungsmethoden müssen definiert sein.
- Performance-Machbarkeit: Durchsatzprofil und Laufzeitgrenzen müssen validiert sein.
4. Identity- und Access-Migration
Abschnitt betitelt „4. Identity- und Access-Migration“- Primäres Ziel: Identity-Trust- und Access-Modelle ohne Security-Regression überführen.
Verbindliche Grenzen:
- Trust-Modell-Mapping: Föderation, SSO und Token-Flows müssen gemappt sein.
- Autorisierungs-Mapping: Rollen- und Entitlement-Mapping müssen validiert sein.
- Credential-Übergang: Secret-Rotation und Notfall-Zugriffspfade müssen freigegeben sein.
5. Netzwerk- und Konnektivitäts-Migration
Abschnitt betitelt „5. Netzwerk- und Konnektivitäts-Migration“- Primäres Ziel: Kommunikationspfade und Security-Grenzen zwischen Umgebungen überführen.
Verbindliche Grenzen:
- Adressierung und Routing: IP-Planung und Routen-Ownership müssen definiert sein.
- Policy-Parität der Controls: Firewall- und Segmentierungs-Policies müssen abgeglichen sein.
- Kontinuität der Namensauflösung: Das DNS-Übergangsverhalten muss geplant sein.
6. Integrations- und API-Migration
Abschnitt betitelt „6. Integrations- und API-Migration“- Primäres Ziel: Service-Schnittstellen und Integrationsmuster überführen, ohne Consumer zu brechen.
Verbindliche Grenzen:
- Vertragskompatibilität: Versionierungs- und Kompatibilitätsstrategie müssen explizit sein.
- Abhängigkeits-Sequenzierung: Die Switch-Reihenfolge von Producer/Consumer muss gesteuert werden.
- Message-Semantik: Annahmen zu Ordering, Retries und wiederholungssicherem Verhalten müssen validiert sein.
7. Migration von Security- und Compliance-Controls
Abschnitt betitelt „7. Migration von Security- und Compliance-Controls“- Primäres Ziel: Wirksamkeit der Controls und Audit-Readiness während des Übergangs erhalten oder verbessern.
Verbindliche Grenzen:
- Control-Mapping: Erforderliche Controls und Nachweispunkte müssen gemappt sein.
- Schlüssel- und Zertifikats-Handling: Der Übergang kryptografischen Materials muss gesteuert sein.
- Audit-Kontinuität: Logging- und Nachweis-Aufbewahrungspflichten müssen intakt bleiben.
8. Operations- und Observability-Migration
Abschnitt betitelt „8. Operations- und Observability-Migration“- Primäres Ziel: Operative Kontrolle und Incident-Response-Readiness nach der Migration sicherstellen.
Verbindliche Grenzen:
- Observability-Baseline: Metriken, Logs, Traces und Alerts müssen vor dem Cutover aktiv sein.
- Betriebs-Ownership: On-Call- und Eskalationspfade müssen zugewiesen sein.
- Service-Ziele: SLO-/SLA-Ziele und Schwellwerte müssen definiert sein.
9. Delivery- und Resilienz-Migration
Abschnitt betitelt „9. Delivery- und Resilienz-Migration“- Primäres Ziel: Software-Delivery- und Resilienz-Fähigkeiten in den Zielbetrieb überführen.
Verbindliche Grenzen:
- Pipeline-Kontinuität: CI/CD- und Release-Controls müssen auditierbar bleiben.
- Recovery-Readiness: Backup-/Restore- und DR-Annahmen müssen validiert sein.
- Automatisierungs-Sicherheit: Leitplanken für Deployment-Automatisierung müssen vorhanden sein.
Fallübergreifende Entscheidungskriterien
Abschnitt betitelt „Fallübergreifende Entscheidungskriterien“- Downtime-Ziel: Geplantes Downtime-Fenster versus Erwartung durchgehender Verfügbarkeit.
- Konsistenzanforderung: Eventual Consistency, Near-Real-Time oder strikte transaktionale Konsistenz.
- Änderungstoleranz: Wie viel Architektur- und Anwendungsänderung in der aktuellen Welle akzeptabel ist.
- Automatisierungsgrad: Manueller, teilautomatisierter oder vollautomatisierter Ausführungspfad.
- Risiko und Reversibilität: Fähigkeit, Fehler schnell zu erkennen und ohne business-kritische Auswirkung zurückzurollen.
Konkrete Asset-Vorlagen
Abschnitt betitelt „Konkrete Asset-Vorlagen“Die Umsetzungsdetails werden auf dedizierten Asset-Seiten gepflegt. Das hält die Übersichtsseite kategorie-fokussiert und lässt konkrete Vorlagen unabhängig weiterentwickeln.
Anwendung mit VM-Runtime
Abschnitt betitelt „Anwendung mit VM-Runtime“Asset-Titel
Framework
Asset-Typ
Migration
Runbook
Große Datenmigration zum STACKIT File Service
Abschnitt betitelt „Große Datenmigration zum STACKIT File Service“Asset-Titel
Framework
Asset-Typ
Migration
Runbook
Migration
Runbook
Kubernetes-zu-Kubernetes-Migration
Abschnitt betitelt „Kubernetes-zu-Kubernetes-Migration“Asset-Titel
Framework
Asset-Typ
Migration
Runbook
Migration
Blueprint
Migration
Runbook
Data and AI
Blueprint
Migration
Runbook
Migration
Runbook
Migration
Runbook
Migration
Service
Zielmuster und Runtime auswählen
Warum diese Seite existiert
Abschnitt betitelt „Warum diese Seite existiert“Das Design-Modul entscheidet vor der Ausführung der Migration, wie eine Anwendung auf STACKIT betrieben werden soll. Diese Seite fokussiert auf Zielarchitektur-Entscheidungen für Anwendungen, nicht auf Landing-Zone-Basisthemen.
Welche Fragen ein gutes Design der Anwendung beantworten muss
Abschnitt betitelt „Welche Fragen ein gutes Design der Anwendung beantworten muss“Für jede Anwendung sollte das Zielbild diese zentralen Fragen beantworten:
- Workload-Modell: Soll die Anwendung auf VM, Kubernetes, Cloud Foundry, als statische Auslieferung oder auf einem SaaS-Ziel laufen?
- Service-Modell-Fit: Welches Service-Modell (IaaS, PaaS, SaaS) balanciert Kontrolle, Geschwindigkeit und Betriebsaufwand am besten?
- State- und Weg der Daten: Wie werden Datenkonsistenz, Cutover-Sequenz und Rollback umgesetzt?
- Betriebsmodell: Welches Team verantwortet Day-1/Day-2-Betrieb, Alerting, Backup und Incident Response?
- Regeln für Risiken: Welche Architekturentscheidungen sind verpflichtend, nur als Ausnahme zulässig oder ausdrücklich ausgeschlossen?
Orientierung zum Service-Modell (IaaS, PaaS, SaaS)
Abschnitt betitelt „Orientierung zum Service-Modell (IaaS, PaaS, SaaS)“Diese Orientierung hilft bei der praktischen Auswahl für Designs von Anwendungen:
- IaaS wählen, wenn: Tiefe OS-/Runtime-Kontrolle, Legacy-Abhängigkeiten oder spezielle Anforderungen ans Netzwerk erforderlich sind.
- PaaS wählen, wenn: Schnellere Lieferung und weniger Betriebsaufwand gewünscht sind, bei weiterhin eigener Verantwortung für die Anwendung.
- SaaS wählen, wenn: Der Geschäftsprozess ein standardisiertes Produkt akzeptiert und Differenzierung keinen eigenen Plattformbetrieb erfordert.
Nicht nach Gewohnheit entscheiden. Auf Basis messbarer Anforderungen, verfügbarer Betriebskapazität und Zielen über den Lebenszyklus entscheiden.
Runtime-Auswahl für typische STACKIT-Zielbilder
Abschnitt betitelt „Runtime-Auswahl für typische STACKIT-Zielbilder“VM-Runtime (IaaS)
Geeignet für Low-Change-Migrationen und Komponenten mit OS-naher Kontrolle, Spezialagenten oder ausgeprägten Legacy-Abhängigkeiten.
Kubernetes-Runtime (PaaS-nahes Betriebsmodell)
Geeignet für containerisierte Workloads mit Bedarf an skalierbarer Ausführung, standardisierten Releases und Plattformbetrieb.
Cloud-Foundry-Runtime (PaaS)
Geeignet, wenn Teams hohe Entwicklerproduktivität und schnelle Bereitstellung über tiefe Plattformkontrolle priorisieren.
Statische Auslieferung mit Object Storage/CDN
Geeignet für Frontend-/Static-Workloads mit hohem Verteilungsbedarf und geringer Runtime-Komplexität.
SaaS-Ersatzpfad
Geeignet, wenn Prozessfit und Standardfähigkeiten mehr Mehrwert liefern als Migration und Betrieb des bisherigen Stacks.
Architektur-Guardrails für Designs von Anwendungen
Abschnitt betitelt „Architektur-Guardrails für Designs von Anwendungen“- Immer umsetzen: Ziel-Runtime, Verantwortung für Daten, Rollback-Trigger und Day-1-Betrieb vor Freigabe der Migration festlegen.
- Nur als Ausnahme: Temporärer Dual-Run, manuelle Handover oder teilweise Automatisierung nur mit explizitem Risiko und Enddatum.
- Vermeiden: Runtime-Wechsel, Datenmigration und große Integrationsänderungen in einem unkontrollierten Cutover bündeln.
- Nie umsetzen: Kein Zielbild ohne Observability-Baseline, Backup-/Recovery-Modell und klar benannte Betriebsverantwortung freigeben.
Praktischer Design-Ablauf pro Anwendung
Abschnitt betitelt „Praktischer Design-Ablauf pro Anwendung“- Anwendungsscope, Abhängigkeiten und nicht-funktionale Anforderungen bestätigen.
- Service-Modell-Fit (IaaS, PaaS, SaaS) bewerten und zulässige Runtime-Ziele eingrenzen.
- Ein Zielmuster auswählen und dokumentieren, warum Alternativen verworfen wurden.
- Datenpfad, Cutover-Sequenz, Validierungsgates und Rollback-Logik festlegen.
- Betriebsverantwortung, Monitoring-Baseline und Handover-Kriterien definieren.
- Architekturentscheidungen in das Migrations-Runbook überführen.
Typische STACKIT-Designoptionen
Abschnitt betitelt „Typische STACKIT-Designoptionen“VM-Muster mit Betriebsbaseline
Spring Boot auf VM mit Application Load Balancer, Observability-Integration und Backup-Strategie.
Kubernetes-Plattformmuster
Spring Boot auf SKE mit gemanagten Datendiensten, Object Storage, Secret Handling und Messaging.
Statische Auslieferung mit CDN-Option
Statische Auslieferung aus Object Storage mit optionaler CDN-Beschleunigung für internetseitige Nutzung.
Hybrides Connectivity-Muster
Zugriff auf den Workload über VPN und zentrale Firewall-Controls für Enterprise-Netze.
Cloud-Foundry-Muster
Spring Boot auf Cloud Foundry mit angebundenen Backing Services wie Redis und RabbitMQ.
Die Pattern-Karten dienen als mögliche Zielbilder. Pro Anwendung sollte ein explizites Zielbild gewählt werden. Mehrere Muster nur kombinieren, wenn Koexistenz bewusst als Übergangszustand geplant ist.
Best practices für Zielbilder auf STACKIT
Abschnitt betitelt „Best practices für Zielbilder auf STACKIT“- Architektur und Runbook trennen: zuerst das Zielbild definieren, danach Sequenz und Rollback für die Migration ableiten.
- Betrieb von Anfang an einplanen: Observability-Signale, Alarm-Grenzen und Backup- oder Recovery-Erwartungen im Zielzustand festlegen.
- Managed Services bewusst nutzen: gemanagte Plattform-Services bevorzugen, wenn sie Betriebsaufwand senken und keine unnötige Codeänderung erzwingen.
- Vertrauensgrenzen im Netzwerk explizit definieren: Ingress, Egress, Ost-West-Controls und Hybrid-Bedarf vor der Umsetzung dokumentieren.
- Secrets und Zugriffe als Design-Input behandeln: IAM-Rollen, Service Accounts und Secret-Manager-Nutzung früh im Architektur-Paket aufnehmen.
- Datenmigration vom Runtime-Wechsel entkoppeln: bei stateful Workloads Daten-Gates getrennt von Runtime-Cutover validieren.
- Messbare Abnahmekriterien festlegen: Verfügbarkeit, Latenz, Skalierung und Recovery müssen vor Handover prüfbar sein.
Verwandte Design-Seiten
Abschnitt betitelt „Verwandte Design-Seiten“Architektur-Assets
Abschnitt betitelt „Architektur-Assets“Diese Architektur-Assets dienen als konkrete Design-Referenzen.
Asset-Titel
Framework
Asset-Typ
Migration
Blueprint
Migration
Anleitung
Migration
Software
Migration
Software
Migration
Software
Migration
Runbook
Migration
Blueprint
Migration
Runbook
Migration
Blueprint
Migration
Blueprint
Migration
Blueprint
Migration
Software
Migration
Service
Migration
Anleitung
Ausführbare Beispiele für Migrationen (bestehend)
Abschnitt betitelt „Ausführbare Beispiele für Migrationen (bestehend)“Asset-Titel
Framework
Asset-Typ
Migration
Runbook
Migration
Runbook
Migration
Runbook
Die Architektur-Assets helfen bei Auswahl und Begründung der Zielarchitektur, die Runbook-Assets bei der konkreten Umsetzung des Migrationspfad.
Warum diese Seite existiert
Abschnitt betitelt „Warum diese Seite existiert“Das Design-Modul entscheidet vor der Ausführung der Migration, wie eine Anwendung auf STACKIT betrieben werden soll. Diese Seite fokussiert auf Zielarchitektur-Entscheidungen für Anwendungen, nicht auf Landing-Zone-Basisthemen.
Welche Fragen ein gutes Design der Anwendung beantworten muss
Abschnitt betitelt „Welche Fragen ein gutes Design der Anwendung beantworten muss“Für jede Anwendung sollte das Zielbild diese zentralen Fragen beantworten:
- Workload-Modell: Soll die Anwendung auf VM, Kubernetes, Cloud Foundry, als statische Auslieferung oder auf einem SaaS-Ziel laufen?
- Service-Modell-Fit: Welches Service-Modell (IaaS, PaaS, SaaS) balanciert Kontrolle, Geschwindigkeit und Betriebsaufwand am besten?
- State- und Weg der Daten: Wie werden Datenkonsistenz, Cutover-Sequenz und Rollback umgesetzt?
- Betriebsmodell: Welches Team verantwortet Day-1/Day-2-Betrieb, Alerting, Backup und Incident Response?
- Regeln für Risiken: Welche Architekturentscheidungen sind verpflichtend, nur als Ausnahme zulässig oder ausdrücklich ausgeschlossen?
Orientierung zum Service-Modell (IaaS, PaaS, SaaS)
Abschnitt betitelt „Orientierung zum Service-Modell (IaaS, PaaS, SaaS)“Diese Orientierung hilft bei der praktischen Auswahl für Designs von Anwendungen:
- IaaS wählen, wenn: Tiefe OS-/Runtime-Kontrolle, Legacy-Abhängigkeiten oder spezielle Anforderungen ans Netzwerk erforderlich sind.
- PaaS wählen, wenn: Schnellere Lieferung und weniger Betriebsaufwand gewünscht sind, bei weiterhin eigener Verantwortung für die Anwendung.
- SaaS wählen, wenn: Der Geschäftsprozess ein standardisiertes Produkt akzeptiert und Differenzierung keinen eigenen Plattformbetrieb erfordert.
Nicht nach Gewohnheit entscheiden. Auf Basis messbarer Anforderungen, verfügbarer Betriebskapazität und Zielen über den Lebenszyklus entscheiden.
Runtime-Auswahl für typische STACKIT-Zielbilder
Abschnitt betitelt „Runtime-Auswahl für typische STACKIT-Zielbilder“VM-Runtime (IaaS)
Geeignet für Low-Change-Migrationen und Komponenten mit OS-naher Kontrolle, Spezialagenten oder ausgeprägten Legacy-Abhängigkeiten.
Kubernetes-Runtime (PaaS-nahes Betriebsmodell)
Geeignet für containerisierte Workloads mit Bedarf an skalierbarer Ausführung, standardisierten Releases und Plattformbetrieb.
Cloud-Foundry-Runtime (PaaS)
Geeignet, wenn Teams hohe Entwicklerproduktivität und schnelle Bereitstellung über tiefe Plattformkontrolle priorisieren.
Statische Auslieferung mit Object Storage/CDN
Geeignet für Frontend-/Static-Workloads mit hohem Verteilungsbedarf und geringer Runtime-Komplexität.
SaaS-Ersatzpfad
Geeignet, wenn Prozessfit und Standardfähigkeiten mehr Mehrwert liefern als Migration und Betrieb des bisherigen Stacks.
Architektur-Guardrails für Designs von Anwendungen
Abschnitt betitelt „Architektur-Guardrails für Designs von Anwendungen“- Immer umsetzen: Ziel-Runtime, Verantwortung für Daten, Rollback-Trigger und Day-1-Betrieb vor Freigabe der Migration festlegen.
- Nur als Ausnahme: Temporärer Dual-Run, manuelle Handover oder teilweise Automatisierung nur mit explizitem Risiko und Enddatum.
- Vermeiden: Runtime-Wechsel, Datenmigration und große Integrationsänderungen in einem unkontrollierten Cutover bündeln.
- Nie umsetzen: Kein Zielbild ohne Observability-Baseline, Backup-/Recovery-Modell und klar benannte Betriebsverantwortung freigeben.
Praktischer Design-Ablauf pro Anwendung
Abschnitt betitelt „Praktischer Design-Ablauf pro Anwendung“- Anwendungsscope, Abhängigkeiten und nicht-funktionale Anforderungen bestätigen.
- Service-Modell-Fit (IaaS, PaaS, SaaS) bewerten und zulässige Runtime-Ziele eingrenzen.
- Ein Zielmuster auswählen und dokumentieren, warum Alternativen verworfen wurden.
- Datenpfad, Cutover-Sequenz, Validierungsgates und Rollback-Logik festlegen.
- Betriebsverantwortung, Monitoring-Baseline und Handover-Kriterien definieren.
- Architekturentscheidungen in das Migrations-Runbook überführen.
Typische STACKIT-Designoptionen
Abschnitt betitelt „Typische STACKIT-Designoptionen“VM-Muster mit Betriebsbaseline
Spring Boot auf VM mit Application Load Balancer, Observability-Integration und Backup-Strategie.
Kubernetes-Plattformmuster
Spring Boot auf SKE mit gemanagten Datendiensten, Object Storage, Secret Handling und Messaging.
Statische Auslieferung mit CDN-Option
Statische Auslieferung aus Object Storage mit optionaler CDN-Beschleunigung für internetseitige Nutzung.
Hybrides Connectivity-Muster
Zugriff auf den Workload über VPN und zentrale Firewall-Controls für Enterprise-Netze.
Cloud-Foundry-Muster
Spring Boot auf Cloud Foundry mit angebundenen Backing Services wie Redis und RabbitMQ.
Die Pattern-Karten dienen als mögliche Zielbilder. Pro Anwendung sollte ein explizites Zielbild gewählt werden. Mehrere Muster nur kombinieren, wenn Koexistenz bewusst als Übergangszustand geplant ist.
Best practices für Zielbilder auf STACKIT
Abschnitt betitelt „Best practices für Zielbilder auf STACKIT“- Architektur und Runbook trennen: zuerst das Zielbild definieren, danach Sequenz und Rollback für die Migration ableiten.
- Betrieb von Anfang an einplanen: Observability-Signale, Alarm-Grenzen und Backup- oder Recovery-Erwartungen im Zielzustand festlegen.
- Managed Services bewusst nutzen: gemanagte Plattform-Services bevorzugen, wenn sie Betriebsaufwand senken und keine unnötige Codeänderung erzwingen.
- Vertrauensgrenzen im Netzwerk explizit definieren: Ingress, Egress, Ost-West-Controls und Hybrid-Bedarf vor der Umsetzung dokumentieren.
- Secrets und Zugriffe als Design-Input behandeln: IAM-Rollen, Service Accounts und Secret-Manager-Nutzung früh im Architektur-Paket aufnehmen.
- Datenmigration vom Runtime-Wechsel entkoppeln: bei stateful Workloads Daten-Gates getrennt von Runtime-Cutover validieren.
- Messbare Abnahmekriterien festlegen: Verfügbarkeit, Latenz, Skalierung und Recovery müssen vor Handover prüfbar sein.
Verwandte Design-Seiten
Abschnitt betitelt „Verwandte Design-Seiten“Architektur-Assets
Abschnitt betitelt „Architektur-Assets“Diese Architektur-Assets dienen als konkrete Design-Referenzen.
Asset-Titel
Framework
Asset-Typ
Migration
Blueprint
Migration
Anleitung
Migration
Software
Migration
Software
Migration
Software
Migration
Runbook
Migration
Blueprint
Migration
Runbook
Migration
Blueprint
Migration
Blueprint
Migration
Blueprint
Migration
Software
Migration
Service
Migration
Anleitung
Ausführbare Beispiele für Migrationen (bestehend)
Abschnitt betitelt „Ausführbare Beispiele für Migrationen (bestehend)“Asset-Titel
Framework
Asset-Typ
Migration
Runbook
Migration
Runbook
Migration
Runbook
Die Architektur-Assets helfen bei Auswahl und Begründung der Zielarchitektur, die Runbook-Assets bei der konkreten Umsetzung des Migrationspfad.
Runbook und Cutover vorbereiten
Warum ein Runbook ein Design-Ergebnis ist
Abschnitt betitelt „Warum ein Runbook ein Design-Ergebnis ist“In diesem Framework wird das Runbook in der Design-Phase erstellt. Es beschreibt den geplanten Ablauf, Controls, Rollback-Logik und Handover-Kriterien je Migrationsstrategie.
Migration Factory Setup erstellt nicht die erste Runbook-Version. Dort werden Design-Runbook-Entwuerfe operativ gehärtet, standardisiert und für die Wellen-Delivery validiert.
Pflicht-Kapitel eines Runbooks
Abschnitt betitelt „Pflicht-Kapitel eines Runbooks“Jedes Migrations-Runbook sollte diese Kapitel enthalten:
- Scope und Kontext: Scope der Anwendung, Kontext von Quelle und Ziel, Annahmen, Ausschlüsse.
- Owner und Entscheidungsrechte: Technischer Owner, Release-Owner, Rollback-Verantwortung, Eskalationsweg.
- Abhängigkeiten und Voraussetzungen: Plattform-Readiness, Zugriffe, Datenlage, externe Wartungsfenster.
- Cutover-Plan: Geordnete Run-Schritte, erwartete Dauer, Freeze-Punkte, Punkte für Kommunikation.
- Validierungsprüfungen: Funktionale, nicht-funktionale, Security- und Observability-Checks mit Nachweisen.
- Rollback und Fallback: Trigger-Bedingungen, Rollback-Schritte, Fallback-Kommunikationsfluss.
- Handover und Day-1-Betrieb: Übergabe an den Betrieb, Incident-Ownership, Post-Cutover-Stabilisierungsphase.
Qualitätskriterien für ein gutes Runbook
Abschnitt betitelt „Qualitätskriterien für ein gutes Runbook“Ausführbar
Schritte sind konkret, geordnet und klar Rollen zuweisbar.
Verifizierbar
Validierungspunkte definieren eindeutige Pass/Fail-Kriterien und benötigte Nachweise.
Wiederherstellbar
Der Rollback-Pfad ist vollständig, zeitlich geplant und an explizite Trigger-Bedingungen gekoppelt.
Handover-ready
Day-1-Betrieb und Ownership-Übergabe sind vollständig spezifiziert.
Empfohlener Design-zu-Factory-Ablauf
Abschnitt betitelt „Empfohlener Design-zu-Factory-Ablauf“- Strategie-spezifischen Runbook-Entwurf in der Design-Phase erstellen.
- Technische Annahmen mit Plattform-, Security- und Operations-Stakeholdern validieren.
- Nachweis-Checkpoints und Rollback-Trigger ergänzen.
- Zur Standardisierung und Readiness-Prüfung an Migration Factory Setup übergeben.
- Nach Probe oder Pilot-Validierung für Wellen-Ausführung freigeben.
Konkretes Beispiel-Asset
Abschnitt betitelt „Konkretes Beispiel-Asset“Nutzen Sie dieses konkrete Beispiel-Runbook für einen klassischen Rehost-Fall (Spring Boot auf VM):
Asset-Titel
Framework
Asset-Typ
Migration
Runbook
- Muster: Lift-and-Shift auf Ziel-VM (kein Kubernetes)
- Anwendungstyp: Typischer Enterprise-Spring-Boot-Service mit PostgreSQL-Backend
Warum ein Runbook ein Design-Ergebnis ist
Abschnitt betitelt „Warum ein Runbook ein Design-Ergebnis ist“In diesem Framework wird das Runbook in der Design-Phase erstellt. Es beschreibt den geplanten Ablauf, Controls, Rollback-Logik und Handover-Kriterien je Migrationsstrategie.
Migration Factory Setup erstellt nicht die erste Runbook-Version. Dort werden Design-Runbook-Entwuerfe operativ gehärtet, standardisiert und für die Wellen-Delivery validiert.
Pflicht-Kapitel eines Runbooks
Abschnitt betitelt „Pflicht-Kapitel eines Runbooks“Jedes Migrations-Runbook sollte diese Kapitel enthalten:
- Scope und Kontext: Scope der Anwendung, Kontext von Quelle und Ziel, Annahmen, Ausschlüsse.
- Owner und Entscheidungsrechte: Technischer Owner, Release-Owner, Rollback-Verantwortung, Eskalationsweg.
- Abhängigkeiten und Voraussetzungen: Plattform-Readiness, Zugriffe, Datenlage, externe Wartungsfenster.
- Cutover-Plan: Geordnete Run-Schritte, erwartete Dauer, Freeze-Punkte, Punkte für Kommunikation.
- Validierungsprüfungen: Funktionale, nicht-funktionale, Security- und Observability-Checks mit Nachweisen.
- Rollback und Fallback: Trigger-Bedingungen, Rollback-Schritte, Fallback-Kommunikationsfluss.
- Handover und Day-1-Betrieb: Übergabe an den Betrieb, Incident-Ownership, Post-Cutover-Stabilisierungsphase.
Qualitätskriterien für ein gutes Runbook
Abschnitt betitelt „Qualitätskriterien für ein gutes Runbook“Ausführbar
Schritte sind konkret, geordnet und klar Rollen zuweisbar.
Verifizierbar
Validierungspunkte definieren eindeutige Pass/Fail-Kriterien und benötigte Nachweise.
Wiederherstellbar
Der Rollback-Pfad ist vollständig, zeitlich geplant und an explizite Trigger-Bedingungen gekoppelt.
Handover-ready
Day-1-Betrieb und Ownership-Übergabe sind vollständig spezifiziert.
Empfohlener Design-zu-Factory-Ablauf
Abschnitt betitelt „Empfohlener Design-zu-Factory-Ablauf“- Strategie-spezifischen Runbook-Entwurf in der Design-Phase erstellen.
- Technische Annahmen mit Plattform-, Security- und Operations-Stakeholdern validieren.
- Nachweis-Checkpoints und Rollback-Trigger ergänzen.
- Zur Standardisierung und Readiness-Prüfung an Migration Factory Setup übergeben.
- Nach Probe oder Pilot-Validierung für Wellen-Ausführung freigeben.
Konkretes Beispiel-Asset
Abschnitt betitelt „Konkretes Beispiel-Asset“Nutzen Sie dieses konkrete Beispiel-Runbook für einen klassischen Rehost-Fall (Spring Boot auf VM):
Asset-Titel
Framework
Asset-Typ
Migration
Runbook
- Muster: Lift-and-Shift auf Ziel-VM (kein Kubernetes)
- Anwendungstyp: Typischer Enterprise-Spring-Boot-Service mit PostgreSQL-Backend
Business Case
Gehen Sie hier in die Tiefe: Verbinden Sie jede R-Strategie-Entscheidung mit einmaliger Investition, Run-Kosten-Ökonomie und erwartetem Langfristnutzen.
Dieses Modul verstehen
Abschnitt betitelt „Dieses Modul verstehen“Der Business Case übersetzt Discovery, Ziel-Design und Migration Strategy in eine transparente Entscheidungsvorlage je Anwendung.
Der finanzielle Kern ist klar:
- Erwartete Cloud-Kosten aus Zielarchitektur und Betriebsmodell prognostizieren.
- Diese Kosten mit der Kosten-Baseline des heutigen Zustands vergleichen.
- Deltas für Application Owner und Sponsor-Stakeholder nachvollziehbar machen.
Dieses Modul erweitert den reinen Vergleich der Kosten um zusätzlichen Business-Nutzen, der sich aus technischen Discovery-Daten meist nicht direkt ableiten lässt.
Kernfrage des Moduls
Abschnitt betitelt „Kernfrage des Moduls“Für jede Anwendung wird eine praktische Entscheidungsfrage beantwortet:
Erzeugt die Migration zum richtigen Zeitpunkt genug Mehrwert, um Investition und Umsetzungsrisiko zu rechtfertigen?
Eingaben für den Business Case
Abschnitt betitelt „Eingaben für den Business Case“Der Business Case nutzt strukturierte Eingaben aus vorherigen Modulen:
- Discovery-Ergebnisse: Lastprofil der Anwendung, Life-Cycle-Status, Nutzungsverhalten und Baseline-Betriebskosten.
- Design-Ergebnisse: Annahmen zur Landing Zone, Ziel-Services sowie Anforderungen an Verfügbarkeit, Sicherheit und Compliance.
- Migrationsstrategie: Gewähltes Migrationsmuster (z. B. Rehost, Replatform, Refactor), Wellenplanung und Übergangsrestriktionen.
- Finanzielle Baseline: Aktuelle TCO-Bausteine wie Infrastruktur, Lizenzen, Betrieb, Support und gegebenenfalls Abschreibungen.
Kostentransparenz als Pflicht-Ergebnis
Abschnitt betitelt „Kostentransparenz als Pflicht-Ergebnis“Das erste Pflicht-Ergebnis ist ein klares Kostenbild je Anwendung und Welle:
- Cloud-Zielbetriebskosten: Prognostizierte laufende Kosten im Zielzustand.
- Transition-Kosten: Einmalige Migrationskosten (Factory-Aufwand, Tooling, Parallelbetrieb, Cutover).
- Baseline-Kosten: Kosten des heutigen Betriebs (On-Premises oder bestehendes Hosting).
- Delta-Sicht: Kostenunterschiede über die Zeit inklusive Break-even-Betrachtung.
Damit erhalten Application Owner die Mindestbasis für finanziell belastbare Migrationsentscheidungen.
KI-gestützte Business-Case-Assets
Abschnitt betitelt „KI-gestützte Business-Case-Assets“KI-gestützte Business-Case-Assets können aus erfassten Anforderungen und Zielarchitektur-Annahmen erste STACKIT Laufkostenschätzungen und Business-Case-Entwürfe für die fachliche Prüfung erzeugen.
Asset-Titel
Framework
Asset-Typ
Migration
Software
Beispiel: Kostenstapel im Vergleich
Abschnitt betitelt „Beispiel: Kostenstapel im Vergleich“Die folgende semantische Darstellung vergleicht Ausgangs- und Zielkosten je Kategorie auf einer einheitlichen Skala. In diesem Beispiel zeigt der STACKIT-Stapel einen Mittelwert und Bandbreiten je Kategorie. Abhängig von Migrationsqualität und FinOps-Reife können einzelne Kostenkategorien auch steigen.
Wichtig: Die Grafik nutzt illustrative Kostenindex-Werte, um die Vergleichsmethode zu zeigen. Sie ist kein empirischer Benchmark und muss mit projektspezifischen Baseline- und Preisdaten ersetzt werden.
Annahmen, Datengrundlage und Quellenhinweise
Abschnitt betitelt „Annahmen, Datengrundlage und Quellenhinweise“- Methode: Die Baseline ist auf 100 indexiert. Je Kostenkategorie wird ein Wertebereich plus ein Mittelwert-Szenario dargestellt.
- Interpretation: Die Wertebereiche sind orientierende Erfahrungswerte aus Migrationsprogrammen und FinOps-Praxis, keine Garantie.
- Einflussfaktoren: Architekturqualität, Migrationsmuster, Workload-Eignung, Lizenzmodell, Resilienzanforderungen und Governance-Reife.
- Nötige Projektdaten: Gemessene Baseline-Auslastung, Vertrags- und Lizenzposition, Zielarchitektur und Betriebsmodellannahmen.
| Kostenkategorie | Illustrativer Bereich gegen Baseline | Typische Treiber |
|---|---|---|
| Infrastruktur | -40% bis -10% | Rightsizing und Managed Services reduzieren häufig Überprovisionierung. |
| Lizenzen | -20% bis +15% | BYOL-Entscheidungen und Softwaremodell-Wechsel können Kosten senken oder erhöhen. |
| Betrieb | -25% bis +10% | Automatisierung kann Aufwand senken; Parallelbetrieb und Umstellungskomplexität können gegenläufig wirken. |
| Sicherheit und Compliance | -10% bis +20% | Tool-Konsolidierung kann senken, höhere Kontrolltiefe kann erhöhen. |
| Backup und Wiederherstellung | -15% bis +25% | Tiering kann sparen; strengere RPO/RTO und Replikation können Kosten erhöhen. |
Methodische Referenzpunkte und Beobachtungen zur Kostenschwankung:
FinOps Foundation: State of FinOps Data and Benchmarking Hub Externe Seite öffnen Führt von der Route weg FinOps Foundation Framework: Usage Optimization Externe Seite öffnen Führt von der Route weg FinOps Foundation Framework: Rate Optimization Externe Seite öffnen Führt von der Route wegR-Strategie-Matrix für einmalige Investition und Langfristnutzen
Abschnitt betitelt „R-Strategie-Matrix für einmalige Investition und Langfristnutzen“Die folgende Matrix modelliert explizit den Teil, den der Run-Cost-Stapel nicht zeigt: die einmaligen Migrations- und Projektkosten je Strategieentscheidung.
So ist die Matrix zu lesen:
- X-Achse: Einmalige Migrations- und Projektinvestition (Umsetzungsaufwand, Tooling, Test, Change, Cutover).
- Y-Achse: Langfristnutzen (Run-Cost-Effekt plus fachliche und operative Wirkung).
- Punktbeschriftung: Illustrative Bandbreiten, keine festen Zusagen.
Für belastbare Entscheidungen sollten beide Sichten kombiniert werden:
- Run-Cost-Stapel: Entwicklung der wiederkehrenden Betriebskosten.
- R-Strategie-Matrix: Vorabinvestition und Transformationswirkung.
- Entscheidungslogik: Break-even und Wertrealisierung über einen definierten Zeitraum betrachten, nicht nur den Run Cost.
Zusätzliche Business-Value-Dimensionen
Abschnitt betitelt „Zusätzliche Business-Value-Dimensionen“Kosten sind essenziell, aber nur ein Teil der Wertgleichung. Eine Cloud-Migration kann deutliche zusätzliche Nutzenbeiträge liefern, die in Discovery-Daten nicht unmittelbar sichtbar sind.
Geschwindigkeit und Lieferfähigkeit
Schnellere Bereitstellung, kürzere Durchlaufzeiten und häufigere Releases beschleunigen die Auslieferung von Produkten und Features.
Resilienz und Risikoreduktion
Bessere Backup-, Recovery- und Hochverfügbarkeitsmuster können Ausfallwahrscheinlichkeit und Ausfallauswirkung reduzieren.
Sicherheits- und Compliance-Qualität
Höherer Automatisierungsgrad, bessere Kontrollreife und Auditierbarkeit senken operative und regulatorische Risiken.
Skalierbarkeit und Nachfrageflexibilität
Elastizität kann Überprovisionierung verringern und Wachstumsengpässe in Lastspitzen vermeiden.
Technische Schulden und Modernisierung
Plattform-Modernisierung reduziert Wartungsaufwand und ermöglicht weitere Architekturentwicklung.
Produktivität und Fokus der Teams
Teams investieren weniger Zeit in undifferenzierende Infrastrukturtätigkeiten und mehr in fachlichen Mehrwert.
Praxistauglicher Quantifizierungsansatz
Abschnitt betitelt „Praxistauglicher Quantifizierungsansatz“Nicht jeder Nutzenbeitrag muss am ersten Tag exakt in Euro beziffert sein. Verwenden Sie ein kombiniertes Bewertungsmodell:
-
Direkt quantifizierbar: Kosten, Lizenzen, Infrastrukturbedarf, Teile des Betriebsaufwands.
-
Mit Proxy grob schätzbar: Incident-Auswirkungen, Release-Durchlaufzeit, Bereitstellungsgeschwindigkeit von Umgebungen.
-
Qualitativ, aber entscheidungsrelevant: Strategische Agilität, Plattform-Standardisierung, Innovationsfähigkeit.
Annahmen sollten explizit dokumentiert und mit einem Transparenzgrad zur Datenqualität versehen werden.
Empfohlene Kennzahlen je Anwendung
Abschnitt betitelt „Empfohlene Kennzahlen je Anwendung“Mindestens folgende Kennzahlen sollten geführt werden:
- Jährliche Baseline-Betriebskosten.
- Prognostizierte jährliche Cloud-Betriebskosten.
- Einmaliges Migrationsinvestment.
- Erwartete Break-even-Dauer.
- Trend bei Change Lead Time (vor/nach Migration).
- Trend bei Verfügbarkeit bzw. Incident-Auswirkungen.
- Trend bei Security-/Compliance-Findings.
Iterativer Lebenszyklus des Business Case
Abschnitt betitelt „Iterativer Lebenszyklus des Business Case“Der Business Case ist kein einmaliges Dokument. Er wird je Welle gepflegt und mit zunehmenden Ist-Daten geschärft.
- Initiale Annahmen aus Discovery und Ziel-Design aufsetzen.
- Ziel-Cloud-Kosten und Migrationskosten je Anwendung schätzen.
- Nicht-kostenbezogene Nutzenhypothesen und messbare Proxys ergänzen.
- Annahmen mit Application Owner und Finance-Stakeholdern abstimmen und freigeben.
- Nach Pilot und frühen Wellen mit Ist-Daten aktualisieren.
- Migrations-Backlog auf Basis der aktualisierten Wertbelege neu priorisieren.
Ergebnisse dieses Moduls
Abschnitt betitelt „Ergebnisse dieses Moduls“Der Business Case sollte mindestens folgende Ergebnisse liefern:
-
Business-Case-Sheet je Anwendung: Baseline-Kosten, Zielprognose, Migrationsinvestment und Break-even-Logik.
-
Bewertung zusätzlicher Value-Dimensionen: Strukturierte Sicht auf Nutzenbeiträge und Risikoreduktion.
-
Annahmenregister: Transparente Annahmen, Hinweise zur Datenqualität und Confidence-Rating.
-
Entscheidungsempfehlung: Proceed, defer, redesign oder stop je Anwendung.
Dieses Modul verstehen
Abschnitt betitelt „Dieses Modul verstehen“Der Business Case übersetzt Discovery, Ziel-Design und Migration Strategy in eine transparente Entscheidungsvorlage je Anwendung.
Der finanzielle Kern ist klar:
- Erwartete Cloud-Kosten aus Zielarchitektur und Betriebsmodell prognostizieren.
- Diese Kosten mit der Kosten-Baseline des heutigen Zustands vergleichen.
- Deltas für Application Owner und Sponsor-Stakeholder nachvollziehbar machen.
Dieses Modul erweitert den reinen Vergleich der Kosten um zusätzlichen Business-Nutzen, der sich aus technischen Discovery-Daten meist nicht direkt ableiten lässt.
Kernfrage des Moduls
Abschnitt betitelt „Kernfrage des Moduls“Für jede Anwendung wird eine praktische Entscheidungsfrage beantwortet:
Erzeugt die Migration zum richtigen Zeitpunkt genug Mehrwert, um Investition und Umsetzungsrisiko zu rechtfertigen?
Eingaben für den Business Case
Abschnitt betitelt „Eingaben für den Business Case“Der Business Case nutzt strukturierte Eingaben aus vorherigen Modulen:
- Discovery-Ergebnisse: Lastprofil der Anwendung, Life-Cycle-Status, Nutzungsverhalten und Baseline-Betriebskosten.
- Design-Ergebnisse: Annahmen zur Landing Zone, Ziel-Services sowie Anforderungen an Verfügbarkeit, Sicherheit und Compliance.
- Migrationsstrategie: Gewähltes Migrationsmuster (z. B. Rehost, Replatform, Refactor), Wellenplanung und Übergangsrestriktionen.
- Finanzielle Baseline: Aktuelle TCO-Bausteine wie Infrastruktur, Lizenzen, Betrieb, Support und gegebenenfalls Abschreibungen.
Kostentransparenz als Pflicht-Ergebnis
Abschnitt betitelt „Kostentransparenz als Pflicht-Ergebnis“Das erste Pflicht-Ergebnis ist ein klares Kostenbild je Anwendung und Welle:
- Cloud-Zielbetriebskosten: Prognostizierte laufende Kosten im Zielzustand.
- Transition-Kosten: Einmalige Migrationskosten (Factory-Aufwand, Tooling, Parallelbetrieb, Cutover).
- Baseline-Kosten: Kosten des heutigen Betriebs (On-Premises oder bestehendes Hosting).
- Delta-Sicht: Kostenunterschiede über die Zeit inklusive Break-even-Betrachtung.
Damit erhalten Application Owner die Mindestbasis für finanziell belastbare Migrationsentscheidungen.
KI-gestützte Business-Case-Assets
Abschnitt betitelt „KI-gestützte Business-Case-Assets“KI-gestützte Business-Case-Assets können aus erfassten Anforderungen und Zielarchitektur-Annahmen erste STACKIT Laufkostenschätzungen und Business-Case-Entwürfe für die fachliche Prüfung erzeugen.
Asset-Titel
Framework
Asset-Typ
Migration
Software
Beispiel: Kostenstapel im Vergleich
Abschnitt betitelt „Beispiel: Kostenstapel im Vergleich“Die folgende semantische Darstellung vergleicht Ausgangs- und Zielkosten je Kategorie auf einer einheitlichen Skala. In diesem Beispiel zeigt der STACKIT-Stapel einen Mittelwert und Bandbreiten je Kategorie. Abhängig von Migrationsqualität und FinOps-Reife können einzelne Kostenkategorien auch steigen.
Wichtig: Die Grafik nutzt illustrative Kostenindex-Werte, um die Vergleichsmethode zu zeigen. Sie ist kein empirischer Benchmark und muss mit projektspezifischen Baseline- und Preisdaten ersetzt werden.
Annahmen, Datengrundlage und Quellenhinweise
Abschnitt betitelt „Annahmen, Datengrundlage und Quellenhinweise“- Methode: Die Baseline ist auf 100 indexiert. Je Kostenkategorie wird ein Wertebereich plus ein Mittelwert-Szenario dargestellt.
- Interpretation: Die Wertebereiche sind orientierende Erfahrungswerte aus Migrationsprogrammen und FinOps-Praxis, keine Garantie.
- Einflussfaktoren: Architekturqualität, Migrationsmuster, Workload-Eignung, Lizenzmodell, Resilienzanforderungen und Governance-Reife.
- Nötige Projektdaten: Gemessene Baseline-Auslastung, Vertrags- und Lizenzposition, Zielarchitektur und Betriebsmodellannahmen.
| Kostenkategorie | Illustrativer Bereich gegen Baseline | Typische Treiber |
|---|---|---|
| Infrastruktur | -40% bis -10% | Rightsizing und Managed Services reduzieren häufig Überprovisionierung. |
| Lizenzen | -20% bis +15% | BYOL-Entscheidungen und Softwaremodell-Wechsel können Kosten senken oder erhöhen. |
| Betrieb | -25% bis +10% | Automatisierung kann Aufwand senken; Parallelbetrieb und Umstellungskomplexität können gegenläufig wirken. |
| Sicherheit und Compliance | -10% bis +20% | Tool-Konsolidierung kann senken, höhere Kontrolltiefe kann erhöhen. |
| Backup und Wiederherstellung | -15% bis +25% | Tiering kann sparen; strengere RPO/RTO und Replikation können Kosten erhöhen. |
Methodische Referenzpunkte und Beobachtungen zur Kostenschwankung:
FinOps Foundation: State of FinOps Data and Benchmarking Hub Externe Seite öffnen Führt von der Route weg FinOps Foundation Framework: Usage Optimization Externe Seite öffnen Führt von der Route weg FinOps Foundation Framework: Rate Optimization Externe Seite öffnen Führt von der Route wegR-Strategie-Matrix für einmalige Investition und Langfristnutzen
Abschnitt betitelt „R-Strategie-Matrix für einmalige Investition und Langfristnutzen“Die folgende Matrix modelliert explizit den Teil, den der Run-Cost-Stapel nicht zeigt: die einmaligen Migrations- und Projektkosten je Strategieentscheidung.
So ist die Matrix zu lesen:
- X-Achse: Einmalige Migrations- und Projektinvestition (Umsetzungsaufwand, Tooling, Test, Change, Cutover).
- Y-Achse: Langfristnutzen (Run-Cost-Effekt plus fachliche und operative Wirkung).
- Punktbeschriftung: Illustrative Bandbreiten, keine festen Zusagen.
Für belastbare Entscheidungen sollten beide Sichten kombiniert werden:
- Run-Cost-Stapel: Entwicklung der wiederkehrenden Betriebskosten.
- R-Strategie-Matrix: Vorabinvestition und Transformationswirkung.
- Entscheidungslogik: Break-even und Wertrealisierung über einen definierten Zeitraum betrachten, nicht nur den Run Cost.
Zusätzliche Business-Value-Dimensionen
Abschnitt betitelt „Zusätzliche Business-Value-Dimensionen“Kosten sind essenziell, aber nur ein Teil der Wertgleichung. Eine Cloud-Migration kann deutliche zusätzliche Nutzenbeiträge liefern, die in Discovery-Daten nicht unmittelbar sichtbar sind.
Geschwindigkeit und Lieferfähigkeit
Schnellere Bereitstellung, kürzere Durchlaufzeiten und häufigere Releases beschleunigen die Auslieferung von Produkten und Features.
Resilienz und Risikoreduktion
Bessere Backup-, Recovery- und Hochverfügbarkeitsmuster können Ausfallwahrscheinlichkeit und Ausfallauswirkung reduzieren.
Sicherheits- und Compliance-Qualität
Höherer Automatisierungsgrad, bessere Kontrollreife und Auditierbarkeit senken operative und regulatorische Risiken.
Skalierbarkeit und Nachfrageflexibilität
Elastizität kann Überprovisionierung verringern und Wachstumsengpässe in Lastspitzen vermeiden.
Technische Schulden und Modernisierung
Plattform-Modernisierung reduziert Wartungsaufwand und ermöglicht weitere Architekturentwicklung.
Produktivität und Fokus der Teams
Teams investieren weniger Zeit in undifferenzierende Infrastrukturtätigkeiten und mehr in fachlichen Mehrwert.
Praxistauglicher Quantifizierungsansatz
Abschnitt betitelt „Praxistauglicher Quantifizierungsansatz“Nicht jeder Nutzenbeitrag muss am ersten Tag exakt in Euro beziffert sein. Verwenden Sie ein kombiniertes Bewertungsmodell:
-
Direkt quantifizierbar: Kosten, Lizenzen, Infrastrukturbedarf, Teile des Betriebsaufwands.
-
Mit Proxy grob schätzbar: Incident-Auswirkungen, Release-Durchlaufzeit, Bereitstellungsgeschwindigkeit von Umgebungen.
-
Qualitativ, aber entscheidungsrelevant: Strategische Agilität, Plattform-Standardisierung, Innovationsfähigkeit.
Annahmen sollten explizit dokumentiert und mit einem Transparenzgrad zur Datenqualität versehen werden.
Empfohlene Kennzahlen je Anwendung
Abschnitt betitelt „Empfohlene Kennzahlen je Anwendung“Mindestens folgende Kennzahlen sollten geführt werden:
- Jährliche Baseline-Betriebskosten.
- Prognostizierte jährliche Cloud-Betriebskosten.
- Einmaliges Migrationsinvestment.
- Erwartete Break-even-Dauer.
- Trend bei Change Lead Time (vor/nach Migration).
- Trend bei Verfügbarkeit bzw. Incident-Auswirkungen.
- Trend bei Security-/Compliance-Findings.
Iterativer Lebenszyklus des Business Case
Abschnitt betitelt „Iterativer Lebenszyklus des Business Case“Der Business Case ist kein einmaliges Dokument. Er wird je Welle gepflegt und mit zunehmenden Ist-Daten geschärft.
- Initiale Annahmen aus Discovery und Ziel-Design aufsetzen.
- Ziel-Cloud-Kosten und Migrationskosten je Anwendung schätzen.
- Nicht-kostenbezogene Nutzenhypothesen und messbare Proxys ergänzen.
- Annahmen mit Application Owner und Finance-Stakeholdern abstimmen und freigeben.
- Nach Pilot und frühen Wellen mit Ist-Daten aktualisieren.
- Migrations-Backlog auf Basis der aktualisierten Wertbelege neu priorisieren.
Ergebnisse dieses Moduls
Abschnitt betitelt „Ergebnisse dieses Moduls“Der Business Case sollte mindestens folgende Ergebnisse liefern:
-
Business-Case-Sheet je Anwendung: Baseline-Kosten, Zielprognose, Migrationsinvestment und Break-even-Logik.
-
Bewertung zusätzlicher Value-Dimensionen: Strukturierte Sicht auf Nutzenbeiträge und Risikoreduktion.
-
Annahmenregister: Transparente Annahmen, Hinweise zur Datenqualität und Confidence-Rating.
-
Entscheidungsempfehlung: Proceed, defer, redesign oder stop je Anwendung.
Migrationsplan
Gehen Sie hier in die Tiefe: Der Migrationsplan ist das gemeinsame Steuerungsdokument, das Portfolio-Entscheidungen mit ausführbaren Lieferwellen verbindet.
Überblick: Dieses Modul
Abschnitt betitelt „Überblick: Dieses Modul“Der Migrationsplan ist der Übergang von Analyse zur konkreten Umsetzung. Er folgt auf Discovery und wird durch das Modul Design laufend mit umsetzbaren Details gefüllt.
Ziel ist es, die Erkenntnisse aus Discovery und Design in einen detaillierten, schrittweisen Migrationsplan zu überführen, den Delivery-Teams mit hoher Verlässlichkeit umsetzen können.
Damit bildet dieses Modul die Brücke zwischen Strategie und Ausführung und ist zentral für den Gesamterfolg der Migration.
Kernaktivitäten
Abschnitt betitelt „Kernaktivitäten“Wellenbasierte Planung
Anwendungen in logische Migrationswellen gruppieren, basierend auf Abhängigkeiten, Geschäftskritikalität und technischer Komplexität.
Migrations-Runbooks
Detaillierte Schritt-für-Schritt-Runbooks je Welle oder Anwendung erstellen, inklusive Vorbereitung, Ausführung, Cutover, Rollback und Validierung.
Ressourcenplanung
Nötige Teams, Fähigkeiten, Werkzeuge und Experten je Welle festlegen, einschließlich Enablement- und Schulungsplanung.
Umsetzungs-Governance
Verbindliche Governance-Prozesse, Verantwortlichkeiten, Kommunikationsroutinen und Cutover-Kontrollen für die Wellenumsetzung etablieren.
Agilität als Grundprinzip
Abschnitt betitelt „Agilität als Grundprinzip“Migrationsplanung muss anpassungsfähig bleiben. Programme sollten frühe Wellen möglichst schnell starten und gleichzeitig Wellenschnitt und Reihenfolge kontinuierlich nachziehen, sobald neue Discovery- und Design-Ergebnisse vorliegen.
Runbooks sind lebende Dokumente. Nach jedem Cutover sollten Teams die Runbooks überarbeiten und verbessern. Mit steigender Runbook-Qualität steigt typischerweise auch die Migrationsgeschwindigkeit von Welle zu Welle.
Skalierung großer Migrationen in der Praxis
Abschnitt betitelt „Skalierung großer Migrationen in der Praxis“In großen Migrationsprogrammen liegt der Fokus auf skalierter Umsetzung. Typisch ist, mit kleinen Wellen zu starten (z. B. 5 Server/Woche) und den Durchsatz schrittweise zu steigern (z. B. auf 50-100 Server/Woche), abhängig von Restriktionen und Reifegrad.
Die ersten Wellen sind bewusst kleiner, damit Portfolio- und Migrations-Workstream ihre Prozesse stabilisieren, Annahmen validieren und Runbooks verbessern können. Dieser Lernzyklus ist ein zentraler Erfolgsfaktor in großen Migrationen.
Betriebsmodell der Migration Factory
Abschnitt betitelt „Betriebsmodell der Migration Factory“In diesem Modul wird die Migration Factory typischerweise über vier Bausteine gesteuert:
Project Governance Rules
Prozesse und Werkzeuge zur Steuerung von Wellen, Kommunikation, Zeitplänen und Cutovers, damit Aufgaben in der richtigen Reihenfolge und zum richtigen Zeitpunkt ausgeführt werden.
Portfolio-Runbooks
Runbooks zur Priorisierung von Anwendungen, Planung von Wellen und Erhebung der nötigen Metadaten als Eingangsmaterial für die Umsetzung.
Migrations-Runbooks
Runbooks für die technische Umsetzung der Wellen, das Laden von Metadaten in Migrationswerkzeuge sowie Cutover und Validierung.
Best Practices und Health-Check-Matrix
Regelmäßiger Health-Check zur Fortschrittsbewertung, frühen Risikoerkennung und Stabilisierung der Auslieferung.
Datenfluss durch Portfolio- und Migrations-Workstream
Abschnitt betitelt „Datenfluss durch Portfolio- und Migrations-Workstream“Runbooks bilden den Datenfluss über zwei verbundene Workstreams:
- Portfolio-Workstream: Priorisiert Anwendungen und bereitet Metadaten für kommende Wellen auf.
- Migrations-Workstream: Führt Migrationen und Cutover gemäß freigegebenem Wellenplan aus.
Teams sind meist auf bestimmte Teile der Factory spezialisiert, während die Wellen durch beide Workstreams fließen. Um Engpässe zu vermeiden, sollten ausreichend vorbereitete Wellen vor der Ausführung bereitstehen. Ein bewährter Richtwert ist, den Portfolio-Workstream fünf Wellen vor dem Migrations-Workstream zu halten.
Klare Abgrenzung von Portfolio und Migration
Abschnitt betitelt „Klare Abgrenzung von Portfolio und Migration“Für Steuerung und Kapazitätsplanung ist die Unterscheidung zwischen Funktion und Team wichtig:
- Portfolio: Fachliche und technische Vorbereitung einer Welle, inklusive Priorisierung, Abhängigkeitsklärung, Scope-Schnitt, Datenqualität und Readiness-Nachweis.
- Portfolio Team: Rollen, die Portfolio-Arbeit ausführen und verantworten (z. B. Programmleitung, Domain-Owner, Architekt:innen, Application-Owner und Governance).
- Migration: Operative Umsetzung der freigegebenen Welle mit Runbook-Ausführung, Change-/Cutover-Steuerung, Validierung, Stabilisierung und dokumentiertem Abschluss.
- Migration Team: Rollen, die technische Migration durchführen und absichern (z. B. Factory-Engineers, Plattform-Team, Netzwerk/Security, Test und Betriebsübergabe).
Beide Teams sind eng gekoppelt, übernehmen aber unterschiedliche Lieferobjekte:
- Portfolio Team liefert: Freigegebene Wellenzuschnitte, priorisierte Backlogs, vollständige Metadaten und umsetzungsfähige Eingangspakete.
- Migration Team liefert: Erfolgreiche Cutovers, validierte Zielzustände, Lessons Learned und verbesserte Runbook-Versionen für Folgewellen.
Dynamisches Wellenmuster in der Umsetzung
Abschnitt betitelt „Dynamisches Wellenmuster in der Umsetzung“Ein typisches Muster ist:
- Portfolio-Taktung: Etwa 1-2 Wochen je Welle für Vorbereitung.
- Migrations-Taktung: Etwa 3-4 Wochen je Welle für Umsetzung und Cutover.
- Wellenpuffer: Ein Puffer von fünf Wellen zwischen Portfolio- und Migrations-Workstream.
Bevor die Migrationsumsetzung in den Regelbetrieb übergeht, wird typischerweise ein initialer Wellenpuffer aufgebaut. Ab dem Start der Ausführung laufen beide Workstreams parallel weiter, und der Puffer verhindert Lieferengpässe.
Phasen- und Modulmodell in der Wellenplanung
Abschnitt betitelt „Phasen- und Modulmodell in der Wellenplanung“Die folgende Darstellung zeigt das operative Zielbild mit unserem Phasen- und Modulmodell: Der Planungsanteil liegt im Modul Migrationsplan (Design and Mobilize), die Ausführung läuft im Migrationsmodul in versetzten Wellen.
In diesem Modell sind die Phasengrenzen bewusst überlappend aufgebaut:
- Design and Mobilize startet mit der Wellenplanung und bleibt bis zum Ende der Planung von Welle 8 aktiv (bis Woche 3).
- Migrate startet bereits in Woche 3 und läuft über die verbleibende Zeitachse weiter.
- Pilotwelle und Anpassungen: Welle 1 ist als kürzere Pilotwelle zur Erstvalidierung ausgelegt; danach folgen gezielte Factory-Setup-Anpassungen in den ersten produktiven Wellen.
Der detaillierte Setup-Umfang ist im eigenen Kapitel beschrieben: Migration Factory Setup.
Das Muster bleibt bewusst dynamisch: Portfolio-Arbeit erzeugt einen stabilen Vorlauf, während Migration die Wellen mit Runbooks, Cutover und Validierung umsetzt.
Migration-Factory-Prozess im Modulfluss
Abschnitt betitelt „Migration-Factory-Prozess im Modulfluss“Der Migrationsplan verbindet Discovery- und Design-Ergebnisse mit Umsetzungs-Governance, Wellenplanung und runbook-basierter Delivery. Der Prozess koppelt Portfolio- und Migrations-Workstream eng über Governance, Runbooks und kontinuierliche Verbesserung.
Wellenplanung als dynamische Zeitachse
Abschnitt betitelt „Wellenplanung als dynamische Zeitachse“Wellenplanung ist kein statischer Terminplan. Sie ist eine operative Zeitachse, die für Stakeholder transparent und für neue Erkenntnisse anpassbar bleiben muss. Maßgeblich sind dabei Taktung, Überlappung der Workstreams und eine klare Pufferlogik.
Iterative Planungslogik in der Praxis
Abschnitt betitelt „Iterative Planungslogik in der Praxis“- Aktuelle Discovery- und Design-Ergebnisse sowie Restriktionen und Annahmen bestätigen.
- Wellenzuschnitt, Reihenfolge und Staffing auf Basis des aktuellen Stands aktualisieren.
- Aktuelle Welle mit freigegebenen Migrations- und Cutover-Runbooks ausführen.
- Cutover-Ergebnisse, Störungen und Zeitabweichungen auswerten.
- Governance-Kontrollen und Runbooks verbessern und in kommende Wellen übernehmen.
- Health-Status und Wellenpuffer prüfen und in die nächste Iteration gehen.
Ergebnisse dieses Moduls
Abschnitt betitelt „Ergebnisse dieses Moduls“Der Migrationsplan sollte mindestens folgende Ergebnisse liefern:
- Freigegebener Wellenplan: Sequenzierte Migrationswellen mit abhängigkeitsbewusster Gruppierung.
- Ausführbare Runbooks: Versionierte Runbooks je Welle/Anwendung mit Validierung und Rollback.
- Ressourcen- und Skill-Plan: Besetzungs- und Fähigkeitsplanung je Welle.
- Governance-Taktung: Rahmen für Entscheidungen, Kommunikation und Cutover-Steuerung.
- Backlog für kontinuierliche Verbesserung: Nachverfolgbare Verbesserungen aus jeder Welle.
Überblick: Dieses Modul
Abschnitt betitelt „Überblick: Dieses Modul“Der Migrationsplan ist der Übergang von Analyse zur konkreten Umsetzung. Er folgt auf Discovery und wird durch das Modul Design laufend mit umsetzbaren Details gefüllt.
Ziel ist es, die Erkenntnisse aus Discovery und Design in einen detaillierten, schrittweisen Migrationsplan zu überführen, den Delivery-Teams mit hoher Verlässlichkeit umsetzen können.
Damit bildet dieses Modul die Brücke zwischen Strategie und Ausführung und ist zentral für den Gesamterfolg der Migration.
Kernaktivitäten
Abschnitt betitelt „Kernaktivitäten“Wellenbasierte Planung
Anwendungen in logische Migrationswellen gruppieren, basierend auf Abhängigkeiten, Geschäftskritikalität und technischer Komplexität.
Migrations-Runbooks
Detaillierte Schritt-für-Schritt-Runbooks je Welle oder Anwendung erstellen, inklusive Vorbereitung, Ausführung, Cutover, Rollback und Validierung.
Ressourcenplanung
Nötige Teams, Fähigkeiten, Werkzeuge und Experten je Welle festlegen, einschließlich Enablement- und Schulungsplanung.
Umsetzungs-Governance
Verbindliche Governance-Prozesse, Verantwortlichkeiten, Kommunikationsroutinen und Cutover-Kontrollen für die Wellenumsetzung etablieren.
Agilität als Grundprinzip
Abschnitt betitelt „Agilität als Grundprinzip“Migrationsplanung muss anpassungsfähig bleiben. Programme sollten frühe Wellen möglichst schnell starten und gleichzeitig Wellenschnitt und Reihenfolge kontinuierlich nachziehen, sobald neue Discovery- und Design-Ergebnisse vorliegen.
Runbooks sind lebende Dokumente. Nach jedem Cutover sollten Teams die Runbooks überarbeiten und verbessern. Mit steigender Runbook-Qualität steigt typischerweise auch die Migrationsgeschwindigkeit von Welle zu Welle.
Skalierung großer Migrationen in der Praxis
Abschnitt betitelt „Skalierung großer Migrationen in der Praxis“In großen Migrationsprogrammen liegt der Fokus auf skalierter Umsetzung. Typisch ist, mit kleinen Wellen zu starten (z. B. 5 Server/Woche) und den Durchsatz schrittweise zu steigern (z. B. auf 50-100 Server/Woche), abhängig von Restriktionen und Reifegrad.
Die ersten Wellen sind bewusst kleiner, damit Portfolio- und Migrations-Workstream ihre Prozesse stabilisieren, Annahmen validieren und Runbooks verbessern können. Dieser Lernzyklus ist ein zentraler Erfolgsfaktor in großen Migrationen.
Betriebsmodell der Migration Factory
Abschnitt betitelt „Betriebsmodell der Migration Factory“In diesem Modul wird die Migration Factory typischerweise über vier Bausteine gesteuert:
Project Governance Rules
Prozesse und Werkzeuge zur Steuerung von Wellen, Kommunikation, Zeitplänen und Cutovers, damit Aufgaben in der richtigen Reihenfolge und zum richtigen Zeitpunkt ausgeführt werden.
Portfolio-Runbooks
Runbooks zur Priorisierung von Anwendungen, Planung von Wellen und Erhebung der nötigen Metadaten als Eingangsmaterial für die Umsetzung.
Migrations-Runbooks
Runbooks für die technische Umsetzung der Wellen, das Laden von Metadaten in Migrationswerkzeuge sowie Cutover und Validierung.
Best Practices und Health-Check-Matrix
Regelmäßiger Health-Check zur Fortschrittsbewertung, frühen Risikoerkennung und Stabilisierung der Auslieferung.
Datenfluss durch Portfolio- und Migrations-Workstream
Abschnitt betitelt „Datenfluss durch Portfolio- und Migrations-Workstream“Runbooks bilden den Datenfluss über zwei verbundene Workstreams:
- Portfolio-Workstream: Priorisiert Anwendungen und bereitet Metadaten für kommende Wellen auf.
- Migrations-Workstream: Führt Migrationen und Cutover gemäß freigegebenem Wellenplan aus.
Teams sind meist auf bestimmte Teile der Factory spezialisiert, während die Wellen durch beide Workstreams fließen. Um Engpässe zu vermeiden, sollten ausreichend vorbereitete Wellen vor der Ausführung bereitstehen. Ein bewährter Richtwert ist, den Portfolio-Workstream fünf Wellen vor dem Migrations-Workstream zu halten.
Klare Abgrenzung von Portfolio und Migration
Abschnitt betitelt „Klare Abgrenzung von Portfolio und Migration“Für Steuerung und Kapazitätsplanung ist die Unterscheidung zwischen Funktion und Team wichtig:
- Portfolio: Fachliche und technische Vorbereitung einer Welle, inklusive Priorisierung, Abhängigkeitsklärung, Scope-Schnitt, Datenqualität und Readiness-Nachweis.
- Portfolio Team: Rollen, die Portfolio-Arbeit ausführen und verantworten (z. B. Programmleitung, Domain-Owner, Architekt:innen, Application-Owner und Governance).
- Migration: Operative Umsetzung der freigegebenen Welle mit Runbook-Ausführung, Change-/Cutover-Steuerung, Validierung, Stabilisierung und dokumentiertem Abschluss.
- Migration Team: Rollen, die technische Migration durchführen und absichern (z. B. Factory-Engineers, Plattform-Team, Netzwerk/Security, Test und Betriebsübergabe).
Beide Teams sind eng gekoppelt, übernehmen aber unterschiedliche Lieferobjekte:
- Portfolio Team liefert: Freigegebene Wellenzuschnitte, priorisierte Backlogs, vollständige Metadaten und umsetzungsfähige Eingangspakete.
- Migration Team liefert: Erfolgreiche Cutovers, validierte Zielzustände, Lessons Learned und verbesserte Runbook-Versionen für Folgewellen.
Dynamisches Wellenmuster in der Umsetzung
Abschnitt betitelt „Dynamisches Wellenmuster in der Umsetzung“Ein typisches Muster ist:
- Portfolio-Taktung: Etwa 1-2 Wochen je Welle für Vorbereitung.
- Migrations-Taktung: Etwa 3-4 Wochen je Welle für Umsetzung und Cutover.
- Wellenpuffer: Ein Puffer von fünf Wellen zwischen Portfolio- und Migrations-Workstream.
Bevor die Migrationsumsetzung in den Regelbetrieb übergeht, wird typischerweise ein initialer Wellenpuffer aufgebaut. Ab dem Start der Ausführung laufen beide Workstreams parallel weiter, und der Puffer verhindert Lieferengpässe.
Phasen- und Modulmodell in der Wellenplanung
Abschnitt betitelt „Phasen- und Modulmodell in der Wellenplanung“Die folgende Darstellung zeigt das operative Zielbild mit unserem Phasen- und Modulmodell: Der Planungsanteil liegt im Modul Migrationsplan (Design and Mobilize), die Ausführung läuft im Migrationsmodul in versetzten Wellen.
In diesem Modell sind die Phasengrenzen bewusst überlappend aufgebaut:
- Design and Mobilize startet mit der Wellenplanung und bleibt bis zum Ende der Planung von Welle 8 aktiv (bis Woche 3).
- Migrate startet bereits in Woche 3 und läuft über die verbleibende Zeitachse weiter.
- Pilotwelle und Anpassungen: Welle 1 ist als kürzere Pilotwelle zur Erstvalidierung ausgelegt; danach folgen gezielte Factory-Setup-Anpassungen in den ersten produktiven Wellen.
Der detaillierte Setup-Umfang ist im eigenen Kapitel beschrieben: Migration Factory Setup.
Das Muster bleibt bewusst dynamisch: Portfolio-Arbeit erzeugt einen stabilen Vorlauf, während Migration die Wellen mit Runbooks, Cutover und Validierung umsetzt.
Migration-Factory-Prozess im Modulfluss
Abschnitt betitelt „Migration-Factory-Prozess im Modulfluss“Der Migrationsplan verbindet Discovery- und Design-Ergebnisse mit Umsetzungs-Governance, Wellenplanung und runbook-basierter Delivery. Der Prozess koppelt Portfolio- und Migrations-Workstream eng über Governance, Runbooks und kontinuierliche Verbesserung.
Wellenplanung als dynamische Zeitachse
Abschnitt betitelt „Wellenplanung als dynamische Zeitachse“Wellenplanung ist kein statischer Terminplan. Sie ist eine operative Zeitachse, die für Stakeholder transparent und für neue Erkenntnisse anpassbar bleiben muss. Maßgeblich sind dabei Taktung, Überlappung der Workstreams und eine klare Pufferlogik.
Iterative Planungslogik in der Praxis
Abschnitt betitelt „Iterative Planungslogik in der Praxis“- Aktuelle Discovery- und Design-Ergebnisse sowie Restriktionen und Annahmen bestätigen.
- Wellenzuschnitt, Reihenfolge und Staffing auf Basis des aktuellen Stands aktualisieren.
- Aktuelle Welle mit freigegebenen Migrations- und Cutover-Runbooks ausführen.
- Cutover-Ergebnisse, Störungen und Zeitabweichungen auswerten.
- Governance-Kontrollen und Runbooks verbessern und in kommende Wellen übernehmen.
- Health-Status und Wellenpuffer prüfen und in die nächste Iteration gehen.
Ergebnisse dieses Moduls
Abschnitt betitelt „Ergebnisse dieses Moduls“Der Migrationsplan sollte mindestens folgende Ergebnisse liefern:
- Freigegebener Wellenplan: Sequenzierte Migrationswellen mit abhängigkeitsbewusster Gruppierung.
- Ausführbare Runbooks: Versionierte Runbooks je Welle/Anwendung mit Validierung und Rollback.
- Ressourcen- und Skill-Plan: Besetzungs- und Fähigkeitsplanung je Welle.
- Governance-Taktung: Rahmen für Entscheidungen, Kommunikation und Cutover-Steuerung.
- Backlog für kontinuierliche Verbesserung: Nachverfolgbare Verbesserungen aus jeder Welle.
Landing Zone
Gehen Sie hier in die Tiefe: Bauen Sie die gemeinsame Plattform-Baseline auf, bevor Anwendungsteams mit Migrationswellen beginnen.
Überblick: Landing Zones
Abschnitt betitelt „Überblick: Landing Zones“Eine Landing Zone ist die strukturierte Cloud-Grundlage, die festlegt, wie Ihre Organisation auf STACKIT von Anfang an betrieben wird. Sie verbindet Governance, Identität, Security, Netzwerkarchitektur, Kostensteuerung und Automatisierung zu einem belastbaren Rahmen.
Ohne diese Grundlage stocken Migrationswellen typischerweise durch fehlende Freigaben, inkonsistente Kontrollen und wiederkehrende Plattformentscheidungen.
Kernkomponenten
Abschnitt betitelt „Kernkomponenten“Die folgende Visualisierung zeigt die zentralen Komponenten für eine belastbare Plattform-Basis.
Warum Sie eine Landing Zone brauchen
Abschnitt betitelt „Warum Sie eine Landing Zone brauchen“- Kontrolle und Risikoreduktion: Security- und Compliance-Kontrollen werden konsistent umgesetzt.
- Skalierbare Delivery-Basis: Wiederverwendbare Muster beschleunigen mehrere Migrationswellen.
- Klare Verantwortlichkeiten: Zuständigkeiten zwischen Plattform-, Security- und Applikationsteams sind klar.
- Höhere Umsetzungsgeschwindigkeit: Grundlegende Kontrollen müssen nicht je Applikation neu entworfen werden.
Wann Sie starten sollten
Abschnitt betitelt „Wann Sie starten sollten“Starten Sie den Landing-Zone-Stream so früh wie möglich parallel zum Discovery.
- Zu spät: Produktive Migrationen werden blockiert, weil Pflichtkontrollen noch fehlen.
- Zu früh ohne Discovery-Feedback: Relevante Applikationsrandbedingungen fehlen und führen zu Nacharbeit.
Bewährt hat sich ein zweigleisiges Vorgehen: Die Plattform-Basis früh etablieren und Application-Landing-Zone-Templates iterativ mit Discovery-Erkenntnissen verfeinern.
Zwei Ebenen: Platform und Application Landing Zone
Abschnitt betitelt „Zwei Ebenen: Platform und Application Landing Zone“Platform Landing Zone
Unternehmensweite Grundlage für Governance, Identität, Security, Netzwerk, Kostensteuerung und Automatisierung.
Zur Platform Landing ZoneApplication Landing Zone
Workload-spezifische Umsetzungsprofile, abgeleitet aus Plattform-Basis und Discovery-Ergebnissen.
Zur Application Landing ZoneTypische Eingaben aus dem Unternehmen
Abschnitt betitelt „Typische Eingaben aus dem Unternehmen“Für ein belastbares Landing-Zone-Design werden typischerweise benötigt:
- Organisations- und Ownership-Modell: Einheiten, Projektgrenzen und Verantwortungsmodell.
- Compliance- und Policy-Anforderungen: Regulatorische Pflichten und interne Kontrollvorgaben.
- Security-Anforderungen: IAM-Standards, Netzsegmentierung, Verschlüsselung und Logging.
- Betriebs- und Supportvorgaben: Incident-Prozesse, Eskalationswege und Übergabemodell.
- Erkenntnisse aus dem Applikationsportfolio: Discovery-Resultate zu Abhängigkeiten und Archetypen.
Vorgehensmodell
Abschnitt betitelt „Vorgehensmodell“- Unternehmensweite Leitplanken und Kontrollmodell definieren.
- Platform Landing Zone als Code aufbauen und validieren.
- Application-Landing-Zone-Templates aus Discovery und Migrationsdesign ableiten.
- Mit Pilot-Workloads testen und über Migration-Factory-Runbooks skalieren.
STACKIT Beschleuniger und Assets
Abschnitt betitelt „STACKIT Beschleuniger und Assets“Um die Umsetzung zu beschleunigen, bietet STACKIT konkrete Best Practices und wiederverwendbare Vorlagen:
Asset-Titel
Framework
Asset-Typ
Migration
Blueprint
Migration
Blueprint
Migration
Service
Migration
Blueprint
Migration
Software
Migration
Service
Zielbild
Abschnitt betitelt „Zielbild“Account Governance beschreibt, wie Teams, Umgebungen und Zuständigkeiten in der Cloud klar getrennt und steuerbar aufgebaut werden.
Damit entsteht die organisatorische Steuerungsebene für Migrationswellen: wo Workloads betrieben werden, wem welcher Scope gehört und wie neue Projekte ohne Umgehung von Guardrails angebunden werden.
Governance-Hierarchie
Abschnitt betitelt „Governance-Hierarchie“
Governance-Design und Delivery
Abschnitt betitelt „Governance-Design und Delivery“Kernbausteine der Governance
Abschnitt betitelt „Kernbausteine der Governance“- Regions: Die Regionenstrategie bestimmt Datenlokalität, Latenzprofil und Resilienzgrenzen für Workloads und Shared Services. Definieren Sie früh verbindliche Nutzungsmuster und stimmen Sie diese mit Compliance- und Kontinuitätsanforderungen ab. Dokumentation
- Customer Account: Der Customer Account ist die oberste Governance-Grenze für Ownership, Abrechnung und Administration. Er bildet den Anker für organisationsweite Standards und Kontrollverantwortung. Dokumentation
- STACKIT Folder: Folder strukturieren organisatorische Domänen (zum Beispiel Plattform, Shared Services, Business Units, Umgebungen) und ermöglichen Policy-Vererbung sowie klare Delegationsmodelle. Dokumentation
- STACKIT Projects: Projects sind die Delivery-Scopes, in denen Ressourcen bereitgestellt und betrieben werden. Sie sollten über ein definiertes Onboarding-Modell an Folder angebunden werden und nicht ad hoc entstehen. Dokumentation
Wie die Bausteine zusammenspielen
Abschnitt betitelt „Wie die Bausteine zusammenspielen“- Regionprinzipien zuerst: Legen Sie fest, welche Regionen für welche Workload-Klassen zulässig sind.
- Customer Account als Governance-Root: Verankern Sie globale Ownership, Policy-Absicht und finanzielle Verantwortlichkeit.
- Folder für Struktur und Delegation: Überführen Sie das Betriebsmodell in skalierbare organisatorische Grenzen.
- Projects für Delivery: Stellen Sie Projektscopes über einen standardisierten Lebenszyklus mit verpflichtenden, vom Folder geerbten Kontrollen bereit.
Wichtige Entscheidungen
Abschnitt betitelt „Wichtige Entscheidungen“- Region-Governance-Modell: Entscheiden Sie zwischen Single-Region-, Dual-Region- oder Workload-basiertem Regionenansatz inklusive Ausnahmen.
- Customer-Account-Verantwortung: Definieren Sie, welche zentralen Teams Governance, Billing-Transparenz und Kontrollbetrieb verantworten.
- Folder-Topologie: Legen Sie fest, wie Folder auf Domänen wie Plattform, Umgebungen und Business Units abgebildet werden.
- Project-Onboarding-Modell: Standardisieren Sie Projekterstellung, Namenskonventionen, Tagging und Lebenszyklus-Kontrollen.
- Policies und Ausnahmen: Definieren Sie verpflichtende Guardrails und transparente Ausnahmeprozesse.
Typische Ergebnisse
Abschnitt betitelt „Typische Ergebnisse“- Governance-Blueprint: Customer-Account-, Folder- und Project-Topologie mit Verantwortungsmatrix.
- Regionen-Nutzungsrichtlinie: Freigegebene Regionenmuster je Workload-Typ und Risikoprofil.
- Project-Onboarding-Standard: Wiederholbarer Prozess für die Erstellung und Anbindung gesteuerter Projekte.
- Control-Baseline: Erzwungene Namens-, Tagging- und Policy-Kontrollen mit dokumentiertem Ausnahmefluss.
Typische Anti-Patterns
Abschnitt betitelt „Typische Anti-Patterns“- Keine Regionenrichtlinie: Regionauswahl pro Team oder Projekt ohne unternehmensweite Leitplanken.
- Unstrukturierte Project-Sprawl: Projekte entstehen ohne Folder-Strategie, klare Ownership oder Lebenszyklusstandards.
- Governance nur auf Papier: Kontrollen sind dokumentiert, aber nicht im Projekt-Onboarding und Betrieb verankert.
Zielbild
Abschnitt betitelt „Zielbild“Die Netzwerkarchitektur regelt sichere Kommunikation, Segmentierung und die Governance zentraler Connectivity-Services über Shared und projektbezogene Landing Zones.
In Enterprise-Migrationen geht es dabei weniger um einzelne Subnetze, sondern um ein dauerhaft steuerbares Konnektivitätsmodell: welches Projekt über welche Pfade angebunden wird und unter welchen Guardrails.
Referenztopologie
Abschnitt betitelt „Referenztopologie“
Connectivity-Design und Delivery
Abschnitt betitelt „Connectivity-Design und Delivery“Kernbausteine der Connectivity
Abschnitt betitelt „Kernbausteine der Connectivity“- STACKIT Network Area: Nutzen Sie eine geteilte Unternehmens-Netzwerkscope als zentrales Rückgrat für Projektanbindung und Governance-Planung. Dokumentation
- Routing Tables: Definieren und erzwingen Sie, wie Projekte innerhalb einer Network Area verbunden sind und ob ein Hub-and-Spoke-Modell mit zentraler Firewall-Kontrolle oder eine flachere Topologie genutzt wird. Dokumentation
- DNS: Standardisieren Sie Namensgebung und Service Discovery frühzeitig, damit Connectivity-Design, Zertifikatshandling und Workload-Cutovers konsistent bleiben. Dokumentation
- VPN (Connectivity): Behandeln Sie VPN als zentrale Connectivity-Fähigkeit für Hybrid- und Multi-Cloud-Integrationsmuster, nicht als isolierte Einzellösung. Dokumentation
Wichtige Entscheidungen
Abschnitt betitelt „Wichtige Entscheidungen“- Network-Area-Ownership-Modell: Entscheiden Sie, wer geteilte Connectivity zentral steuert und welche Onboarding-Kriterien für angebundene Projekte gelten.
- Routing-Strategie je Domäne: Legen Sie fest, wo Hub-and-Spoke mit zentraler Inspektion verpflichtend ist und wo eine flache Routing-Topologie ausreicht.
- Hybrid-Connectivity-Baseline: Definieren Sie, wie VPN-basierte Konnektivität in Plattformstandards und Betriebs-Lifecycle integriert wird.
- Namensauflösungsdesign: Standardisieren Sie DNS-Grenzen und Muster für Plattformservices, Shared Services und Applikations-Landing-Zones.
Typische Ergebnisse
Abschnitt betitelt „Typische Ergebnisse“- Zieltopologie und Vertrauensgrenzen: Dokumentierter Zielzustand für Segmentierung und projektübergreifende Kommunikation.
- Network-Area-Onboarding-Prinzipien: Klare Kriterien, welche Projekte angebunden werden, wie Reviews ablaufen und wie Änderungen freigegeben werden.
- Routing-Governance-Modell: Definierter Einsatz von Routing Tables inklusive Entscheidungskriterien für Hub-and-Spoke versus flaches Routing.
- Connectivity-Baseline: Wiederverwendbare Standards für VPN, DNS und gemeinsame Netzwerk-Services.
Asset-Container-Referenz
Abschnitt betitelt „Asset-Container-Referenz“Asset-Titel
Framework
Asset-Typ
Migration
Software
Typische Anti-Patterns
Abschnitt betitelt „Typische Anti-Patterns“- Ungeplantes Wachstum der Network Area: Projekte werden ohne zentrale Architekturprüfung und Ownership angebunden.
- Ad-hoc-Einsatz von Routing Tables: Inkonsistente Routing-Logik je Projekt ohne Referenzarchitektur.
- DNS als Nachgedanke: Späte DNS-Entscheidungen bremsen Migrationstermine oder stören Service Discovery.
- VPN als Ausnahmepfad: VPN wird als Sonderlösung statt als geregelte Grundlage für die Konnektivität genutzt.
Accelerator-Architektur
Abschnitt betitelt „Accelerator-Architektur“
Übersicht
Abschnitt betitelt „Übersicht“Dieses Asset liefert eine wiederverwendbare Grundlage für die Umsetzung einer STACKIT Platform Landing Zone. Es ist für Enterprise-Umgebungen ausgelegt, die eine strukturierte Basis für Governance, Security, Netzwerk, Kostensteuerung und Automatisierung benötigen.
Repository:
Wie das Repository funktioniert
Abschnitt betitelt „Wie das Repository funktioniert“Das Repository ist als Single-Root-Module-Accelerator mit kombinierbaren Untermodulen aufgebaut.
- Das Root-Modul in
src/main.tforchestriert alle Plattform- und Landing-Zone-Bausteine. - Die Konfiguration erfolgt über flavor-spezifische Variablendateien in
src/config/. - Deployment ist mit OpenTofu oder Terraform möglich (identische Modulstruktur).
- Das erste Deployment nutzt einen temporären Bootstrap-Service-Account und wechselt danach auf Managed Backend und Managed Credentials.
Deployment-Flavors und ihr Umfang
Abschnitt betitelt „Deployment-Flavors und ihr Umfang“Das Repository enthält acht Referenzkonfigurationen in src/config/. Wählen Sie die einfachste
Topologie, die die erforderlichen Netzwerk-, Sicherheits-, Organisations-, Mandanten- und
Regionsgrenzen erfüllt.
Standalone
Abschnitt betitelt „Standalone“
Nutzen Sie standalone.tfvars für die kleinste Basis: Governance, Management, eine Sandbox und
eine öffentliche Application Landing Zone mit eigenem Netzwerk und direktem Internetzugang. Es
wird weder eine gemeinsame Network Area noch ein Connectivity-Hub erstellt. Das Muster eignet
sich, wenn Workloads keine private Ost-West-Kommunikation oder zentrales DNS benötigen.
Hub-and-Spoke
Abschnitt betitelt „Hub-and-Spoke“
Nutzen Sie hub-and-spoke.tfvars, wenn Corporate Workloads gemeinsame private Connectivity
benötigen. Ein zentrales Connectivity-Projekt stellt Network Area und DNS bereit, die Corporate
Data Platform nutzt diese private Domäne und öffentliche Workloads behalten unabhängige Netzwerke
mit direktem Internetzugang.
Hub-and-Spoke mit Firewall
Abschnitt betitelt „Hub-and-Spoke mit Firewall“
Nutzen Sie hub-and-spoke-firewall.tfvars, wenn Corporate Egress einen einheitlichen Inspektions-
und Kontrollpunkt benötigt. Das Muster erweitert die gemeinsame Network Area um eine
OPNsense-Firewall und führt die Default Routes der Corporate Landing Zones über die Appliance,
während öffentliche Landing Zones direkt angebunden bleiben.
Trennung von Finance und Research
Abschnitt betitelt „Trennung von Finance und Research“
Nutzen Sie hub-and-spoke-finance-research.tfvars, wenn Business Units unabhängige Ownership und
private Connectivity benötigen. Finance und Research erhalten innerhalb derselben STACKIT
Organisation jeweils einen eigenen Adressplan, ein Connectivity-Projekt, eine Network Area und
eine Workload Landing Zone.
Network Areas für regulierte und gemeinsame Workloads
Abschnitt betitelt „Network Areas für regulierte und gemeinsame Workloads“
Nutzen Sie hub-and-spoke-multi-area.tfvars, wenn regulierte und gemeinsame Workloads in
getrennten privaten Connectivity-Domänen liegen müssen. Jede Domäne erhält eine eigene Network
Area und DNS-Zone; zwischen ihnen besteht kein implizites Routing.
Unabhängige regionale Hubs
Abschnitt betitelt „Unabhängige regionale Hubs“
Nutzen Sie hub-and-spoke-multi-region.tfvars für regionale Basen in eu01 und eu02. Jede
Region erhält einen unabhängigen Hub, eine Network Area, eine Workload Landing Zone und optional
einen Platform-Kubernetes-Cluster. Interregionale Connectivity wird bewusst nicht erstellt und
muss explizit entworfen werden.
Isolation von Produktion und Nicht-Produktion
Abschnitt betitelt „Isolation von Produktion und Nicht-Produktion“
Nutzen Sie hub-and-spoke-prod-nonprod-firewall.tfvars, wenn Produktion von Nicht-Produktion
isoliert werden muss. Jede Domäne erhält eine eigene Network Area und OPNsense-Firewall;
Development und Test teilen die Nicht-Produktions-Domäne, bleiben aber getrennte Landing Zones.
Mandantenisolation
Abschnitt betitelt „Mandantenisolation“
Nutzen Sie hub-and-spoke-tenant-isolation.tfvars für mehrere Mandanten innerhalb einer
Organisation. Jeder Mandant erhält unabhängige Ownership, einen eigenen Adressplan, eine Network
Area, ein Connectivity-Projekt und eine Workload Landing Zone ohne privates Routing zu den anderen
Mandantendomänen.
Modul-für-Modul-Beschreibung
Abschnitt betitelt „Modul-für-Modul-Beschreibung“1. Governance-Modul (src/modules/governance)
Abschnitt betitelt „1. Governance-Modul (src/modules/governance)“Zweck:
- Erstellt die RM-Folder-Struktur (
platform,landing_zones_corporate,landing_zones_public,sandboxes). - Vergibt Folder-Owner- und Auditor-Rollen.
- Vergibt Organization-Owner- und Auditor-Rollen.
- Erstellt Custom Roles auf Organisationsebene.
Landing-Zone-Zuordnung:
- Platform Landing Zone: zentrale Governance-Basis.
2. Management-Modul (src/modules/management)
Abschnitt betitelt „2. Management-Modul (src/modules/management)“Zweck:
- Erstellt ein zentrales Management-Projekt.
- Provisioniert Secrets Manager und einen Default-Zugangsuser.
- Provisioniert Object-Storage-Buckets (inklusive tfstate-Bucket).
- Erstellt Object-Storage-Credentials und speichert sie im Secrets Manager.
- Erstellt Automation-Service-Account plus rotierende Keys und speichert den Key im Secrets Manager.
- Stellt optional Observability bereit und speichert die zugehörigen Zugangsdaten im Secrets Manager.
- Konfiguriert optional Federated Identity Provider für den Automation-Service-Account.
Landing-Zone-Zuordnung:
- Platform Landing Zone: gemeinsamer Operations- und Automatisierungs-Kontrollpfad.
3. Connectivity-Modul (src/modules/connectivity)
Abschnitt betitelt „3. Connectivity-Modul (src/modules/connectivity)“Zweck:
- Erstellt ein dediziertes Connectivity-Projekt.
- Erstellt Network Area und regionale Network-Area-Konfiguration.
- Erstellt DNS-Zonen für gemeinsame Namensräume.
- Stellt optional Firewall-Image, Volume, Server, Interfaces und Public IP bereit.
- Liefert die Firewall-Next-Hop-IP für Routen in Corporate Landing Zones.
Landing-Zone-Zuordnung:
- Platform Landing Zone: gemeinsame Netzwerk- und Routing-Basis.
4. DevOps-Modul (src/modules/devops)
Abschnitt betitelt „4. DevOps-Modul (src/modules/devops)“Zweck:
- Erstellt ein dediziertes DevOps-Projekt.
- Erstellt optional eine zentrale STACKIT Git-Instanz mit ACL-Ranges.
Landing-Zone-Zuordnung:
- Platform Landing Zone in der Architektur dieses Accelerators.
- Begründung: Das Modul liefert zentrale Delivery-Tooling-Grundlagen und Source-Control-Kapazität für mehrere Landing Zones.
5. Landing-Zone-Modul (src/modules/landing-zone)
Abschnitt betitelt „5. Landing-Zone-Modul (src/modules/landing-zone)“Zweck:
- Erstellt anwendungsnahe Landing-Zone-Projekte iterativ über
for_each. - Unterstützt corporate Landing Zones (an Network Area angebunden) und public Landing Zones.
- Erstellt geroutete Netzwerke und optional Default-Route über Firewall-Next-Hop.
- Erstellt optional projektbezogene Child-DNS-Zonen.
- Erstellt projektbezogene Custom Roles und Role Assignments.
- Erstellt Secrets Manager, Object-Storage-Buckets und Automation-Service-Account-Key-Material pro Landing Zone.
Landing-Zone-Zuordnung:
- Application Landing Zone: zentrales ALZ-Umsetzungsmodul.
6. Sandboxes-Modul (src/modules/sandboxes)
Abschnitt betitelt „6. Sandboxes-Modul (src/modules/sandboxes)“Zweck:
- Erstellt schlanke Sandbox-Projekte im dedizierten
sandboxes-Folder. - Vergibt Project-Owner.
Landing-Zone-Zuordnung:
- Application Landing Zone (unterstützend): nicht-produktive Testumgebung nahe ALZ-Nutzungsmustern.
Neu umgesetzter Umfang in diesem Asset
Abschnitt betitelt „Neu umgesetzter Umfang in diesem Asset“Die aktuelle Umsetzung enthält jetzt einen durchgängigen Pfad für eine zentrale Kubernetes-Plattform und ein namespace-basiertes Application-Onboarding.
Platform Landing Zone für zentrales Kubernetes
Abschnitt betitelt „Platform Landing Zone für zentrales Kubernetes“Der Platform-Umfang enthält jetzt eine dedizierte zentrale Kubernetes-Basis, die als geteilter Platform-Service betrieben werden kann.
- Zentrale Cluster-Basis: Ein dediziertes Platform-Kubernetes-Projekt mit SKE-Cluster-Life-cycle, DNS-Extension-Integration und optionaler Observability-Anbindung.
- Secret-Policy-Readiness: Namespace-bezogenes Secret-Manager-Policy-Enforcement unterstützt schrittweise Rollout-Modi wie audit und strict.
- Shared-Service-Modell: Plattform-Teams können zentrale Fähigkeiten bereitstellen und gleichzeitig klare Projekt- und Namespace-Grenzen beibehalten.
- Betriebs-Basis: Cluster-bezogene Outputs und Informationen zum Zugriff stehen für Automatisierung und kontrollierte Plattform-Operationen bereit.
Application Landing Zone für Namespace-Tenants
Abschnitt betitelt „Application Landing Zone für Namespace-Tenants“Application Landing Zones können jetzt den Namespace-Service aus dem zentralen Platform-Kubernetes-Cluster nutzen.
- Namespace-Onboarding: Die Landing-Zone-Konfiguration kann die Namespace-Erstellung für ein Team im Shared Cluster anfordern.
- Developer-Zugriffspfad: Namespace-spezifische Kubernetes-User und Role-Bindings werden für Tenant-Operationen bereitgestellt.
- Service-Exposition: DNS- und Ingress-Muster sind für Service-Endpunkte auf Basis von Landing-Zone- und Namespace-Kontext vorkonfiguriert.
- Secret-Integration: Workloads können zentral gesteuerte Secret-Flows konsumieren und bleiben dabei im Namespace-Umfang.
Zusätzliche Plattform-Features in diesem Setup
Abschnitt betitelt „Zusätzliche Plattform-Features in diesem Setup“- External-DNS-Automatisierung: DNS-Einträge für Namespace-Services werden über Kubernetes-Annotationen und Extension-Zone-Integration verwaltet.
- Zentrales Kubernetes-Monitoring: Die Plattform-Observability-Integration umfasst Grafana-Zugang und Metrics-Push-Wiring für Cluster-Telemetrie.
- Dashboard-Provisioning-Workflow: Beispiel-Dashboards werden für eine schnellere operative Übergabe provisioniert und importiert.
- Option für Encrypted Volumes: Unterstützung für verschlüsselte Volume-Muster hilft bei strengeren Datenschutz- und Compliance-Anforderungen.
- Flexibles Netzwerk-Setup: Das Platform-Kubernetes-Modul unterstützt SNA-orientierte Netzwerk-Setups für kontrollierte Enterprise-Konnektivität.
Was Entwickler in einer Application Landing Zone bekommen
Abschnitt betitelt „Was Entwickler in einer Application Landing Zone bekommen“- Sofort nutzbarer Namespace: Ein vorkonfigurierter Namespace im zentralen Cluster statt eines vollständigen Cluster-pro-Team-Modells.
- Least-Privilege-Zugriff: Namespace-bezogene Identitäten und Berechtigungen passend zu typischen Day-2-Developer-Aufgaben.
- Konsistentes Endpunkt-Modell: Vorhersehbare DNS- und Ingress-Muster für die Service-Veröffentlichung.
- Governed Secret Usage: Zentrale Secret-Governance mit Namespace-bezogenen Mustern zur Nutzung.
- Observability-Transparenz: Gemeinsame Metrik- und Dashboard-Sichten helfen Teams bei Rollout und Validierung im Betrieb.
Platform vs Application Landing Zone Umfang in diesem Repository
Abschnitt betitelt „Platform vs Application Landing Zone Umfang in diesem Repository“- Platform Landing Zone Fokus (derzeit der größere Umfang):
governancemanagementconnectivitydevops
- Application Landing Zone Umfang (derzeit fokussierter):
landing-zone(ALZ-Kernprovisionierung)sandboxes(unterstützende ALZ-nahe Umgebungen)
Damit liefert das Repository aktuell primär eine starke Plattform-Basis, während ALZ-Funktionalität bewusst auf Landing-Zone-Instanziierung und Sandbox-Enabling fokussiert ist.
Einsatz im Migrationsprogramm
Abschnitt betitelt „Einsatz im Migrationsprogramm“- Plattform-Basis früh starten (Governance, Management, Connectivity, optional DevOps).
- Corporate- vs Public-ALZ-Muster anhand von Connectivity- und Compliance-Anforderungen definieren.
- Application Landing Zones über die
landing_zones-Map in Variablendateien bereitstellen. - Sandboxes für Team-Onboarding und kontrollierte frühe Experimente nutzen.
- Nach erstem Apply State in das Managed Backend migrieren und von Bootstrap-Credentials auf Managed Automation-Credentials wechseln.
Inhalt des Assets
Abschnitt betitelt „Inhalt des Assets“- Wiederverwendbare Basismodule: Bausteine für Account-/Projektstruktur, IAM, Netzwerk und Kontrollen.
- Policy-orientiertes Setup: Leitplanken und Konventionen für sichere und steuerbare Cloud-Nutzung.
- IaC-First-Ansatz: OpenTofu/Terraform als Modell für wiederholbare Bereitstellung.
- Erweiterbar für Enterprise-Bedarf: Bewusst als Basis für kundenspezifische Anpassungen ausgelegt.
Typischer Einsatz im Migrationsprogramm
Abschnitt betitelt „Typischer Einsatz im Migrationsprogramm“- Früher Plattform-Stream: Aufbau parallel zum Discovery starten.
- Kontrollbasis vor produktiver Migration: Pflichtkontrollen vor dem ersten produktiven Move etablieren.
- Template-Quelle für Application Landing Zones: Basismodule für Workload-Archetypen wiederverwenden und verfeinern.
Empfohlene Voraussetzungen
Abschnitt betitelt „Empfohlene Voraussetzungen“- Organisations- und Ownership-Modell für Projekte und Umgebungen.
- Security- und Compliance-Vorgaben (Identität, Logging, Nachweise, Segmentierung).
- Konnektivitäts- und Integrationsanforderungen.
- Betriebsmodell-Abstimmung zwischen Plattform-, Security- und Applikationsteams.
Target Operating Model
Geben Sie dem Target Operating Model einen eigenen Moment: Es legt fest, wie die Plattform betrieben, besetzt und gesteuert wird, sobald Workloads gelandet sind.
Das Target Operating Model (TOM) definiert, wie eine Organisation ihre Cloud-Umgebung nach der Migration betreibt. Es überführt die technische Grundlage der STACKIT Landing Zone in klare Ownership, wiederholbare Prozesse und messbare Ergebnisse.
Das Modell beschreibt die gemeinsame Verantwortung von Plattform- und Workload-Teams, Security, Service Management und Fachbereichen. Es sollte vor dem Start der Migrationswellen entwickelt und mit der Übernahme weiterer Workloads fortlaufend geschärft werden.
TOM-Fähigkeitsbereiche
Abschnitt betitelt „TOM-Fähigkeitsbereiche“Governance und Entscheidungsfindung
Legen Sie Entscheidungsrechte, Architektur- und Security-Reviews, Ausnahmeverfahren und Eskalationswege fest. Mehr unter Governance und Entscheidungsfindung.
Rollen und Verantwortlichkeiten
Definieren Sie klare Ownership für Plattform, Anwendungen, Security, FinOps und Service Management. Mehr unter Rollen und Verantwortlichkeiten.
Service Management und Betrieb
Verankern Sie Incident-, Change-, Problem-, Request- und Übergabeprozesse im Betrieb. Mehr unter Service Management und Betrieb.
Plattformteam und Enablement
Betreiben Sie die STACKIT-Plattformgrundlage als internes Produkt mit wiederverwendbaren Guardrails und Self-Service-Pfaden. Mehr unter Plattformteam und Enablement.
Fähigkeiten und Change Management
Entwickeln Sie Fähigkeiten, Adoption-Praktiken und Kommunikationsroutinen für neue Cloud-Verantwortlichkeiten. Mehr unter Fähigkeiten und Change Management.
Messung und kontinuierliche Verbesserung
Nutzen Sie Signale zu Zuverlässigkeit, Delivery, Security und Kosten zur Verbesserung von Plattform und Workloads. Mehr unter Messung und kontinuierliche Verbesserung.
Verbindung zur Landing Zone
Abschnitt betitelt „Verbindung zur Landing Zone“Die Landing Zone stellt technische Guardrails für Identität, Netzwerk, Security, Kostenkontrolle und Automatisierung bereit. Das TOM legt fest, wer diese Guardrails verantwortet und nutzt und wie Änderungen, Ausnahmen und Betriebsrisiken gesteuert werden. Es ersetzt nicht die Verantwortlichkeiten von STACKIT als Provider, sondern beschreibt das kundenseitige Betriebsmodell für die konfigurierte Plattform und migrierte Workloads.
Verbundene Framework-Inhalte
Abschnitt betitelt „Verbundene Framework-Inhalte“- Landing Zones beschreibt die technische Plattformgrundlage und Guardrails.
- Account Governance beschreibt Grenzen von Customer Account, Folder, Projects und Delegation.
- Cost Management und Control liefert Kostenallokation, Budgetierung und FinOps-Praktiken.
- Security und Compliance: Betriebsmodell und Steuerung definiert Kontrollverantwortung und Security-Prüfpunkte.
- Migration Factory: Runbook Readiness und Übergabe definiert das operative Übergabepaket pro Migrationswelle.
- Enablement liefert Lernpfade und Referenzmaterial zur Adoption des Zielmodells.
Umsetzungsschritte
Abschnitt betitelt „Umsetzungsschritte“- Bewerten Sie das bestehende Betriebsmodell, Supportprozesse, Fähigkeiten und Ownership-Lücken.
- Definieren Sie Zielverantwortungen, Entscheidungsrechte und Schnittstellen für STACKIT-Plattform- und Workload-Teams.
- Stimmen Sie Service-Management-Prozesse, Supportgrenzen und Übergabekriterien auf die ersten Migrationswellen ab.
- Etablieren Sie das Plattformproduktmodell, Enablement-Pfade und betriebliche Dokumentation.
- Messen Sie Adoption und Betriebsergebnisse und entwickeln Sie das Modell mit den Migrationswellen weiter.
Zugehörige Assets
Abschnitt betitelt „Zugehörige Assets“Asset-Titel
Framework
Asset-Typ
Enablement
Zeigen Sie, wie aus Readiness-Befunden ein wirksames Enablement-System entsteht: CCoE-Verantwortung, rollenbasiertes STACKIT-Lernen und verlässliche Dokumentation mit KI-gestützter Orientierung.
Übersicht
Abschnitt betitelt „Übersicht“Enablement für die Cloud-Migration überführt Zielarchitektur und Migrationsplan in eine wiederholbare Delivery-Fähigkeit. Teams erhalten die Befugnisse, Kompetenzen, praktische Erfahrung und verlässlichen Informationen, die sie für eigenständige Entscheidungen benötigen.
Das Readiness Assessment bildet den Ausgangspunkt. Fragebogen und Workshops machen organisatorische und technische Lücken sichtbar. Die Readiness-Scorecard über fünf Dimensionen zeigt, welche Rollen, Kontrollen, Finanzmittel und Plattformfähigkeiten vorhanden sein müssen. Priorisieren Sie mit diesen Ergebnissen die folgenden drei Enablement-Kapitel.
- Verantwortlichkeiten für Migrationsstandards, Entscheidungen und Kompetenzentwicklung zuweisen.
- Readiness- und Rollenlücken passenden Lernpfaden, Workshops und praktischen Übungen zuordnen.
- Verbindliche Dokumentation, Migrationsentscheidungen und wiederverwendbare Referenzen kuratieren.
- Fähigkeiten vor jeder Welle prüfen und Erkenntnisse in alle drei Bereiche zurückführen.
Center of Excellence
Abschnitt betitelt „Center of Excellence“Das Cloud Center of Excellence (CCoE) verantwortet das Enablement-System über alle Migrationswellen hinweg. Es definiert Guardrails und Referenzmuster, verbindet Plattform- und Workload-Teams, pflegt den Kompetenzplan und macht Erkenntnisse aus der Delivery als Wissen für die Organisation wiederverwendbar. Dabei befähigt es dezentrale Delivery, statt zum Freigabeengpass zu werden.
Etablieren Sie das CCoE mit einem klaren Mandat, einer unterzeichneten Charta, passenden Strukturen und Rollen, einem schrittweisen Rollout und einem föderierten Betriebsmodell, das über Delivery-Teams hinweg skaliert.
Während einer Migration sollte das CCoE:
- Readiness-Befunde in verantwortete Maßnahmen für Behebung und Enablement überführen;
- festlegen, welche Standards verbindlich sind und wo Teams selbst entscheiden können;
- freigegebene Muster für Landing Zones, Architektur, Sicherheit, FinOps und Betrieb pflegen;
- rollenbasiertes Lernen mit dem Bedarf der Migrationswellen koordinieren;
- Sprechstunden, Coaching und Eskalationswege für Delivery-Teams anbieten;
- Feedback, Ausnahmen und bewährte Praktiken aus jeder Welle erfassen.
Trainings & Lernpfade
Abschnitt betitelt „Trainings & Lernpfade“Trainings sollten sich an Migrationsrollen und anstehenden Aufgaben orientieren, nicht an einem allgemeinen Kurskalender. Beginnen Sie mit den Kompetenzlücken aus den Readiness-Workshops und planen Sie Lernmaßnahmen so früh, dass Teilnehmende üben können, bevor sie Verantwortung für Design, Migration, Übergabe oder Betrieb übernehmen.
Nutzen Sie einen mehrstufigen Lernpfad:
- Gemeinsames Verständnis schaffen: STACKIT Introduction, Portal und Portfolio vermitteln Geschäfts-, Architektur-, Delivery-, Sicherheits- und Betriebsrollen ein gemeinsames Plattformvokabular.
- Rollenwissen vertiefen: Rollenbasierte Selbstlernprogramme für Cloud Engineers, Security Engineers, Data Engineers, AI Engineers, Cloud Product Owner, Business-Rollen und Partner zuweisen.
- Migrationsaufgaben üben: Praktische Deep Dives für Cloud Engineering, Architektur und Kubernetes-Sicherheit passend zu Ziel-Workloads und Wellenverantwortung ergänzen.
- Spezifische Lücken schließen: Expert Sessions für Themen wie IAM, Netzwerk, FinOps, LLM-Hosting, Sicherheit oder die Übergabe des Betriebsmodells nutzen.
- Readiness nachweisen: Praktische Nachweise wie ein geprüftes Design, eine Deployment-Übung, einen Runbook-Walkthrough, ein Incident-Szenario oder eine erfolgreiche Übergabeprobe verlangen.
Die STACKIT University ist die zentrale Lernplattform für Kunden und Partner. Sie bietet Selbstlernprogramme, Kurse mit professionellen Zertifikaten, Webinare, Workshops und Expert Sessions. Für den Zugriff ist ein STACKIT-Benutzerkonto erforderlich; praktische Übungen können zusätzlich ein Kundenkonto und eine Organisation voraussetzen.
STACKIT University öffnen Dokumentation öffnenVerfügbare Trainings-Assets
Abschnitt betitelt „Verfügbare Trainings-Assets“Die Trainings-Assets bündeln aktuelle Kurse, Workshops, Zertifizierungen und Expertenformate für unterschiedliche Rollen und Erfahrungsstufen.
Asset-Titel
Framework
Asset-Typ
Dokumentation & Referenz
Abschnitt betitelt „Dokumentation & Referenz“Erstellen Sie für jede Migrationsrolle einen verlässlichen Referenzpfad. Verknüpfen Sie die verbindliche STACKIT-Produktdokumentation mit migrationsspezifischen Entscheidungen und Nachweisen, statt Produktanleitungen in Projektdokumente zu kopieren, die schnell veralten.
Nutzen Sie das Referenzsystem für:
- verbindliches Produktverhalten, Voraussetzungen, Grenzen, Release-Informationen und Betriebsanleitungen;
- Plattform- und Entwicklerwerkzeuge einschließlich APIs, CLI, SDKs und Infrastructure-as-Code-Providern;
- freigegebene Zielmuster, Architekturentscheidungen, Kontrollen und Ausnahmen;
- Runbooks, Validierungsnachweise, Übergabeprotokolle und bekannte Probleme jeder Migrationswelle;
- eindeutige Verantwortlichkeiten, Prüftermine und Links zur verbindlichen Quelle.
STACKIT Docs Dokumentation öffnen Erste Schritte Dokumentation öffnen Produkte Dokumentation öffnen Entwicklerwerkzeuge Dokumentation öffnen
Die Cloud-Reise gemeinsam erklären
Abschnitt betitelt „Die Cloud-Reise gemeinsam erklären“Nutzen Sie den illustrierten Cloud-Journey-Leitfaden bei Kick-offs und ersten Gesprächen mit Fachbereichen und Menschen ohne Cloud-Vorwissen. Das Wimmelbild und der Gesprächsleitfaden für fünf Minuten verbinden Orientierung, Vorbereitung, Migration und Betrieb mit dem Framework.
KI-gestütztes Enablement
Abschnitt betitelt „KI-gestütztes Enablement“KI kann Service-Mapping, Architekturvarianten, Terraform-Entwürfe und die Navigation durch technische Referenzen beschleunigen. Behandeln Sie generierte Ergebnisse als Entscheidungsunterstützung: Verlangen Sie Quellenangaben, schützen Sie Kundendaten und lassen Sie die Ergebnisse von qualifizierten Verantwortlichen aus Architektur, Sicherheit, Betrieb und Migration validieren, bevor sie in Design- oder Umsetzungsartefakte einfließen.
CloudMent ist das zentrale KI-gestützte Migrations-Asset in diesem Modul. Es verbindet strukturierte Assessment-Artefakte mit interaktiver STACKIT-Beratung und verankert Empfehlungen zur fachlichen Prüfung in der STACKIT-Dokumentation.
Verfügbare Enablement-Assets
Abschnitt betitelt „Verfügbare Enablement-Assets“Entdecken Sie den visuellen Gesprächsleitfaden und die KI-gestützte Beratung in den folgenden Assets.
Asset-Titel
Framework
Asset-Typ
Migration
Software
Migration
Anleitung
Die Anleitung zu Skills und Change Management verbindet diese Enablement-Maßnahmen mit Rollenverantwortung, Adoption und dem Target Operating Model.
Übersicht
Abschnitt betitelt „Übersicht“Enablement für die Cloud-Migration überführt Zielarchitektur und Migrationsplan in eine wiederholbare Delivery-Fähigkeit. Teams erhalten die Befugnisse, Kompetenzen, praktische Erfahrung und verlässlichen Informationen, die sie für eigenständige Entscheidungen benötigen.
Das Readiness Assessment bildet den Ausgangspunkt. Fragebogen und Workshops machen organisatorische und technische Lücken sichtbar. Die Readiness-Scorecard über fünf Dimensionen zeigt, welche Rollen, Kontrollen, Finanzmittel und Plattformfähigkeiten vorhanden sein müssen. Priorisieren Sie mit diesen Ergebnissen die folgenden drei Enablement-Kapitel.
- Verantwortlichkeiten für Migrationsstandards, Entscheidungen und Kompetenzentwicklung zuweisen.
- Readiness- und Rollenlücken passenden Lernpfaden, Workshops und praktischen Übungen zuordnen.
- Verbindliche Dokumentation, Migrationsentscheidungen und wiederverwendbare Referenzen kuratieren.
- Fähigkeiten vor jeder Welle prüfen und Erkenntnisse in alle drei Bereiche zurückführen.
Center of Excellence
Abschnitt betitelt „Center of Excellence“Das Cloud Center of Excellence (CCoE) verantwortet das Enablement-System über alle Migrationswellen hinweg. Es definiert Guardrails und Referenzmuster, verbindet Plattform- und Workload-Teams, pflegt den Kompetenzplan und macht Erkenntnisse aus der Delivery als Wissen für die Organisation wiederverwendbar. Dabei befähigt es dezentrale Delivery, statt zum Freigabeengpass zu werden.
Etablieren Sie das CCoE mit einem klaren Mandat, einer unterzeichneten Charta, passenden Strukturen und Rollen, einem schrittweisen Rollout und einem föderierten Betriebsmodell, das über Delivery-Teams hinweg skaliert.
Während einer Migration sollte das CCoE:
- Readiness-Befunde in verantwortete Maßnahmen für Behebung und Enablement überführen;
- festlegen, welche Standards verbindlich sind und wo Teams selbst entscheiden können;
- freigegebene Muster für Landing Zones, Architektur, Sicherheit, FinOps und Betrieb pflegen;
- rollenbasiertes Lernen mit dem Bedarf der Migrationswellen koordinieren;
- Sprechstunden, Coaching und Eskalationswege für Delivery-Teams anbieten;
- Feedback, Ausnahmen und bewährte Praktiken aus jeder Welle erfassen.
Trainings & Lernpfade
Abschnitt betitelt „Trainings & Lernpfade“Trainings sollten sich an Migrationsrollen und anstehenden Aufgaben orientieren, nicht an einem allgemeinen Kurskalender. Beginnen Sie mit den Kompetenzlücken aus den Readiness-Workshops und planen Sie Lernmaßnahmen so früh, dass Teilnehmende üben können, bevor sie Verantwortung für Design, Migration, Übergabe oder Betrieb übernehmen.
Nutzen Sie einen mehrstufigen Lernpfad:
- Gemeinsames Verständnis schaffen: STACKIT Introduction, Portal und Portfolio vermitteln Geschäfts-, Architektur-, Delivery-, Sicherheits- und Betriebsrollen ein gemeinsames Plattformvokabular.
- Rollenwissen vertiefen: Rollenbasierte Selbstlernprogramme für Cloud Engineers, Security Engineers, Data Engineers, AI Engineers, Cloud Product Owner, Business-Rollen und Partner zuweisen.
- Migrationsaufgaben üben: Praktische Deep Dives für Cloud Engineering, Architektur und Kubernetes-Sicherheit passend zu Ziel-Workloads und Wellenverantwortung ergänzen.
- Spezifische Lücken schließen: Expert Sessions für Themen wie IAM, Netzwerk, FinOps, LLM-Hosting, Sicherheit oder die Übergabe des Betriebsmodells nutzen.
- Readiness nachweisen: Praktische Nachweise wie ein geprüftes Design, eine Deployment-Übung, einen Runbook-Walkthrough, ein Incident-Szenario oder eine erfolgreiche Übergabeprobe verlangen.
Die STACKIT University ist die zentrale Lernplattform für Kunden und Partner. Sie bietet Selbstlernprogramme, Kurse mit professionellen Zertifikaten, Webinare, Workshops und Expert Sessions. Für den Zugriff ist ein STACKIT-Benutzerkonto erforderlich; praktische Übungen können zusätzlich ein Kundenkonto und eine Organisation voraussetzen.
STACKIT University öffnen Dokumentation öffnenVerfügbare Trainings-Assets
Abschnitt betitelt „Verfügbare Trainings-Assets“Die Trainings-Assets bündeln aktuelle Kurse, Workshops, Zertifizierungen und Expertenformate für unterschiedliche Rollen und Erfahrungsstufen.
Asset-Titel
Framework
Asset-Typ
Dokumentation & Referenz
Abschnitt betitelt „Dokumentation & Referenz“Erstellen Sie für jede Migrationsrolle einen verlässlichen Referenzpfad. Verknüpfen Sie die verbindliche STACKIT-Produktdokumentation mit migrationsspezifischen Entscheidungen und Nachweisen, statt Produktanleitungen in Projektdokumente zu kopieren, die schnell veralten.
Nutzen Sie das Referenzsystem für:
- verbindliches Produktverhalten, Voraussetzungen, Grenzen, Release-Informationen und Betriebsanleitungen;
- Plattform- und Entwicklerwerkzeuge einschließlich APIs, CLI, SDKs und Infrastructure-as-Code-Providern;
- freigegebene Zielmuster, Architekturentscheidungen, Kontrollen und Ausnahmen;
- Runbooks, Validierungsnachweise, Übergabeprotokolle und bekannte Probleme jeder Migrationswelle;
- eindeutige Verantwortlichkeiten, Prüftermine und Links zur verbindlichen Quelle.
STACKIT Docs Dokumentation öffnen Erste Schritte Dokumentation öffnen Produkte Dokumentation öffnen Entwicklerwerkzeuge Dokumentation öffnen
Die Cloud-Reise gemeinsam erklären
Abschnitt betitelt „Die Cloud-Reise gemeinsam erklären“Nutzen Sie den illustrierten Cloud-Journey-Leitfaden bei Kick-offs und ersten Gesprächen mit Fachbereichen und Menschen ohne Cloud-Vorwissen. Das Wimmelbild und der Gesprächsleitfaden für fünf Minuten verbinden Orientierung, Vorbereitung, Migration und Betrieb mit dem Framework.
KI-gestütztes Enablement
Abschnitt betitelt „KI-gestütztes Enablement“KI kann Service-Mapping, Architekturvarianten, Terraform-Entwürfe und die Navigation durch technische Referenzen beschleunigen. Behandeln Sie generierte Ergebnisse als Entscheidungsunterstützung: Verlangen Sie Quellenangaben, schützen Sie Kundendaten und lassen Sie die Ergebnisse von qualifizierten Verantwortlichen aus Architektur, Sicherheit, Betrieb und Migration validieren, bevor sie in Design- oder Umsetzungsartefakte einfließen.
CloudMent ist das zentrale KI-gestützte Migrations-Asset in diesem Modul. Es verbindet strukturierte Assessment-Artefakte mit interaktiver STACKIT-Beratung und verankert Empfehlungen zur fachlichen Prüfung in der STACKIT-Dokumentation.
Verfügbare Enablement-Assets
Abschnitt betitelt „Verfügbare Enablement-Assets“Entdecken Sie den visuellen Gesprächsleitfaden und die KI-gestützte Beratung in den folgenden Assets.
Asset-Titel
Framework
Asset-Typ
Migration
Software
Migration
Anleitung
Die Anleitung zu Skills und Change Management verbindet diese Enablement-Maßnahmen mit Rollenverantwortung, Adoption und dem Target Operating Model.
Dokumentation und Referenz
Schaffen Sie für jede Migrationsrolle einen verlässlichen Referenzpfad aus verbindlicher STACKIT-Produktdokumentation, Migrationsentscheidungen und Nachweisen.
Übersicht
Abschnitt betitelt „Übersicht“Enablement für die Cloud-Migration überführt Zielarchitektur und Migrationsplan in eine wiederholbare Delivery-Fähigkeit. Teams erhalten die Befugnisse, Kompetenzen, praktische Erfahrung und verlässlichen Informationen, die sie für eigenständige Entscheidungen benötigen.
Das Readiness Assessment bildet den Ausgangspunkt. Fragebogen und Workshops machen organisatorische und technische Lücken sichtbar. Die Readiness-Scorecard über fünf Dimensionen zeigt, welche Rollen, Kontrollen, Finanzmittel und Plattformfähigkeiten vorhanden sein müssen. Priorisieren Sie mit diesen Ergebnissen die folgenden drei Enablement-Kapitel.
- Verantwortlichkeiten für Migrationsstandards, Entscheidungen und Kompetenzentwicklung zuweisen.
- Readiness- und Rollenlücken passenden Lernpfaden, Workshops und praktischen Übungen zuordnen.
- Verbindliche Dokumentation, Migrationsentscheidungen und wiederverwendbare Referenzen kuratieren.
- Fähigkeiten vor jeder Welle prüfen und Erkenntnisse in alle drei Bereiche zurückführen.
Center of Excellence
Abschnitt betitelt „Center of Excellence“Das Cloud Center of Excellence (CCoE) verantwortet das Enablement-System über alle Migrationswellen hinweg. Es definiert Guardrails und Referenzmuster, verbindet Plattform- und Workload-Teams, pflegt den Kompetenzplan und macht Erkenntnisse aus der Delivery als Wissen für die Organisation wiederverwendbar. Dabei befähigt es dezentrale Delivery, statt zum Freigabeengpass zu werden.
Etablieren Sie das CCoE mit einem klaren Mandat, einer unterzeichneten Charta, passenden Strukturen und Rollen, einem schrittweisen Rollout und einem föderierten Betriebsmodell, das über Delivery-Teams hinweg skaliert.
Während einer Migration sollte das CCoE:
- Readiness-Befunde in verantwortete Maßnahmen für Behebung und Enablement überführen;
- festlegen, welche Standards verbindlich sind und wo Teams selbst entscheiden können;
- freigegebene Muster für Landing Zones, Architektur, Sicherheit, FinOps und Betrieb pflegen;
- rollenbasiertes Lernen mit dem Bedarf der Migrationswellen koordinieren;
- Sprechstunden, Coaching und Eskalationswege für Delivery-Teams anbieten;
- Feedback, Ausnahmen und bewährte Praktiken aus jeder Welle erfassen.
Trainings & Lernpfade
Abschnitt betitelt „Trainings & Lernpfade“Trainings sollten sich an Migrationsrollen und anstehenden Aufgaben orientieren, nicht an einem allgemeinen Kurskalender. Beginnen Sie mit den Kompetenzlücken aus den Readiness-Workshops und planen Sie Lernmaßnahmen so früh, dass Teilnehmende üben können, bevor sie Verantwortung für Design, Migration, Übergabe oder Betrieb übernehmen.
Nutzen Sie einen mehrstufigen Lernpfad:
- Gemeinsames Verständnis schaffen: STACKIT Introduction, Portal und Portfolio vermitteln Geschäfts-, Architektur-, Delivery-, Sicherheits- und Betriebsrollen ein gemeinsames Plattformvokabular.
- Rollenwissen vertiefen: Rollenbasierte Selbstlernprogramme für Cloud Engineers, Security Engineers, Data Engineers, AI Engineers, Cloud Product Owner, Business-Rollen und Partner zuweisen.
- Migrationsaufgaben üben: Praktische Deep Dives für Cloud Engineering, Architektur und Kubernetes-Sicherheit passend zu Ziel-Workloads und Wellenverantwortung ergänzen.
- Spezifische Lücken schließen: Expert Sessions für Themen wie IAM, Netzwerk, FinOps, LLM-Hosting, Sicherheit oder die Übergabe des Betriebsmodells nutzen.
- Readiness nachweisen: Praktische Nachweise wie ein geprüftes Design, eine Deployment-Übung, einen Runbook-Walkthrough, ein Incident-Szenario oder eine erfolgreiche Übergabeprobe verlangen.
Die STACKIT University ist die zentrale Lernplattform für Kunden und Partner. Sie bietet Selbstlernprogramme, Kurse mit professionellen Zertifikaten, Webinare, Workshops und Expert Sessions. Für den Zugriff ist ein STACKIT-Benutzerkonto erforderlich; praktische Übungen können zusätzlich ein Kundenkonto und eine Organisation voraussetzen.
STACKIT University öffnen Dokumentation öffnenVerfügbare Trainings-Assets
Abschnitt betitelt „Verfügbare Trainings-Assets“Die Trainings-Assets bündeln aktuelle Kurse, Workshops, Zertifizierungen und Expertenformate für unterschiedliche Rollen und Erfahrungsstufen.
Asset-Titel
Framework
Asset-Typ
Dokumentation & Referenz
Abschnitt betitelt „Dokumentation & Referenz“Erstellen Sie für jede Migrationsrolle einen verlässlichen Referenzpfad. Verknüpfen Sie die verbindliche STACKIT-Produktdokumentation mit migrationsspezifischen Entscheidungen und Nachweisen, statt Produktanleitungen in Projektdokumente zu kopieren, die schnell veralten.
Nutzen Sie das Referenzsystem für:
- verbindliches Produktverhalten, Voraussetzungen, Grenzen, Release-Informationen und Betriebsanleitungen;
- Plattform- und Entwicklerwerkzeuge einschließlich APIs, CLI, SDKs und Infrastructure-as-Code-Providern;
- freigegebene Zielmuster, Architekturentscheidungen, Kontrollen und Ausnahmen;
- Runbooks, Validierungsnachweise, Übergabeprotokolle und bekannte Probleme jeder Migrationswelle;
- eindeutige Verantwortlichkeiten, Prüftermine und Links zur verbindlichen Quelle.
STACKIT Docs Dokumentation öffnen Erste Schritte Dokumentation öffnen Produkte Dokumentation öffnen Entwicklerwerkzeuge Dokumentation öffnen
Die Cloud-Reise gemeinsam erklären
Abschnitt betitelt „Die Cloud-Reise gemeinsam erklären“Nutzen Sie den illustrierten Cloud-Journey-Leitfaden bei Kick-offs und ersten Gesprächen mit Fachbereichen und Menschen ohne Cloud-Vorwissen. Das Wimmelbild und der Gesprächsleitfaden für fünf Minuten verbinden Orientierung, Vorbereitung, Migration und Betrieb mit dem Framework.
KI-gestütztes Enablement
Abschnitt betitelt „KI-gestütztes Enablement“KI kann Service-Mapping, Architekturvarianten, Terraform-Entwürfe und die Navigation durch technische Referenzen beschleunigen. Behandeln Sie generierte Ergebnisse als Entscheidungsunterstützung: Verlangen Sie Quellenangaben, schützen Sie Kundendaten und lassen Sie die Ergebnisse von qualifizierten Verantwortlichen aus Architektur, Sicherheit, Betrieb und Migration validieren, bevor sie in Design- oder Umsetzungsartefakte einfließen.
CloudMent ist das zentrale KI-gestützte Migrations-Asset in diesem Modul. Es verbindet strukturierte Assessment-Artefakte mit interaktiver STACKIT-Beratung und verankert Empfehlungen zur fachlichen Prüfung in der STACKIT-Dokumentation.
Verfügbare Enablement-Assets
Abschnitt betitelt „Verfügbare Enablement-Assets“Entdecken Sie den visuellen Gesprächsleitfaden und die KI-gestützte Beratung in den folgenden Assets.
Asset-Titel
Framework
Asset-Typ
Migration
Software
Migration
Anleitung
Die Anleitung zu Skills und Change Management verbindet diese Enablement-Maßnahmen mit Rollenverantwortung, Adoption und dem Target Operating Model.
Übersicht
Abschnitt betitelt „Übersicht“CloudMent AI-Powered Cloud Advisor unterstützt Migrationsteams in Assess sowie Design and Mobilize. Die Lösung kombiniert CloudMent Deck für strukturierte Assessment-Ergebnisse mit CloudMent Essential für interaktive STACKIT Beratung.
Architekten und Portfolio-Teams können Anforderungen erfassen, Services aus der Ausgangslage auf STACKIT Optionen abbilden, R-Strategien auswählen, Zielbilder entwerfen und STACKIT Laufkosten abschätzen. Empfehlungen basieren auf STACKIT Dokumentation und enthalten Quellenhinweise für die fachliche Prüfung.
Einordnung im Migration Framework
Abschnitt betitelt „Einordnung im Migration Framework“- Rapid Discovery und Readiness Assessment: Erfasst Anwendungen sowie funktionale und nicht-funktionale Anforderungen für erste Readiness- und Portfolio-Sichten.
- Discovery und Design: Ordnet Services von AWS, Azure und Google Cloud passenden STACKIT Optionen zu und unterstützt die R-Strategie-Auswahl im Design.
- Business Case: Schätzt monatliche STACKIT Laufkosten anhand von Preisinformationen und erzeugt Grundlagen für die Migrationsplanung.
- Enablement: Unterstützt Teams mit einer geführten Advisory-Oberfläche zu STACKIT Service-Optionen, Terraform-Mustern und Architekturentscheidungen.
Typische Fähigkeiten
Abschnitt betitelt „Typische Fähigkeiten“- Bewertung auf Basis von Anforderungen: Erstellt aus Workload-Beschreibungen, Inventaren oder CMDB-Quellen Entwürfe für Readiness, R-Strategie, Zielbild und Business Case.
- Nachvollziehbare Beratung: Nutzt STACKIT Dokumentation und Provider-Kontext, damit Empfehlungen über Quellen geprüft werden können.
- Source-to-Target-Mapping: Vergleicht Hyperscaler-Services mit STACKIT Alternativen und kennzeichnet direkte Fits, Teil-Fits und Lücken.
- Interaktive Design-Unterstützung: Erstellt und verfeinert Zielarchitektur-Optionen mit Service-Mapping, Kostenschätzung und Terraform-Entwürfen.
Typische Eingaben und Ergebnisse
Abschnitt betitelt „Typische Eingaben und Ergebnisse“- Eingaben: Workload-Beschreibungen, Inventare, Anforderungen, Unterlagen zur Architektur, CSV- oder Excel-Exporte und optionale CMDB-Quellen wie ServiceNow oder LeanIX.
- Ergebnisse: Readiness Assessment, R-Strategie-Klassifikation, Service-Mapping, Zielarchitektur, Business-Case-Schätzung, Terraform-Entwurf und Quellenhinweise.
- Prüfbedarf: Ergebnisse dienen als Entscheidungsunterstützung und müssen durch qualifizierte Experten für Migration, Architektur, Security und Betrieb validiert werden.
Typische Eignungskriterien
Abschnitt betitelt „Typische Eignungskriterien“- Hyperscaler-zu-STACKIT-Migrationen: Gute Eignung für Portfolios, die von AWS, Azure oder Google Cloud nach STACKIT migrieren.
- Große oder unklare Portfolios: Hilfreich, wenn viele Anwendungen, unvollständige Dokumentation oder Service-Mapping-Arbeit Assessment und Design verlangsamen.
- Souveränitätsanforderungen: Relevant für regulierte Organisationen, die nachvollziehbare Empfehlungen und EU-basierte Verarbeitung auf STACKIT benötigen.
Einschränkungen
Abschnitt betitelt „Einschränkungen“- Keine Ausführungsautomatisierung: CloudMent migriert keine Workloads, führt keine Cutover aus und provisioniert keine Infrastruktur des Kunden.
- Kein agentenbasierter Scan: Die Analyse basiert auf bereitgestellten Eingabedaten statt auf direktem Scanning der bestehenden Umgebung.
- Prüfung durch Experten erforderlich: R-Strategie, Kosten, Compliance, Terraform und Architektur müssen vor der Nutzung geprüft werden.
Referenz
Abschnitt betitelt „Referenz“- Produktseite: CloudMent
- Dokumentation: Öffentliche Produktdokumentation ist in Vorbereitung.
- Marketplace-Listing: STACKIT Marketplace Listing ist in Arbeit.
Migration Factory Setup
Gehen Sie hier in die Tiefe: Hier wird aus einem freigegebenen Design eine ausführbare, wellenfähige Lieferfabrik.
Behandeln Sie Partner-Modell, Tooling, Schnittstellen und Runbook-Finalisierung als die Säulen eines factory-fähigen Setups.
Runbook-Reife und Tooling
Führen Sie Runbook-Gates und Auswahlkriterien für Werkzeuge in einer gemeinsamen, nachweisbaren Wellenfreigabe zusammen.
Migrate
Halten Sie dies so kurz wie Assess und fokussieren Sie auf den End-to-End-Ablauf in der Factory, der jede Welle zum Abschluss bringt.
Der End-to-End-Ablauf in der Factory ist hier das Kernkapitel: Intake, Umsetzung, Validierung und Übergabe jeder Welle durch die Factory.
Optimize
Halten Sie dies knapp: Optimize macht frisch migrierte Workloads zu kosten- und leistungsoptimierten Regelbetriebs-Services.
Überblick: Optimize-Modul
Abschnitt betitelt „Überblick: Optimize-Modul“Optimize startet, sobald Workloads auf STACKIT laufen und reale Daten aus dem Betrieb vorliegen. Das Modul überführt Beobachtungen aus dem Betrieb in messbare Verbesserungen für Performance, Stabilität und Wirtschaftlichkeit.
Optimize ist keine einmalige Aufgabe, sondern ein iterativer Zyklus, der sich mit früher Stabilisierung und Unterstützung direkt nach dem Cutover überschneiden kann.
Warum Optimize nach dem Cutover liegt
Abschnitt betitelt „Warum Optimize nach dem Cutover liegt“Viele Entscheidungen zu Rightsizing und Tuning sind erst unter echter Last belastbar. Nach dem Cutover lassen sich Annahmen mit Daten aus dem Betrieb validieren und präzisieren.
Optimize-Zyklus
Abschnitt betitelt „Optimize-Zyklus“- Laufzeitdaten erfassen: Auslastung, Latenz, Fehlerquoten, Durchsatz und Kostentreiber.
- Engpässe und Verschwendungsmuster auf Workload-, Plattform- und Datenebene identifizieren.
- Maßnahmen nach Business-Effekt, Risikoreduktion und FinOps-Nutzen priorisieren.
- Tuning-Änderungen in kontrollierten Inkrementen umsetzen.
- Ergebnisse gegen SLO-, Stabilitäts- und Kostenziele validieren.
- Erkenntnisse in Folgewellen und Betriebsstandards zurückführen.
Typische Bereiche
Abschnitt betitelt „Typische Bereiche“- Rightsizing: Compute-, Storage- und Netzwerkressourcen an reale Last anpassen.
- Performance-Tuning: Latenz und Durchsatz durch Konfiguration, Skalierung und Architekturmaßnahmen verbessern.
- Reliability-Hardening: Incident-Häufigkeit durch Resilienz-, Monitoring- und Fehlerbehandlungsmaßnahmen reduzieren.
- FinOps-Steuerung: Kostentransparenz verbessern, Verschwendung abbauen und Run-Rate optimieren.
Von der Theorie zur Umsetzung
Abschnitt betitelt „Von der Theorie zur Umsetzung“Optimierungsentscheidungen sollten auf Laufzeitdaten basieren, nicht auf Annahmen. Für die praktische Umsetzung werden Workload-Telemetrie, Alerting und kontrollierte Infrastrukturänderungen kombiniert.
- Managed-Observability-Basis: Mit STACKIT Observability Metriken, Logs und Traces mit Grafana, Prometheus, Thanos, Loki und Tempo erfassen.
- Erkennungslogik: Klare Schwellwerte und Beobachtungsfenster für Unterauslastung und Überlast definieren.
- Umsetzungspfad: Rightsizing über IaC-Änderungen (zum Beispiel VM-Flavors) mit Rollback-Checkpoints umsetzen.
- Validierungsschleife: Nach jedem Tuning-Inkrement SLO, Fehlerquote und Laufkosten erneut messen.
Konkrete Beispiel-Assets
Abschnitt betitelt „Konkrete Beispiel-Assets“Asset-Titel
Framework
Asset-Typ
Migration
Runbook
Migration
Runbook
Migration
Runbook
Migration
Runbook
Replatform-Optimierungsdimensionen
Abschnitt betitelt „Replatform-Optimierungsdimensionen“Für Replatform-Workloads auf Kubernetes umfasst Optimierung mehrere Ebenen und sollte als gemeinsamer Regelkreis gesteuert werden.
- Pod-Skalierung: HPA nutzen, um die Replikazahl anhand von Last mit klaren Min-/Max-Grenzen anzupassen.
- Node-Pool-Skalierung: Ausreichend Cluster-Headroom sicherstellen und den Maschinentyp (Flavor) für CPU-/Memory-Dichteanforderungen abstimmen.
- Ingress-Skalierung: Den Serviceplan des Load Balancers neu bewerten, wenn Ingress-Durchsatz oder Verbindungsverhalten zum Engpass werden.
- Storage-Rightsizing: Storage-Klassen nach Performance-Anforderungen persistenter Workloads auswählen.
- Validierungsdisziplin: Nach jeder inkrementellen Tuning-Änderung Latenz, Fehlerquote und Kosten erneut prüfen.
Eingaben und Ergebnisse
Abschnitt betitelt „Eingaben und Ergebnisse“Zentrale Eingaben
Cutover-Berichte, Incident-Trends, SLO-Messwerte, Telemetrie-Baselines und Kostenberichte.
Ergebnisse
Priorisiertes Verbesserungs-Backlog, validierte Tuning-Änderungen und aktualisierte Betriebsstandards.
Governance-Effekt
Nachvollziehbare Trade-off-Entscheidungen zwischen Performance, Stabilität und Kosten.
Abgrenzung zu anderen Modulen
Abschnitt betitelt „Abgrenzung zu anderen Modulen“Run
Schließen Sie die Reise kurz mit dem Run-Phasenmodell ab, damit das Publikum sieht, wo Migrationsergebnisse letztlich landen.
Überblick: Diese Phase
Abschnitt betitelt „Überblick: Diese Phase“Run ist der Zielzustand der Migration: Workloads laufen auf STACKIT mit klarer Verantwortung, stabilem Betrieb und messbarer Servicequalität.
Die Phase startet mit der Stabilisierung direkt nach dem Cutover und geht in den langfristigen Regelbetrieb über. Hier wird aus Migration ein tragfähiges Betriebsmodell.
Überblick
Abschnitt betitelt „Überblick“Run ist nicht nur ein Nachgang zur Migration, sondern das strategische Zielbild. Für viele Programme ist das operative Leitmotiv klar: möglichst viele Workloads in einen belastbaren “Runs on STACKIT”-Status überführen.
Die Phase verbindet Migrate über Hypercare mit dem laufenden Betrieb und prüft das Target Operating Model in der Praxis.
Wann Run startet und endet
Abschnitt betitelt „Wann Run startet und endet“- Start mit Hypercare direkt nach dem Cutover, solange Projekt- und Migrationsteams greifbar sind.
- Operative Lücken schließen, zum Beispiel fehlendes Monitoring, Alerting und Runbook-Anpassungen.
- Übergabe in DevOps-Verantwortung oder an ein klassisches Betriebsteam formalisieren.
- Support- und Service-Request-Modell zwischen Kunde und Anbieter verbindlich aktivieren.
- In den Regelbetrieb mit kontinuierlicher Optimierung und regelmäßiger Betriebsmodell-Prüfung überführen.
Je nach Betriebsmodell können Teile der Übergabe bereits während Migrate beginnen und mit Wellen überlappen.
Operating Model Handover ist in Migrate verankert und kann bereits vor Start der Run-Phase aktiv sein.
Run-Phasenmodell und Module
Abschnitt betitelt „Run-Phasenmodell und Module“Run verbindet kurzfristige Stabilisierung mit langfristigem Cloud-Betrieb. Das folgende Modell zeigt den Ablauf von der Migrationsübergabe bis zum stabilen Day-2-Betrieb.
Semantische Einordnung
Abschnitt betitelt „Semantische Einordnung“Das Run-Modell arbeitet mit vier semantischen Strömen zur klaren Einordnung von Verantwortung und Zweck:
- Stabilisierung: Hypercare schließt Post-Cutover-Risiken, solange Delivery-Teams noch direkt eingebunden sind.
- Betrieb: Operate sichert Zuverlässigkeit, Security, Observability und kontrollierte Änderungen im Regelbetrieb.
- Service: Support klärt Incident-Verantwortung sowie provider- und kundenseitige Service Requests.
- Nutzen: Customer Success sichert dauerhafte Adoption und Business-Outcome.
Warum diese Phase wichtig ist
Abschnitt betitelt „Warum diese Phase wichtig ist“Brücke von Projekt zu Betrieb
Hypercare stabilisiert offene Migrationsthemen, bevor daraus dauerhafte Störungsmuster entstehen.
Klare Ownership und Supportmodell
Eindeutige Verantwortungen für Störungen und Service Requests reduzieren Reibung und Eskalationen.
Betriebliche Resilienz
Monitoring, Observability und Runbook-Reife stärken Zuverlässigkeit und Wiederherstellungsverhalten.
Dauerhafte Wertrealisierung
Kontinuierliche Verbesserungen halten Performance, Kosten und Service-Ergebnisse im Zielbild.
Module in dieser Phase
Abschnitt betitelt „Module in dieser Phase“- Hypercare: Stabilisierungsbrücke von Migrate nach Run mit schneller Rückkopplung und kontrollierter Nacharbeit.
- Operate: Regelbetrieb in der Cloud auf STACKIT mit Fokus auf Stabilität, Security und Effizienz.
- Support: Betriebsmodell für Störungen und Service Requests zwischen Kunde und Anbieter.
- Customer Success: Baustein mit zentralem Kontakt für Adoption und Outcome-Tracking.
Typische Ergebnisse
Abschnitt betitelt „Typische Ergebnisse“Zum Ende der initialen Run-Etablierung sollten vorliegen:
- Stabilisierter Post-Cutover-Betrieb: Kritische Themen aus der Migration sind behoben oder mit klaren Maßnahmen abgesichert.
- Geschlossene Betriebslücken: Fehlendes Monitoring, Alerting und betriebliche Nachweise sind umgesetzt.
- Validiertes Übergabemodell: DevOps- oder klassisches Betriebsmodell ist in realen Situationen im Betrieb getestet.
- Aktives Supportmodell: Incident- und Request-Pfade sind produktiv, dokumentiert und messbar.
- Belastbare Run-Governance: Servicequalität, Kostenentwicklung und Verbesserungs-Backlog werden regelmäßig gesteuert.
Hypercare
Überblick
Abschnitt betitelt „Überblick“Hypercare ist die kurze Stabilisierungsphase direkt nach dem Cutover. Projekt- und Migrationsteams bleiben in dieser Zeit nah am Betrieb, damit offene Themen zügig gelöst werden.
Damit ist Hypercare die klare Brücke zwischen Migrate und Run.
Warum Hypercare unverzichtbar ist
Abschnitt betitelt „Warum Hypercare unverzichtbar ist“- Schnelle Nacharbeit: Wissen aus der Migration ist noch verfügbar.
- Risikoreduktion: Frühe Störungen werden beseitigt, bevor sie wiederkehren.
- Betriebsreife: Monitoring, Alerting und Runbook-Details werden ergänzt.
Ablauf je R-Pfad
Abschnitt betitelt „Ablauf je R-Pfad“- Cutover-Baseline bestätigen und Kriterien für Hypercare festlegen.
- Störungen und Lücken im Betrieb täglich auswerten.
- Nacharbeiten nach Nutzen und Risiko priorisieren.
- Korrekturen in kontrollierten Changes mit Rollback umsetzen.
- Stabilisierungsziele prüfen und Restrisiken klar übergeben.
- Hypercare beenden, wenn Service-, Observability- und Support-Reife akzeptiert sind.
Eingaben und Ergebnisse
Abschnitt betitelt „Eingaben und Ergebnisse“Zentrale Eingaben
Cutover-Protokolle, Migrations-Runbooks, offene Fehlertickets, SLO-Baselines und Incident-Muster.
Hypercare-Ergebnisse
Stabilisierte Services, geschlossene kritische Defekte und vollständige Dokumentation für die Übergabe.
Exit-Ergebnis
Freigegebener Übergang in Operate und in den Regelbetrieb.
Module in dieser Phase
Abschnitt betitelt „Module in dieser Phase“- Hypercare startet nach der technischen Umsetzung in Migrate.
- Die strukturierte Verantwortungsübergabe folgt in Operating Model Handover.
- Incident- und Request-Governance wird in Support verbindlich geregelt.
Überblick
Abschnitt betitelt „Überblick“Hypercare ist die kurze Stabilisierungsphase direkt nach dem Cutover. Projekt- und Migrationsteams bleiben in dieser Zeit nah am Betrieb, damit offene Themen zügig gelöst werden.
Damit ist Hypercare die klare Brücke zwischen Migrate und Run.
Warum Hypercare unverzichtbar ist
Abschnitt betitelt „Warum Hypercare unverzichtbar ist“- Schnelle Nacharbeit: Wissen aus der Migration ist noch verfügbar.
- Risikoreduktion: Frühe Störungen werden beseitigt, bevor sie wiederkehren.
- Betriebsreife: Monitoring, Alerting und Runbook-Details werden ergänzt.
Ablauf je R-Pfad
Abschnitt betitelt „Ablauf je R-Pfad“- Cutover-Baseline bestätigen und Kriterien für Hypercare festlegen.
- Störungen und Lücken im Betrieb täglich auswerten.
- Nacharbeiten nach Nutzen und Risiko priorisieren.
- Korrekturen in kontrollierten Changes mit Rollback umsetzen.
- Stabilisierungsziele prüfen und Restrisiken klar übergeben.
- Hypercare beenden, wenn Service-, Observability- und Support-Reife akzeptiert sind.
Eingaben und Ergebnisse
Abschnitt betitelt „Eingaben und Ergebnisse“Zentrale Eingaben
Cutover-Protokolle, Migrations-Runbooks, offene Fehlertickets, SLO-Baselines und Incident-Muster.
Hypercare-Ergebnisse
Stabilisierte Services, geschlossene kritische Defekte und vollständige Dokumentation für die Übergabe.
Exit-Ergebnis
Freigegebener Übergang in Operate und in den Regelbetrieb.
Module in dieser Phase
Abschnitt betitelt „Module in dieser Phase“- Hypercare startet nach der technischen Umsetzung in Migrate.
- Die strukturierte Verantwortungsübergabe folgt in Operating Model Handover.
- Incident- und Request-Governance wird in Support verbindlich geregelt.