„Wir sind jetzt in der Cloud – warum ist es teurer geworden?“
„Warum sind wir nicht schneller, sondern eher komplizierter geworden?“
„Warum machen wir immer noch so viel Betrieb wie früher?“
Solche Fragen hören wir bei CodeKlar regelmäßig. Vor allem, wenn Unternehmen ihre Systeme per Lift & Shift in die Public Cloud verschoben haben. Der Punkt ist: Cloud ist nicht automatisch günstiger oder besser. Cloud wird dann zum Vorteil, wenn man sie gezielt modern nutzt. Mit sauberer Architektur, Automatisierung, klarer Governance und konsequenter Kostensteuerung.
In diesem Beitrag erklären wir einfach und verständlich, warum Lift & Shift häufig enttäuscht, was hinter technischen Schulden steckt und welche Migrationswege wirklich helfen, Kosten, Sicherheit und Geschwindigkeit zu verbessern.
Das Wichtigste in Kürze
Public Cloud-Vorteile entstehen nicht automatisch – sie müssen technisch und organisatorisch ermöglicht werden.
Lift & Shift verschiebt Altsysteme fast unverändert in die Cloud: alte Kosten- und Betriebsprobleme bleiben – manchmal werden sie sogar größer.
Häufige Ursachen: technische Schulden, falsches Sizing, fehlendes Auto-Scaling, manuelle Betriebsprozesse, Security-Modelle „von früher“.
Bessere Strategien sind Replatforming (Cloud-Services nutzen) oder Refactoring (cloud-native umbauen).
Wer überzeugt werden soll (Management), braucht messbare Ergebnisse: Kosten pro Workload, Verfügbarkeit, Release-Frequenz, Security-Status.
Inhaltsverzeichnis
Warum Cloud-Projekte oft nicht liefern, was versprochen wurde
Die Erwartungen sind meist hoch und oft auch berechtigt. Cloud kann enorm helfen. Aber nur, wenn man sie wie Cloud betreibt.
Typische Enttäuschungssignale:
-
„Wir zahlen mehr als vorher – warum?“
-
„Wir sind nicht schneller geworden – im Gegenteil.“
-
„Unser Betrieb ist komplizierter geworden.“
-
„Security fühlt sich unsicherer an, weil wir nicht genau wissen, was wo ist.“
Der Kern dahinter: Viele Unternehmen migrieren zuerst technisch (Server umziehen), aber modernisieren nicht:
-
keine Standardisierung (jede Anwendung anders)
-
keine Automatisierung (Deployments, Patches, Skalierung)
-
keine klare Governance (Rollen, Policies, Kostenstellen)
-
keine Cloud-native Nutzung (Managed Services)
Technische Schulden und warum sie so teuer sind
Technische Schulden sind Kompromisse, die man irgendwann gemacht hat, um schnell voranzukommen und die später dauerhaft Kosten verursachen.
Statt „modernisieren“ wird „reparieren“ zum Alltag:
-
mehr Wartung statt Weiterentwicklung
-
Sonderlösungen statt Standards
-
immer mehr Abhängigkeiten und Workarounds
-
Updates werden riskant („Nicht anfassen, läuft!“)
Warum Manager das spüren:
Technische Schulden sind kein reines IT-Thema. Sie sind ein Business-Risiko, weil sie Innovation verlangsamen, Ausfälle wahrscheinlicher machen und Kosten unplanbar werden lassen.
Lift & Shift: Schnell – aber oft teuer und unflexibel
Was ist Lift & Shift?
Lift & Shift bedeutet: Anwendungen und Server werden nahezu unverändert in die Cloud übertragen.
Wie ein Umzug: Möbel und Kartons werden einfach in die neue Wohnung gestellt, ohne Grundriss neu zu denken.
Warum entscheiden sich viele dafür?
-
schnellster Weg „in die Cloud“
-
wenig Veränderung am System = subjektiv weniger Risiko
-
gut geeignet, um Termine („Cloud bis Datum X“) zu erfüllen
Warum ist das oft der Grund für Zweifel?
Weil Lift & Shift häufig nur einen Teil der Cloud-Vorteile ermöglicht:
-
Kosten: On-Prem-Server sind oft auf Peak-Last „zu groß“. In der Cloud zahlt man diese Größe dauerhaft.
-
Skalierung: Wenn ein System nicht cloudfähig gebaut ist, kann es nicht automatisch skalieren.
-
Betrieb: Man betreibt weiter Betriebssysteme, Patches, Monitoring, Backups wie früher – nur eben in der Cloud.
-
Security: Alte Sicherheitskonzepte passen nicht sauber zu modernen Cloud-Sicherheitsmodellen.
Public Cloud richtig nutzen: Wo der echte Mehrwert liegt
Cloud lohnt sich vor allem, wenn Unternehmen diese Punkte wirklich nutzen:
a) Elastizität statt Dauerbetrieb
-
Ressourcen hochfahren, wenn Bedarf da ist
-
Ressourcen runterfahren/abschalten, wenn nicht
→ reduziert Verschwendung
b) Managed Services statt „Server selbst betreuen“
Statt „Datenbank auf VM“ nutzt man z. B. einen verwalteten Datenbankdienst: weniger Patchaufwand, bessere Stabilität, integrierte Backups.
c) Standardisierung & Automatisierung
-
Infrastruktur als Code (wiederholbar, dokumentiert, weniger Fehler)
-
CI/CD (schnellere Releases, weniger Risiko)
-
zentrale Policies (Governance statt Chaos)
d) Sicherheit als System, nicht als Add-on
-
Identity-first (Wer darf was?)
-
Least Privilege (minimale Rechte)
-
Monitoring/Alerting und saubere Logs
Migrationsstrategien im Vergleich
| Strategie | Was passiert? | Vorteile | Nachteile | Typische Einsatzfälle |
|---|---|---|---|---|
| Lift & Shift | 1:1 Umzug in die Cloud | schnell, wenig App-Änderung, guter Start für Timing | oft teuer, wenig Cloud-Vorteile, technische Schulden bleiben | Deadline-Druck, Übergangslösung, kurzfristige Entlastung |
| Replatforming | gezielte Anpassungen + Cloud-Services nutzen | gutes Kosten/Nutzen-Verhältnis, schneller als Neubau, spürbare Verbesserungen | nicht alles wird „cloud-native“, etwas Umbau nötig | Datenbanken/Queues/Storage modernisieren, Betrieb vereinfachen |
| Refactoring | Architektur/Code cloud-native umbauen | maximale Vorteile (Skalierung, Resilienz, Speed), beste Zukunftsfähigkeit | höherer Initialaufwand, braucht Planung & Tests | Kernsysteme, Wachstum, hohe Last, starke Release-Anforderungen |
Replatforming: der pragmatische „Sweet Spot“
Replatforming ist oft die beste Balance: keine Komplett-Neuentwicklung, aber echte Verbesserungen.
Typische Replatforming-Schritte:
-
Datenbank auf Managed DB umstellen
-
File-/Blob-Storage cloud-native nutzen
-
Monitoring/Backup über Cloud-Mechanismen standardisieren
-
kleine Architektur-Optimierungen (Caching, Entkopplung)
Ergebnis:
-
weniger Betriebsaufwand
-
bessere Stabilität
-
Kosten werden steuerbarer
-
Teams werden schneller
Refactoring: wenn maximale Cloud-Vorteile nötig sind
Refactoring lohnt sich besonders, wenn:
-
ihr stark skalieren müsst
-
hohe Verfügbarkeit geschäftskritisch ist
-
ihr schneller releasen wollt (Time-to-Market)
-
ihr langfristig innovativer werden müsst (API-first, Event-driven, Microservices, Container)
Einfach gesagt:
Lift & Shift bringt euch „in die Cloud“.
Refactoring macht euch „cloud-ready und cloud-fast“.
Kosten, Sicherheit, Betrieb: häufige Fehler & Best Practices
Kosten: typische Fallen
-
zu große VMs („weil es on-prem auch so war“)
-
Dev/Test läuft 24/7
-
keine Tags/Owner → niemand fühlt sich verantwortlich
-
keine regelmäßige Optimierung
Best Practices:
-
Right-Sizing-Routine (monatlich/vierteljährlich)
-
Abschaltpläne für Dev/Test
-
Tags, Budgets, Kostenstellen (FinOps light reicht oft schon)
-
Reservierungen/Commitments erst, wenn Last stabil verstanden ist
Sicherheit: typische Fallen
-
zu viele Adminrechte
-
fehlende Trennung von Umgebungen (Prod/Dev)
-
unklare Zugriffe von außen
-
fehlendes Logging/Alerting
Best Practices:
-
Identity & Rechte sauber (Least Privilege)
-
klare Policies & Standards
-
Security Monitoring + regelmäßige Reviews
Betrieb: typische Fallen
-
„Wir machen das wie früher“
-
kein Standard-Setup für Monitoring/Backup/Updates
-
keine Runbooks/Notfallpläne
Best Practices:
-
Standardisierung (Landing Zone)
-
Automatisierung (IaC, CI/CD)
-
dokumentierte Betriebsprozesse
Erfolg messbar machen: KPIs, die Management überzeugt
Damit Manager nicht „glauben müssen“, sondern sehen, dass Cloud wirkt:
Kosten
-
Kosten pro Workload/Team/Umgebung
-
Einsparungen durch Right-Sizing/Abschaltung
-
Anteil „Managed Services“ vs. „selbst betrieben“
Betrieb
-
Anzahl Incidents, MTTR (Zeit bis Wiederherstellung)
-
Verfügbarkeit / SLA-nahe Werte
-
Patch-/Update-Zeiten
Delivery
-
Release-Frequenz
-
Lead Time (Idee → Produktion)
-
Fehlerquote nach Deployments
Sicherheit
-
MFA/Conditional Access Abdeckung (für Identitäten)
-
kritische Findings und Remediation-Zeiten
-
Log-Abdeckung (was wird überhaupt überwacht?)
So gehen wir typischerweise vor
Damit aus Cloud ein Business-Vorteil wird, arbeiten wir meist in klaren Schritten:
1. Assessment & Transparenz
Kosten, technische Schulden, Risiken, Quick Wins
2. Zielbild & Priorisierung
Welche Workloads: Lift&Shift vs. Replatform vs. Refactor?
3. Landing Zone & Governance
Rollen/Rechte, Policies, Netzwerk, Logging, Kostenregeln
4. Pilot & Blaupause
1–2 Workloads sauber umsetzen → Standard etablieren
5. Migration & Modernisierung im Rollout
wiederholbar, dokumentiert, mit Tests
6. Betrieb & Optimierung (Managed)
Monitoring, Security-Checks, Backup, FinOps, Doku
Quick-Check: Wie Cloud-reif ist eure Umgebung?
Wenn ihr euch fragt, ob eure Cloud-Umgebung wirklich die Vorteile liefert:
CodeKlar Cloud Quick-Check (ca. 30 Minuten):
-
Wir identifizieren typische Lift-&-Shift-Kostenfallen
-
Wir zeigen 5 Maßnahmen mit dem größten Effekt (Kosten/Betrieb/Security)
-
Auf Wunsch bekommt ihr eine kurze Roadmap (Replatforming/Refactoring)