Kubernetes-Migrations-Assessment

Für Betreiber von Legacy-Anwendungen: J2EE, WebLogic, Docker Swarm, VM-Monolithen. Oft ein Cutover, den die Geschäftsführung nur mit schriftlichem Risiko akzeptiert.

Falsch bei Greenfield ohne Bestand, oder wenn Sie nur einen Cluster-Workshop brauchen.

Was Sie bekommen

• Ist-Aufnahme der Anwendung und der Betriebsumgebung
• Zielarchitektur-Skizze
• Cutover-Strategie
• Risiken und Aufwandsschätzung
• Vorlage, mit der Geschäftsführung oder IT-Leitung entscheiden kann

Fünf Tage

1. Tag 1: Ist-Zustand, Abhängigkeiten, Deploy-Pfad, wer den Cutover trägt
2. Tag 2: Zielarchitektur. Was bleibt, was wandert, was stirbt
3. Tag 3: Cutover. Strangler, Parallelbetrieb, Rollback
4. Tag 4: Risiken, Aufwand, Betriebsmodell nach der Übergabe
5. Tag 5: Entscheidungsvorlage und Gespräch

Wonach ich schaue

Dieselbe Reihenfolge wie in der Behördenmigration: Bestand lesen, Ziel skizzieren, Cutover in Phasen, dann übergeben. Zahlen aus diesem Projekt: Zero Downtime, Rollout von einem Tag auf 20 Minuten. Das Assessment liefert die Vorlage, nicht die Migration.

Beispiel-Finding

Beispiel (anonymisiert): ein Swarm-Cluster mit 20+ Mandanten, Deployments von Hand. Ein Big-Bang-Cutover hätte alle Instanzen gleichzeitig getroffen. Die Vorlage war: Mandant für Mandant, automatisierte Rollouts, Rollback pro Instanz.

Danach

Ist-Aufnahme, Zielbild, Cutover, Risiken, Aufwand. Am Ende eine Vorlage, mit der Sie intern argumentieren können.

Sie können intern entscheiden, ob und mit wem Sie die Migration beauftragen. Sie müssen nicht bei mir bleiben.

Häufige Fragen

Hintergrund

• Lessons Learned aus der Behörde
• Fall: Behördenanwendung
• Cloud und Kubernetes