Modul 01 · Live
Migration
Assessment
Aus Inventar-, Auslastungs- und Lifecycle-Daten wird ein Readiness-Score von 0 bis 100 und eine 6R-Empfehlung je Anwendung. Nachvollziehbar bis auf den einzelnen Punktabzug.
Erhebung
Agentenlos, read-only, ausgehend.
Ein Collector im Kundennetz liest über die vSphere-API, normalisiert lokal und überträgt ausschließlich ausgehend. Auf den virtuellen Maschinen wird nichts installiert.
Was erhoben wird
- Inventar — Hosts, VMs, Disks, NICs, Ressourcenpools, Cluster
- Betriebssystem & Software — erkannte OS-Familie, Version, installierte Komponenten
- Auslastung — CPU- und Speichermetriken über 30 Tage, ausgewertet als 95. Perzentil
- Abhängigkeiten — Verbindungen zwischen Systemen als Graph, inklusive Zielen außerhalb des Inventars
- Lifecycle — Abgleich gegen Support-Zeitpläne: supported, extended, end of life
Abgeleitete Kennzahlen je VM
| Kennzahl | Bedeutung |
|---|---|
cpu_p95, mem_p95 | 95. Perzentil über 30 Tage, mindestens 14 Tage Daten |
util_class | idle unter 5 %, low unter 20 %, normal, high über 70 % |
stale | ausgeschaltet seit über 90 Tagen, keine Metriken |
os_support_status | supported / extended / eol |
dependency_fanout | Anzahl verbundener Anwendungen, ein- und ausgehend |
patch_age_days | Tage seit dem letzten Patch |
Readiness-Score
Start bei 100, Abzüge mit Namen.
Vier Kategorien, jede mit einer Obergrenze. Kein Modell entscheidet — die Regeln liegen als Daten vor und lassen sich je Mandant anders gewichten.
| Kategorie | Max. Abzug | Beispiele für Faktoren |
|---|---|---|
| Technical | 40 | Spezialhardware wie GPU oder USB-Dongle (15), kein UEFI (8), Volume über 4 TB (6), zu kurze Metrikhistorie (7) |
| Lifecycle | 25 | Betriebssystem end of life (20), DB-Engine end of life (15), extended support (10), Patchstand älter als 180 Tage (5) |
| Dependency | 20 | Fanout auf 10 und mehr Anwendungen (12), unbekannte externe Ziele (8), latenzsensitiver Ost-West-Verkehr (6) |
| Operational | 15 | Kein Ansprechpartner hinterlegt (8), Lizenzbindung wie Oracle oder SQL Enterprise (7), mission-critical (5) |
Lifecycle senkt die Readiness und hebt die Priorität. Ein Betriebssystem am Support-Ende macht die Migration aufwendiger — ist aber gerade deshalb der Grund, sie zu tun. Beide Effekte stehen getrennt in den Zahlen, statt sich gegenseitig aufzuheben.
| Score | Einstufung | Was das für die Planung heißt |
|---|---|---|
| 80–100 | Ready | Rehost-Kandidat, geringes Risiko |
| 60–79 | Ready mit Auflagen | Blocker sind adressierbar |
| 40–59 | Needs Work | Replatform oder Refactor wahrscheinlich |
| < 40 | Complex | Einzelfallanalyse, späte Welle oder Retain |
Bewertet wird die Anwendung, nicht die einzelne VM: der App-Score ist das Minimum der VM-Scores mit Ausgleich — eine schwache VM soll die Anwendung drücken, aber nicht allein bestimmen.
6R-Klassifikation
Ein Entscheidungsbaum, keine Meinung.
Die Empfehlung entsteht aus einer festen Reihenfolge von Fragen. Jede Anwendung landet in genau einer der sechs Strategien — und Sie können nachlesen, an welcher Verzweigung das passiert ist.
Retire
Alle VMs sind stale oder dauerhaft im Leerlauf. Stilllegung prüfen, bevor irgendetwas migriert wird.
Repurchase
Es gibt eine sinnvolle SaaS-Alternative — der klassische Fall ist Exchange nach Microsoft 365.
Retain
Ein harter Blocker steht im Weg: Spezialhardware, Latenzbindung oder eine Compliance-Vorgabe. Erneute Prüfung in zwölf Monaten.
Replatform
Betriebssystem oder Datenbank sind am Support-Ende. Upgrade oder Wechsel auf einen PaaS-Dienst statt reinem Umzug.
Rehost
Readiness ab 60, keine PaaS-Chance in Sicht. Lift and Shift — aber rightsized statt 1:1.
Refactor
Der Rest: Architektur-Review und Modernisierung, bevor die Anwendung ein Migrationsziel bekommt.
Der Baum liegt als Regelwerk in der Datenbank, nicht im Code. Anpassungen brauchen kein Deployment und lassen sich je Mandant überschreiben.
Designprinzipien
Warum das Assessment so gebaut ist.
Erklärbarkeit vor Cleverness
Jeder Score muss sich auf konkrete Blocker zurückführen lassen. Auf die Frage „warum 62?" gibt es eine Liste, keine Modellgewichte. Ein ML-Schritt lohnt erst, wenn die Heuristiken stabil laufen und Feedback-Daten existieren.
Score auf Anwendungsebene
Migriert wird eine Anwendung, nicht eine VM. VM-Scores sind Zwischenergebnisse; bewertet und priorisiert wird das Aggregat.
Gewichte gehören dem Kunden
Defaults werden mitgeliefert, aber eine Behörde oder ein KRITIS-Betreiber gewichtet Souveränität anders als ein Mittelständler. Die Gewichte sind Konfiguration, nicht Quellcode.
Sehen, wie das auf Ihrer Landschaft aussieht.
Der Migration Advisor macht aus den Scores eine Entscheidungsgrundlage — inklusive der Frage, wie belastbar sie ist.