Cloud-Migration für den Mittelstand: 7 Fehler, die Geld kosten – und wie KMU sie vermeiden

Cloud-Migration ist für viele Mittelständler zum Pflichtthema geworden. Microsoft 365, Azure, AWS – kaum ein Unternehmen arbeitet heute noch rein On-Premises. Gleichzeitig hat kaum ein Projekt so viel Frust produziert. Wir begleiten seit Jahren Migrationen im KMU und sehen immer wieder dieselben Fehler. Dieser Beitrag fasst die sieben teuersten davon zusammen – und zeigt, wie eine saubere Cloud-Migration im Mittelstand gelingt. Die sieben Fehler sind keine theoretischen Konstrukte, sondern haben alle einen realen Projekthintergrund – aus Cloud-Migrationen, die wir in den letzten drei Jahren in Süddeutschland begleitet, gerettet oder umgebaut haben.

Fehler 1: Die Migration startet ohne Zielbild

Wir müssen in die Cloud ist keine Strategie. Es ist ein Wunsch. Wer migriert, ohne das Ziel zu kennen (Skalierung? Kostenreduktion? Resilienz? Time-to-Market?), optimiert im Blindflug. Die Folge: Architektur-Entscheidungen wirken später wie willkürlich. Schreiben Sie vor dem ersten Projekt zwei Absätze: Warum migrieren wir und Woran messen wir den Erfolg. Das klingt banal – und verhindert 80 Prozent der späteren Grabenkämpfe. Ergänzen Sie diese zwei Absätze um eine kurze, schriftliche Antwort auf die Frage: Was machen wir nicht? – die Definition des Out-of-Scope ist oft wichtiger als die der Ziele.

Fehler 2: Lift-and-Shift wird als Endzustand gedacht

Die schnelle Migration einer lokalen VM in die Cloud (Lift-and-Shift) ist ein legitimer Zwischenschritt – aber nie das Ziel. Wer so bleibt, zahlt für Cloud-Infrastruktur, ohne Cloud-Vorteile zu nutzen. Die Rechnung kommt nach 12 Monaten: deutlich höhere Kosten als On-Prem, ohne die Skalierungs- und Automatisierungsvorteile der Cloud. Planen Sie von Anfang an die zweite Stufe: Re-Platforming oder Re-Architecting – für kritische Systeme.

Fehler 3: Kosten werden auf Monatsbasis kalkuliert, aber auf Jahresbasis bezahlt

Cloud-Kosten wirken in der ersten Monatsrechnung überschaubar. Die Überraschung kommt oft im dritten oder sechsten Monat, wenn Traffic, Storage, Backups und unerwartet skalierende Services sichtbar werden. Der typische Effekt: 30 bis 60 Prozent höhere Kosten als ursprünglich kalkuliert. Gegenmaßnahme: Ein FinOps-Prozess ab Tag 1. Tagging-Standards, Budget-Alerts, Reserved Instances dort, wo die Last vorhersehbar ist. Tools wie Sastrify, Vantage oder die nativen Cloud-Cost-Tools sind Pflicht, keine Kür.

Zwei Werte helfen, die Gefahr früh zu entschärfen: Ein Cost-Ownership-Modell je Workload (wer zahlt was? wer darf skalieren?) und eine monatliche Cost-Review-Runde mit Fachbereich, IT und Finanz. Wo diese Disziplin fehlt, explodieren die Kosten nicht wegen der Cloud, sondern wegen fehlender Governance.

Fehler 4: Security wird nachträglich angebaut

Die Cloud ist nicht unsicherer als On-Prem – aber anders. Viele Mittelständler übernehmen On-Prem-Denkmuster (Perimeter, Firewalls) und verpassen, was Cloud-Security eigentlich bedeutet: Identity-based Access, Zero Trust, kontinuierliche Konfigurations-Audits. Besonders gefährlich: falsch konfigurierte Cloud-Speicher (S3-Buckets, Azure Blobs), die öffentlich erreichbar sind. Planen Sie Security als Architekturprinzip, nicht als Abschluss-Aufgabe.

Konkrete Mindeststandards in der Cloud: Identitätsbasierter Zugang mit MFA, kontinuierliche Compliance-Scans (z. B. mit Microsoft Defender for Cloud oder AWS Security Hub), Verschlüsselung at rest und in transit als Default, klare Trennung von Produktions- und Entwicklungsumgebungen. Wer diese vier Punkte ab Tag 1 setzt, vermeidet später teure Nachrüstungen und unangenehme Audit-Befunde.

Fehler 5: Der Kompetenz-Gap wird unterschätzt

Ein erfahrener On-Prem-Admin ist nicht automatisch ein Cloud-Architekt. Cloud-Know-how ist eine eigene Disziplin, und der Mittelstand konkurriert beim Recruiting mit Konzernen. Wer die Migration mit dem bestehenden Team ohne Schulung, Partner oder externe Verstärkung stemmt, produziert Technik-Schulden im Express-Tempo. Realistisch sind: Fortbildungsbudget für das eigene Team plus ein externer Partner in den ersten 6 bis 12 Monaten.

Praktische Faustregel aus unseren Projekten: Planen Sie pro aktiv migriertem Admin zwei bis drei Wochen Schulungs- und Schatten-Zeit mit einem erfahrenen Cloud-Engineer ein. Das klingt viel – ist aber deutlich günstiger als eine Migration, die nach sechs Monaten zurückgebaut werden muss, weil niemand im Team sauber operieren kann.

Fehler 6: Die Lieferanten-Abhängigkeit wird verharmlost

Cloud-Plattformen bieten unschlagbare Managed Services. Aber sie koppeln das Unternehmen an den Anbieter. Ein Exit kostet – technisch und vertraglich. Im Mittelstand entscheidet das oft die Verhandlungsmacht bei der nächsten Preiserhöhung. Was hilft: Portabilität bewusst entscheiden (Container, Kubernetes, offene Formate), zweite Cloud für nicht-kritische Workloads prüfen, Vertragsklauseln zu Daten-Export und Preisstabilität verhandeln.

Fehler 7: Die Organisation migriert nicht mit

Eine Cloud-Migration ist zu 40 Prozent ein Organisationsthema. Neue Rollen (FinOps, Cloud Engineer, Security Engineer), neue Prozesse (Infrastructure as Code, CI/CD, kontinuierliche Compliance), neue Entscheidungswege. Wer die Technik migriert, aber die Organisation unverändert lässt, produziert eine Cloud, die wie ein teures On-Prem betrieben wird. Reservieren Sie mindestens 20 Prozent des Migrationsbudgets für Change-Management, Schulung und Prozessarbeit.

Ein praxistaugliches Format ist die Cloud-Community-of-Practice – ein wöchentlicher 60-Minuten-Termin, in dem das IT-Team Erfahrungen, Probleme und neue Patterns austauscht. Diese kleine Investition beschleunigt die Lernkurve dramatisch und verhindert, dass Wissen nur in den Köpfen einzelner Personen entsteht.

Die fünf Migrationsmuster im Überblick

Bevor Sie eine Anwendung migrieren, entscheiden Sie das Muster. Die sogenannten 6 Rs (Gartner) sind im Mittelstand praxistauglich in fünf Varianten:

• Rehost (Lift-and-Shift) – Anwendung wird unverändert in eine Cloud-VM verschoben. Schnell, aber selten wirtschaftlich auf Dauer.

• Replatform – Teile werden durch Managed Services ersetzt (Datenbank in RDS statt Eigenbetrieb). Mittlerer Aufwand, guter Hebel.

• Rearchitect – Anwendung wird cloud-nativ umgebaut (Container, Microservices, serverless). Hoher Aufwand, maximaler Hebel – nur für echt werthaltige Systeme.

• Repurchase – bestehende Software wird durch eine SaaS-Alternative ersetzt. Oft die pragmatischste Entscheidung für Standard-Workloads (Ticket-System, CRM, ERP).

• Retire – Anwendung wird abgeschaltet. Jedes Migrationsprojekt bringt mindestens 10 bis 15 Prozent retirement-fähige Systeme ans Licht. Diese Ersparnis finanziert oft einen Teil des Projekts.

Wir empfehlen, pro Anwendung eine bewusste Entscheidung zu dokumentieren – inklusive der Begründung. Das spart später Diskussionen und macht die Architektur-Logik nachvollziehbar.

In unseren Projekten verteilt sich das Mengengerüst typischerweise wie folgt: 40 Prozent Rehost (für unkritische, kurzlebige Workloads), 25 Prozent Replatform (für Mittel-Kritisches mit klarem Cloud-Vorteil), 10 Prozent Rearchitect (für strategische Anwendungen), 15 Prozent Repurchase (Software-Ablöse), 10 Prozent Retire. Wer diese Verteilung in seiner eigenen Landschaft kennt, hat einen sehr realistischen Migrationsfahrplan – und vermeidet es, alle Anwendungen über denselben Kamm zu scheren.

Checkliste für eine saubere Cloud-Migration

Bevor Sie starten, prüfen Sie diese Punkte schriftlich:

• Geschäftsziele der Migration sind in zwei Absätzen festgehalten.

• Ein Migrationsszenario pro kritischem System ist beschrieben (Rehost, Replatform, Rearchitect, Replace, Retire).

• Kostenbudget inklusive 30 Prozent Puffer und FinOps-Prozess ab Tag 1 steht.

• Security-Architektur ist mit den Anwendungen mitgedacht (Identity, Netzwerk, Daten).

• Schulungsplan für das IT-Team ist budgetiert und terminiert.

• Externer Migrationspartner ist evaluiert oder ausgeschlossen.

• Exit- und Daten-Portabilitäts-Klauseln sind im Vertrag.

• Change-Management-Spur parallel zur Technik-Spur ist geplant.

Fazit: Cloud ist ein Werkzeug – kein Ziel

Die besten Cloud-Migrationen im Mittelstand, die wir gesehen haben, begannen nicht mit einer Technologie-Entscheidung. Sie begannen mit einer Geschäftsfrage: Wo wollen wir in drei Jahren stehen, und welche IT bringt uns dahin? Wer diese Frage beantwortet, migriert gezielt. Wer sie überspringt, migriert irgendwie – und zahlt dafür doppelt.

CALL-TO-ACTION

→ Wir führen einen 2-Stunden-Cloud-Readiness-Workshop mit Ihnen und Ihrer IT durch – praxisnah, ohne Folienschlacht.

Häufige Fragen (FAQ)

Diese Q&A-Blöcke eignen sich für FAQ-Schema-Markup und Google-SGE-Featured-Snippets.

F1. Welche Cloud passt zu einem Mittelständler aus DACH?

Für Microsoft-Umgebungen ist Azure meist der kürzeste Weg. Für spezifische Workloads (Data, KI, Entwicklung) ist AWS oder Google Cloud oft stark. Entscheidend ist nicht der Anbieter, sondern die Passung zur vorhandenen Architektur.

F2. Wie lange dauert eine typische Cloud-Migration?

Für ein Unternehmen mit 100 Mitarbeitern und durchschnittlicher Komplexität zwischen 4 und 12 Monaten. Reine Lift-and-Shift-Migrationen sind schneller, liefern aber weniger Wert.

F3. Lohnt sich Hybrid Cloud für den Mittelstand?

Ja, oft ist ein hybrider Ansatz pragmatischer als Alles-oder-Nichts. Kritische Systeme bleiben On-Prem oder in einer Private Cloud, Standard-Workloads gehen in die Public Cloud.

F4. Wie verhindere ich Kostenüberraschungen in der Cloud?

Mit einem FinOps-Prozess ab Tag 1: Tagging-Standards, Budget-Alerts, regelmäßige Reviews, Reserved Instances für vorhersehbare Lasten, automatisierte Ressourcen-Abschaltung außerhalb der Geschäftszeiten.