Multicloud-Migration: Wie wir 60% Cloud-Kosten sparten – Praxisguide

60% weniger Cloud-Kosten – das war das Ziel, und wir haben es erreicht. Dieser Guide zeigt die komplette Reise einer Enterprise-Anwendung von On-Premise zu einer Multicloud-Kubernetes-Architektur: die Strategie, die Stolpersteine und das Framework, das andere direkt anwenden können.

Die Ausgangssituation

Ein Enterprise-Softwareunternehmen betrieb seine Hauptanwendung seit 12 Jahren On-Premise. Drei Rechenzentren, 40 physische Server, ein monolithisches Java-Backend, ein SQL-Server-Cluster und vier Vollzeit-Sysadmins für den Betrieb.

Die Betriebskosten: ~420.000 € pro Jahr für Hardware, Lizenzen, Strom, Kühlung und Personal.

Der Auslöser für die Migration: Zwei der vier Sysadmins gingen in Rente, die Hardware war am End-of-Life, und das Unternehmen wollte flexibler auf Lastspitzen reagieren.

Das Ziel: Modernisierung der Infrastruktur bei gleichzeitiger Kostenreduktion.

Warum Multicloud statt Single-Cloud?

Die erste Frage war: AWS, Azure, GCP – oder alle drei?

Die Antwort war nicht ideologisch, sondern wirtschaftlich:

| Workload | Optimale Cloud | Begründung | |----------|---------------|------------| | Compute (Kubernetes) | AWS EKS + GCP GKE | Spot-Instanzen, Preis-Wettbewerb | | Datenbank | Azure SQL | Beste Migration von SQL Server | | ML-Workloads | GCP Vertex AI | Günstigste GPU-Instanzen | | Backup & Storage | AWS S3 | Niedrigste Egress-Kosten |

Vendor Lock-in durch Single-Cloud wäre teurer geworden als der Verwaltungsaufwand der Multicloud-Strategie. Kubernetes als gemeinsame Abstraktionsschicht macht Multicloud beherrschbar.

Die Migrationsarchitektur

Phase 1: Containerisierung (8 Wochen)

Bevor etwas in die Cloud geht, muss die Anwendung containerisiert sein. Das klingt einfach – ist es nicht.

Das Java-Monolith hatte über die Jahre 312 externe Abhängigkeiten angesammelt, darunter drei proprietäre Bibliotheken, die nur auf Windows liefen. Die Lösung: Windows-Container für Legacy-Komponenten, Linux-Container für alles Neue.

Anti-Pattern das wir vermieden: Den Monolith direkt in einen Container packen und hoffen. Stattdessen: Domain-Mapping des Monoliths, Identifikation von 8 abgrenzbaren Domains, schrittweise Strangler-Fig-Pattern.

Phase 2: Kubernetes-Cluster-Setup (4 Wochen)

Wir nutzten Terraform für die gesamte Infrastruktur-Definition und Helm für Application-Deployments. Kein manuelles Klicken in Cloud-Konsolen.

Wichtige Entscheidungen:

Cluster pro Umgebung (dev/staging/prod), nicht pro Workload – einfacheres Networking
Istio als Service Mesh für Observability und Traffic Management
Velero für Backup über alle Clouds hinweg

Phase 3: Pilot-Migration (6 Wochen)

Statt alles auf einmal umzuziehen: Ein repräsentativer Sub-Service wurde als Pilot ausgewählt. Der Grund: Fehler kosten in der Pilot-Phase weniger als nach dem Full-Migration-Commit.

Der Pilot-Service lief parallel zu On-Premise, Ergebnisse wurden verglichen, Latenz und Fehlerrate gemessen. Erst nach 4 Wochen stabilen Betriebs wurde die alte Infrastruktur für diesen Service abgeschaltet.

Phase 4: Full Migration (16 Wochen)

Mit den Learnings aus dem Pilot lief die vollständige Migration deutlich smoother. Der kritischste Moment: Database Migration Day – 8 Stunden Downtimewindow für die Datenbankübertragung zu Azure SQL.

Vorbereitung: 6 Wochen intensive Testing in einem Azure-Mirror der On-Premise-DB, drei Dry-Runs der Migration, Rollback-Plan für jeden Schritt.

Die Kostentabelle nach 12 Monaten

| Kostenblock | On-Premise | Multicloud (Jahr 1) | Delta | |-------------|-----------|---------------------|-------| | Compute | 180.000 € | 48.000 € | -73% | | Datenbank | 95.000 € | 22.000 € | -77% | | Netzwerk/Storage | 45.000 € | 18.000 € | -60% | | Personal (Infra) | 100.000 € | 80.000 € | -20% | | Gesamt | 420.000 € | 168.000 € | -60% |

Was wir falsch gemacht haben

Networking unterschätzt: Cloud-Egress-Kosten bei Multicloud können erheblich sein. Wir hatten zu optimistisch kalkuliert und mussten Datenflüsse nachträglich optimieren.

Kubernetes-Expertise intern aufbauen dauert: Die ersten 3 Monate waren für das Team eine steile Lernkurve. Externe Kubernetes-Expertise war teurer als geplant.

Monitoring-Kosten: CloudWatch + Grafana + Jaeger + Prometheus – Observability in der Cloud ist nicht günstig. Hätten wir früher konsolidiert.

Das Framework für deine Migration

Schritt 1: Cost Baseline (Was kostet die aktuelle Infrastruktur wirklich, inkl. Personal?)

Schritt 2: Workload-Analyse (Welche Services sind cloud-ready, welche brauchen Refactoring?)

Schritt 3: Cloud-Provider-Mapping (Nicht alles zu einem Provider – Wirtschaftlichkeit pro Workload)

Schritt 4: Containerisierung vor Migration (Kubernetes-ready machen, bevor man migriert)

Schritt 5: Pilot-first (Ein repräsentativer Service, 4 Wochen Parallelbetrieb)

Schritt 6: Migration mit Rollback-Plan (Kein heroischer Big-Bang-Ansatz)

Du willst die Infrastruktur deines Unternehmens modernisieren? Lass uns sprechen – ich zeige dir, welche Strategie für deine spezifische Situation Sinn macht und wo die typischen Fallstricke liegen.

FAQ: Multicloud-Migration

Wie viel spart eine Multicloud-Migration?

30–60% Kostenreduktion sind realistisch, wenn man vom On-Premise-Modell kommt. Der exakte Wert hängt von Workload-Profil, aktuellen Lizenzkosten und dem Grad der Containerisierung ab.

Wie lange dauert eine Enterprise-Migration?

6–18 Monate für eine vollständige Migration. Mit dem Pilot-Approach und Strangler-Fig-Pattern für Monolithe sind erste Ergebnisse schon nach 3 Monaten messbar.

Brauche ich für Kubernetes eigene Expertise?

Ja – Kubernetes hat eine steile Lernkurve. Entweder Expertise intern aufbauen (6–12 Monate) oder mit einem Experten starten, der den Aufbau begleitet und gleichzeitig das Team ausbildet.