Vor der Migration · Faktenbasis
Cloud Readiness Assessment für Migrationsprojekte
Bevor Termin und Budget feststehen, klären wir, was Sie wirklich betreiben, was woran hängt und wer was entscheiden muss. Sie erhalten Bestandsliste, Abhängigkeitskarte und Plan als Dateien, mit denen Sie direkt weiterarbeiten können.
- Inventar und Abhängigkeitskarte
- Entscheidungsregister mit Namen und Fristen
- Zielarchitektur und Migrationsplan
01Ausgangslage
Warum Migrationen am Inventar scheitern
Pläne auf Basis veralteter Inventarlisten geraten ins Rutschen: nicht dokumentierte Schnittstellen, Datenbanken mit unerwartetem Volumen, Software mit Lizenzbindung. Ein Assessment verlagert diese Entdeckungen vor die Verpflichtung auf Termin und Budget.
Es ist außerdem der Ort, an dem „nicht migrieren“ (Retain) und „abschalten“ (Retire) ernsthaft geprüft werden können, bevor Aufwand entsteht. Die Umsetzung selbst ist Gegenstand der Cloud-Migration; die vorangestellte Plattformentscheidung fällt in der Cloud-Beratung. Das Assessment liegt dazwischen und liefert die belastbare Faktenbasis.
- Für IT-Leitung und Projektverantwortliche vor einer Migration auf AWS, Azure, Google Cloud, STACKIT oder eine private Plattform
- Eigenständiges, begrenztes Projekt
02Ablauf
Von der Bestandsaufnahme zum belastbaren Migrationsplan
Sechs Arbeitsschritte, jeder mit einem eigenen Ergebnis. Die Übersicht zeigt, wie sie aufeinander aufbauen.
03
Was Sie nach jeder Station in der Hand halten
- 01
Inventar
Ergebnis: BestandslisteSysteme, Dienste, Datenbanken, Schnittstellen, Betriebssystem- und Softwarestände, Datenvolumen und Änderungsrate. Werkzeuge sammeln; Menschen prüfen, ergänzen und streichen.
- 02
Abhängigkeiten
Ergebnis: AbhängigkeitskarteNetzwerkflüsse, Datenbankverbindungen, Batch-Jobs, externe Dienste, Identitäten. Aus der Karte leiten sich die Migrationswellen ab.
- 03
Bewertung je Anwendung
Ergebnis: ErgebnisklasseNach dem Raster weiter unten, mit Ergebnisklasse und Begründung.
- 04
Risiken
Ergebnis: RisikolisteListe mit Eigentümer, Eintrittsbedingung und Gegenmaßnahme.
- 05
Entscheidungsregister
Ergebnis: Fragen mit FristAlle offenen Fragen, die der Plan voraussetzt, mit Frist und Verantwortlichem (Aufbau weiter unten).
- 06
Zielarchitektur
Ergebnis: ZielbildKonkretes Zielbild je Plattform: Struktur, Netzwerk, Identität, Sicherheitszonen, Speicher, Backup, Monitoring. Grundlage ist eine Landing Zone.
- 07
Migrationsplan
Ergebnis: WellenplanWellen, Pilot, Cutover-Verfahren mit Rollback, Abnahmekriterien, Aufwand und Annahmen. Datenbanken folgen einem eigenen Pfad, siehe Datenbankmigration.
- 08
Abschlusspräsentation und Übergabe
Ergebnis: Dateien für SieAlle Ergebnisse erhalten Sie als Dateien, erläutert in einer Abschlusspräsentation.
04Bewertungsraster
Sieben Dimensionen je Anwendung
Jede Anwendung wird auf denselben Dimensionen bewertet. Die Fragen sind unser Raster; Gewichtung und Schwellen legen wir mit Ihnen fest, weil sie von Ihrer Situation abhängen.
| Dimension | Leitfragen | Ergebnisklassen |
|---|---|---|
| Technische Eignung | Läuft die Anwendung auf Standard-Betriebssystemen? Ist sie containerfähig? Gibt es Hardware-, Treiber- oder Kernel-Abhängigkeiten? | bereit / mit Anpassung / Umbau nötig |
| Datenlage | Wie groß, wie schnell wachsend, wie schnell sich ändernd? Wie lange darf das Umschalten dauern? | einfach / geplantes Synchronisationsfenster / Sonderpfad |
| Abhängigkeiten | Wie viele Verbindungen, wie latenzempfindlich? Sind alle bekannt und dokumentiert? | isoliert / gekoppelt / unklar (Klärung nötig) |
| Lizenz und Vertrag | An Hardware, Standort oder Anbieter gebunden? Supportfähig auf Zielplattform? | frei / zu klären / blockierend |
| Sicherheit und Regulierung | Datenklasse, Standortvorgabe, Protokollierungspflichten, Zugriffsmodell | unkritisch / Auflagen / Zielwahl eingeschränkt |
| Betrieb und Verantwortung | Gibt es einen Eigentümer, Dokumentation, Tests, Runbooks? | betreibbar / lückenhaft / ohne Eigentümer |
| Geschäftliche Bedeutung | Ausfalltoleranz, Wartungsfenster, Saisonalität | niedrig / mittel / hoch |
Aus den Ergebnisklassen leiten wir je Anwendung eine Migrationsstrategie ab (Rehost, Replatform, Repurchase, Refactor, Retire, Retain; die sechs Strategien erklärt die Cloud-Migration). Die Zuordnung ist ein Vorschlag, den Ihre Fachseite bestätigt.
05Ergebnisartefakt
Das Entscheidungsregister: aus Lücken werden Namen und Termine
Ein Assessment ist erst fertig, wenn offene Entscheidungen sichtbar sind. So wird aus „der Plan hat Lücken“ eine Liste mit Namen und Terminen. Entscheidungen, die ohne Daten nicht getroffen werden können, erhalten die Aufgabe, welche Daten zu beschaffen sind. Jeder Eintrag enthält sechs Angaben:
-
Nummer und Frage
Zum Beispiel „Verbleibt die Fertigungsanwendung wegen Latenz am Standort?“
-
Wirkung auf den Plan
Warum die Frage den Plan beeinflusst: welche Welle, welches Risiko.
-
Optionen mit Folgen
Aufwand, Betrieb und Risiko je Option.
-
Empfehlung
Empfehlung von SKAFFON mit Begründung.
-
Entscheider und Frist
Wer entscheidet bis wann.
-
Status und Datum
Offen, entschieden oder verworfen, jeweils mit Datum.
06Vorbereitung
Was wir von Ihnen brauchen
Je vollständiger die Eingaben, desto weniger Annahmen stehen später im Plan.
- Zugriff auf Dokumentation, Konfigurations- und Infrastruktur-Code und Ansprechpartner je Anwendung
- Bei VMware-Umgebungen ein Export mit RVTools; bei Cloud-Umgebungen Infrastruktur als Code (Terraform/OpenTofu) oder Lesezugriff auf das Konto
- Betriebs- und Verfügbarkeitsanforderungen, Wartungsfenster
- Termine mit harter Wirkung (Vertragsende, Lizenzablauf, Audit)
- Regulatorische Vorgaben je Datenklasse
- Benennung der Entscheidungsträger für Plattform, Budget und Abnahme
07Werkzeuge
RVTools, Infrastruktur-Code und StackToIT beim Sammeln und Auswerten
Beim Sammeln und Auswerten setzen wir Werkzeuge ein, etwa RVTools-Exporte für VMware-Umgebungen und Infrastruktur-Code als Quelle für Cloud-Bestände. Für Migrationen zu STACKIT gibt es das SKAFFON-Produkt StackToIT. Nach den Angaben auf stacktoit.com liest es Terraform- und OpenTofu-Wurzelmodule (AWS, Azure, Google Cloud, Huawei Cloud, Alibaba Cloud, Oracle Cloud) sowie VMware-RVTools-Exporte und erzeugt STACKIT-Terraform, Zielarchitektur-Diagramme, einen geordneten Ausführungsplan mit Kostenzeilen und Entscheidungsvorlagen für offene Fragen. Es verändert nach eigener Aussage nichts in einer Cloud; die Ausgaben sind Dateien zur Prüfung. Ressourcen, deren Anzahl erst zur Planungszeit feststeht, werden als bedingt aufgeführt und nicht angenommen.
Näheres zum Angebot: Migration zu STACKIT.
Lesezugriff, Ihre Zugangsdaten, geregelte Löschung
Wir arbeiten mit Lesezugriff. Zugangsdaten bleiben bei Ihnen, Zugriffe sind zeitlich begrenzt und rollenbasiert. Inventardaten und Konfigurationsdateien können Geheimnisse enthalten; wir legen vorab fest, wo Daten verarbeitet werden und wie sie nach dem Projekt gelöscht werden. Rechtliche Fragen (Auftragsverarbeitung, Standortvorgaben) bewertet Ihr Datenschutz; wir benennen die technischen Auswirkungen.
08Passung
Assessment oder direkt umsetzen?
Es lohnt sich, wenn Sie …
- eine Migration planen und erst belastbare Fakten zu Bestand, Abhängigkeiten und Risiken brauchen.
- offene Entscheidungen sichtbar machen und Verantwortlichen mit Fristen zuordnen wollen.
- Ihre Anwendungsverantwortlichen einbinden können.
Es passt nicht, wenn Sie …
- die Migration bereits beschlossen haben, Wellenplan und Zielarchitektur existieren und Sie nur Umsetzung suchen. Dann ist die Cloud-Migration der richtige Einstieg.
- ein automatisch erzeugtes Ergebnis ohne Beteiligung Ihrer Anwendungsverantwortlichen erwarten. Ohne deren Antworten bleibt das Inventar unvollständig.
- einen festen Endtermin oder Festpreis für die Migration suchen, bevor das Inventar existiert. Termine und Aufwände nennen wir nach dem Assessment.
- eine reine Plattformauswahl auf Management-Ebene ohne technische Tiefe suchen. Dafür ist die Cloud-Beratung gedacht.
09Angebot
Was ein Assessment-Angebot bestimmt
Der Aufwand richtet sich nach der Zahl und Heterogenität der Anwendungen, der Qualität der vorhandenen Dokumentation und Infrastruktur-Definitionen, der Zahl der Zielplattformen, der Zahl der zu beteiligenden Ansprechpartner sowie der Tiefe der gewünschten Zielarchitektur.
Ein Angebot entsteht nach einem Scoping-Gespräch; es legt Umfang, Phasen, Ergebnisse, Annahmen und Preismodell fest.
Welche Landschaft soll bewertet werden?
Nennen Sie uns den groben Umfang der Landschaft, die Ausgangsplattform, die Zielkandidaten und den auslösenden Termin. Zurück zur Übersicht: Lösungen.