Warum „einfach in die Cloud schieben" nicht funktioniert

Cloud Computing verspricht Flexibilität, Skalierbarkeit und geringere Investitionskosten. Diese Versprechen sind real — aber nur, wenn die Migration durchdacht geplant wird. Wer ohne Strategie migriert — das sogenannte „Lift and Shift" — erlebt häufig das Gegenteil: höhere Kosten, schlechtere Performance und neue Komplexität.

Der Grund: On-Premise-Systeme und Cloud-Systeme funktionieren nach unterschiedlichen Prinzipien. Was auf einem eigenen Server effizient läuft, kann in der Cloud unnötig teuer werden — und umgekehrt. Eine erfolgreiche Migration beginnt deshalb nicht mit der Technik, sondern mit einer ehrlichen Bestandsaufnahme.

Phase 1: Bestandsaufnahme — Was haben Sie?

Bevor Sie irgendetwas migrieren, brauchen Sie ein vollständiges Bild Ihrer aktuellen IT-Landschaft.

Hardware und Software inventarisieren

Listen Sie systematisch auf: - Server: Wie viele physische und virtuelle Server betreiben Sie? Welche Betriebssysteme und Versionen laufen darauf? - Anwendungen: Welche Software läuft auf welchem Server? Welche Abhängigkeiten bestehen zwischen den Anwendungen? - Datenbanken: Welche Datenbanken gibt es, wie groß sind sie, und wer greift darauf zu? - Netzwerk: Wie sind die Systeme untereinander und mit dem Internet verbunden? Welche Bandbreite wird benötigt? - Speicher: Wie viel Speicherplatz wird aktuell genutzt? Wie schnell wächst der Bedarf?

Kosten transparent machen

Viele Unternehmen unterschätzen ihre aktuellen IT-Kosten, weil sie auf verschiedene Budgets verteilt sind. Erfassen Sie: - Hardwarekosten (Server, Switches, USV, Klimatisierung) - Lizenzkosten (Betriebssysteme, Datenbanken, Anwendungen) - Personalkosten für Administration und Wartung - Stromkosten für den Serverraum - Kosten für externe Dienstleister

Erst wenn Sie wissen, was Ihre aktuelle Infrastruktur wirklich kostet, können Sie einen sinnvollen Vergleich mit Cloud-Angeboten anstellen.

Abhängigkeiten verstehen

Zeichnen Sie eine Karte, welche Systeme miteinander kommunizieren. In den meisten Unternehmen gibt es überraschende Abhängigkeiten. Die Buchhaltungssoftware greift auf denselben Datenbankserver zu wie das CRM. Der Druckserver braucht Zugang zum Fileserver, und die VoIP-Anlage setzt eine bestimmte Netzwerkkonfiguration voraus.

Diese Abhängigkeiten bestimmen die Reihenfolge der Migration. Systeme, die stark miteinander verknüpft sind, sollten gemeinsam migriert werden.

Phase 2: Strategie — Was soll wohin?

Nicht alles gehört in die Cloud. Für jedes System und jede Anwendung gibt es vier Optionen:

Retain — Behalten

Manche Systeme bleiben besser, wo sie sind. Typische Gründe: - Regulatorische Anforderungen (bestimmte Daten dürfen Deutschland/die EU nicht verlassen) - Extrem latenzempfindliche Anwendungen - Legacy-Software, die nicht cloud-kompatibel ist und bald abgelöst wird

Rehost — 1:1 in die Cloud verschieben

Die schnellste Methode: Die bestehende Anwendung wird als virtuelle Maschine in der Cloud betrieben. Vorteil: Schnell umgesetzt. Nachteil: Sie nutzen die Cloud-Vorteile (Skalierung, Managed Services) nicht voll aus.

Sinnvoll für: Anwendungen, die zeitnah migriert werden müssen, aber langfristig neu aufgebaut werden sollen.

Replatform — Anpassen und migrieren

Die Anwendung wird leicht angepasst, um Cloud-Dienste zu nutzen — zum Beispiel wird die Datenbank von einem selbst verwalteten MySQL-Server auf eine verwaltete Datenbank wie Azure SQL oder Amazon RDS umgestellt.

Sinnvoll für: Anwendungen, die langfristig in der Cloud bleiben und deren Betriebsaufwand Sie reduzieren möchten.

Replace — Ersetzen

Statt eine alte Anwendung zu migrieren, ersetzen Sie sie durch einen Cloud-nativen Dienst. Beispiel: Der lokale Exchange-Server wird durch Microsoft 365 ersetzt.

Sinnvoll für: Standard-Software, für die es ausgereifte Cloud-Alternativen gibt.

Phase 3: Pilotmigration — Klein anfangen

Migrieren Sie nicht alles auf einmal. Wählen Sie ein System mit geringem Risiko und mittlerem Nutzen als Pilotprojekt.

Gute Pilotprojekte: - Fileserver / Dokumentenmanagement → SharePoint oder Cloud-Speicher - E-Mail → Microsoft 365 oder Google Workspace - Entwicklungs- und Testumgebungen → Cloud-VMs - Backup → Cloud-Backup als zweites Standbein

Schlechte Pilotprojekte: - ERP-System (zu komplex, zu viele Abhängigkeiten) - Produktionsdatenbank (zu hohes Risiko) - VoIP-Anlage (latenzempfindlich, erfordert Netzwerkumbau)

Nutzen Sie das Pilotprojekt, um Erfahrungen zu sammeln: Wie gut funktioniert die Anbindung? Stimmt die Performance? Wie reagieren die Mitarbeitenden? Welche unerwarteten Probleme treten auf?

Phase 4: Schrittweise Migration

Nach einem erfolgreichen Piloten migrieren Sie die verbleibenden Systeme in geplanten Wellen. Jede Welle umfasst Systeme mit ähnlichen Anforderungen und Abhängigkeiten.

Migrationswellen planen

WelleSystemeDauer
1 (Pilot)Fileserver, Backup2-4 Wochen
2E-Mail, Collaboration2-4 Wochen
3Datenbanken, Webanwendungen4-8 Wochen
4ERP, Fachanwendungen6-12 Wochen

Zwischen den Wellen: Evaluieren, anpassen, optimieren.

Parallelbetrieb einplanen

Schalten Sie die alten Systeme nicht sofort ab. Betreiben Sie für jede Welle einen Parallelbetrieb von mindestens zwei Wochen, in dem sowohl das alte als auch das neue System verfügbar sind. Das gibt Ihnen die Möglichkeit, bei Problemen schnell zurückzuschalten.

Phase 5: Optimierung — Cloud richtig nutzen

Nach der Migration beginnt die eigentliche Arbeit. Cloud-Infrastruktur verhält sich anders als On-Premise-Systeme, und die Kostenstruktur erfordert aktives Management.

Kosten überwachen

Cloud-Dienste rechnen nach Verbrauch ab. Was auf den ersten Blick günstig wirkt, kann ohne Kontrolle schnell teuer werden. Richten Sie von Anfang an ein Kosten-Monitoring ein: - Budgets und Alerts in Azure Cost Management oder AWS Budgets - Regelmäßige Reviews (monatlich): Welche Ressourcen werden genutzt, welche laufen ungenutzt? - Reserved Instances für stabile Workloads — bis zu 60 Prozent günstiger als On-Demand-Preise

Sicherheit anpassen

Die Cloud erfordert ein anderes Sicherheitsmodell als On-Premise. Statt eines Perimeters (Firewall um alles herum) gilt das Zero-Trust-Prinzip: Jeder Zugriff wird geprüft, unabhängig davon, woher er kommt.

  • Identitätsmanagement zentralisieren (Microsoft Entra ID (ehemals Azure AD), Google Identity)
  • Least Privilege konsequent umsetzen — jeder Benutzer und jede Anwendung bekommt nur die Rechte, die tatsächlich benötigt werden
  • Verschlüsselung für Daten in Ruhe und in Bewegung aktivieren
  • Logging und Monitoring einrichten — Sie müssen wissen, wer wann auf was zugreift

Häufige Fehler bei der Cloud-Migration

Kein Rückfallplan. Was passiert, wenn die Migration eines Systems schiefgeht? Ohne definierten Rollback-Prozess stehen Sie im schlimmsten Fall ohne funktionierendes System da — weder alt noch neu.

Bandbreite unterschätzen. Cloud-Systeme brauchen eine stabile, schnelle Internetverbindung. Prüfen Sie vor der Migration, ob Ihre Leitung ausreicht — besonders für datenintensive Anwendungen wie Fileserver oder Datenbanken.

Vendor Lock-in ignorieren. Je stärker Sie die spezifischen Dienste eines Cloud-Anbieters nutzen, desto schwieriger wird ein späterer Wechsel. Das muss kein Problem sein — aber es sollte eine bewusste Entscheidung sein, keine versehentliche.

Schulung vergessen. Cloud-Systeme sehen anders aus und funktionieren anders. Investieren Sie Zeit in die Schulung Ihrer Mitarbeitenden — sowohl für Administratoren als auch für Endanwender.

Fazit

Eine Cloud-Migration ist kein IT-Projekt, sondern ein Veränderungsprojekt, das die gesamte Organisation betrifft. Der technische Teil — Server verschieben, Daten kopieren, Dienste konfigurieren — ist oft der einfachere Teil. Die Herausforderung liegt in der Planung, der Kommunikation und dem Change Management.

Nehmen Sie sich die Zeit für eine gründliche Vorbereitung. Ein Monat mehr Planungszeit spart drei Monate Nacharbeit.