Cloud-Migration für KMU: Schritt für Schritt richtig planen

Kurz gesagt: Eine Cloud-Migration ist der geplante Umzug von Anwendungen, Daten und Diensten von den eigenen Servern in eine Cloud-Infrastruktur, in einer festgelegten Reihenfolge. Für KMU heißt eine erfolgreiche Cloud-Migration: zuerst Inventar und Abhängigkeiten erfassen, Workloads in Wellen vom unkritischsten zum kritischsten System verschieben und für jeden Workload Ausfallfenster und Rollback-Plan festlegen, bevor etwas umzieht.

In vielen Unternehmen kommt das Thema Cloud auf, weil Hardware erneuert werden muss, der Serverraum ausgefallen ist oder Mitarbeitende zuverlässig von unterwegs arbeiten sollen. Die Entscheidung fällt schnell, der Umzug selbst wird aber oft nach dem Motto „Das erledigen wir an einem Wochenende“ geplant. Das Ergebnis ist bekannt: ein ERP, das am Montagmorgen wegen einer vergessenen Abhängigkeit nicht startet, eine Datenübertragung, die viel länger dauert als gedacht, und nächtliche Reparaturen, weil niemand einen Weg zurück definiert hat.

Dieser Leitfaden behandelt die Cloud-Migration als gesteuertes Projekt statt als Serverumzug und geht Vorbereitung, Reihenfolge, Ausfallzeit und Rollback Schritt für Schritt durch.

Was eine Cloud-Migration ist und was nicht

Bei einer Cloud-Migration ziehen Workloads wie Dateiserver, E-Mail, ERP, Datenbanken oder Individualsoftware aus der eigenen Umgebung (On-Premises) zu einem Cloud-Anbieter um. Nicht jeder Workload braucht denselben Ansatz. Die gängigsten Varianten:

• Rehost („Lift and Shift“): die virtuelle Maschine unverändert in die Cloud verschieben. Der schnellste Weg, Kosten- und Leistungsoptimierung folgen später.
• Replatform: die Anwendung weitgehend beibehalten, aber eine Komponente wie die Datenbank auf einen verwalteten Cloud-Dienst umstellen.
• Refactor: die Anwendung so umbauen, dass sie Cloud-native Dienste nutzt. Mehr Aufwand, langfristig mehr Flexibilität.
• Ersetzen oder stilllegen: Manche Systeme ziehen gar nicht um; sie werden durch ein SaaS-Produkt ersetzt oder abgeschaltet, wenn sie niemand mehr nutzt.

Eine Cloud-Migration spart nicht automatisch Kosten. Server, die ohne passende Dimensionierung umziehen, sind auch in der Cloud überdimensioniert und oft teurer. Deshalb sollte die Entscheidung pro Workload fallen. Wenn Sie abwägen, wo Ihr ERP laufen soll, hilft unser Vergleich Cloud-ERP oder On-Premise-ERP beim Einstieg.

Vor dem Umzug: Inventar, Ziele und Team

1. Inventar erstellen

Erfassen Sie alle Server, Anwendungen, Datenbanken und geplanten Aufgaben mit verantwortlicher Person und Geschäftskritikalität. Notieren Sie auch die Lizenzbedingungen; manche Software wird in der Cloud anders lizenziert. Fehlt ein aktuelles Bild Ihrer Umgebung, erspart ein vorgeschaltetes IT-Infrastruktur-Audit viele Überraschungen.

2. Ziel pro Workload festlegen

„In die Cloud“ ist für sich kein Ziel. Machen Sie die Erwartung pro Workload konkret: sicherer Fernzugriff, keine neue Hardware anschaffen, einfachere Datensicherung und Notfallwiederherstellung oder Skalierung für saisonale Spitzen. Ist das Ziel klar, ergeben sich Migrationsansatz und Erfolgskriterien fast von selbst.

3. Kompetenzen im Team prüfen

Wer betreibt die Cloud-Umgebung? Fehlt im Team Erfahrung mit Identitätsverwaltung, Netzwerk, Backup und Kostenkontrolle in der Cloud, schließen Sie die Lücke mit Schulung oder externer Unterstützung. Auch Microsofts Leitfaden zur Migrationsplanung im Cloud Adoption Framework empfiehlt, die Fähigkeiten des Teams vor dem Start zu bewerten und bei fehlender Erfahrung externe Expertise hinzuzuziehen.

Der Plan für die Cloud-Migration: Abhängigkeiten, Wellen und Rollback

4. Abhängigkeiten abbilden

Anwendungen hängen voneinander ab: Das ERP braucht eine Datenbank, das Reporting-Tool das ERP, der Etikettendrucker im Lager einen lokalen Server. Komponenten, die direkt und mit geringer Latenz miteinander kommunizieren, ziehen gemeinsam um. Sind Sie unsicher, wie kritisch eine Abhängigkeit ist, lassen Sie die Komponenten zusammen; eine Gruppe lässt sich später immer noch trennen, ein versehentlich getrenntes System steht dagegen am Migrationstag still.

5. Workloads in Wellen aufteilen

In die erste Welle gehören weniger kritische, eigenständige Workloads: Testumgebungen, interne Werkzeuge, Archivdaten. Hat das Team den Ablauf daran erprobt, folgen kritische Systeme in späteren Wellen. Testumgebungen vor der Produktion zu migrieren ist der sicherste Weg, Konfiguration und Leistung zu prüfen, ohne Anwender zu beeinträchtigen.

6. Ausfallfenster wählen

Legen Sie mit dem jeweiligen Fachbereich schriftlich fest, wie lange ein Workload ausfallen darf. Für Systeme, die eine geplante Unterbrechung vertragen, ist eine Migration mit Ausfallzeit einfacher und schneller. Kundennahe oder durchgehend genutzte Systeme brauchen ein Verfahren mit nahezu keiner Ausfallzeit: Die Daten werden vorab repliziert, die eigentliche Umschaltung dauert nur kurz. Monatsabschluss, Aktionszeiträume und Inventurtage gehören nicht in den Migrationskalender.

7. Rollback-Plan vorab schreiben

Definieren Sie vor dem Start, wann eine Migration als gescheitert gilt: Die Anwendung startet nicht, die Antwortzeiten sind inakzeptabel, Daten fehlen oder es gibt einen Sicherheitsbefund. Beschreiben Sie Schritt für Schritt, wie Sie in die alte Umgebung zurückkehren und wer das entscheidet, und proben Sie es in einer Testumgebung. Schalten Sie die lokalen Server erst ab, wenn die Migration geprüft ist und die Anwender sie abgenommen haben.

Migrationstag und danach

• Letztes Backup erstellen und Wiederherstellung testen: Entscheidend ist nicht, dass es ein Backup gibt, sondern dass Sie daraus wiederherstellen können. Unser Leitfaden zum Disaster-Recovery-Plan erklärt, wie Sie RPO- und RTO-Ziele festlegen.
• Abnahmetests mit echten Anwendern: Die Migration ist erst fertig, wenn Buchhaltung, Vertrieb und Lager ihre täglichen Aufgaben in der neuen Umgebung ausprobiert haben.
• Zugriffe absichern: Für die Cloud-Verwaltungskonsole und jeden Fernzugriff sollte Multi-Faktor-Authentifizierung (MFA) Pflicht sein.
• Kosten ab dem ersten Tag beobachten: ungenutzte Ressourcen abschalten, Server an die tatsächliche Nutzung anpassen und Budgetwarnungen einrichten.
• Dokumentation aktualisieren: Sind neue IP-Adressen, Zugriffswege und Zuständigkeiten nicht dokumentiert, kostet die erste Störung unnötig Zeit.

Häufige Fehler

• Alles auf einmal umziehen: Bei einem großen Einmal-Umzug legt ein einzelner Fehler das ganze Unternehmen lahm.
• Abhängigkeiten nur vermuten: Eine undokumentierte Schnittstelle oder geplante Aufgabe hört nach dem Umzug still auf zu funktionieren.
• Übertragungszeit unterschätzen: Für große Datenbanken und Dateiarchive muss die Leitungskapazität vorher getestet werden.
• Kein Rollback-Plan: „Wir schauen, wenn etwas schiefgeht“ heißt, dass im Ernstfall niemand entscheiden darf.
• Zu früh fertig sein: Werden Dimensionierung, Kosten und Sicherheitseinstellungen in den Wochen nach dem Umzug nicht überprüft, geht ein Großteil des Nutzens verloren.

Checkliste Cloud-Migration

• Liegt das Inventar aus Servern, Anwendungen, Datenbanken und Aufgaben mit Verantwortlichen vor?
• Sind Ziel und Migrationsansatz für jeden Workload festgehalten?
• Sind Abhängigkeitsgruppen und Migrationswellen definiert?
• Sind Ausfallfenster mit den Fachbereichen abgestimmt und kritische Termine ausgespart?
• Sind Abbruchkriterien und Rollback-Schritte dokumentiert und getestet?
• Ist geklärt, wer nach dem Umzug für Sicherheit, Kosten und Dokumentation zuständig ist?

In der richtigen Reihenfolge und mit offenem Rückweg ist eine Cloud-Migration ein kontrollierter Wandel, der dem Unternehmen mehr Flexibilität gibt. Bei ÇAP Teknoloji planen wir Cloud-Migrationen gemeinsam mit KMU: von Inventar und Abhängigkeitsanalyse über die Wellenplanung und Rollback-Szenarien bis zur Kostenkontrolle nach dem Umzug. Lernen Sie unsere Beratungsleistungen kennen oder nehmen Sie Kontakt auf, um Ihre aktuelle Umgebung gemeinsam zu bewerten.

Häufig gestellte Fragen