Eine Cloud-Migration verlagert Anwendungen, Daten und Dienste aus dem eigenen Serverraum zu einem Cloud-Anbieter. Das klingt nach einem Umzug von Technik. In der Praxis ändern sich aber auch Zuständigkeiten, Verträge und Abläufe. Dieser Beitrag beschreibt einen Fahrplan in sieben Schritten, mit dem mittelständische Unternehmen den Weg in die Cloud planbar gestalten.
Drei Fragen behandeln wir in eigenen Ratgebern: Ob ein Dienst überhaupt in die Cloud gehört, klärt der Beitrag Cloud für Unternehmen. Ob Sie mehrere Anbieter kombinieren sollten, lesen Sie unter Multi-Cloud-Strategie. Wie der Betrieb nach der Migration geregelt wird, beschreibt Managed Services Cloud.
Warum eine Cloud-Migration einen Plan braucht
Das Bundesamt für Sicherheit in der Informationstechnik (BSI) beschreibt Cloud Computing als bedarfsgerecht angepasstes Anbieten, Nutzen und Abrechnen von IT-Dienstleistungen über ein Netz. Dazu gehören Infrastruktur wie Rechenleistung und Speicher, Plattformen und fertige Software.
Im IT-Grundschutz-Baustein OPS.2.2 „Cloud-Nutzung“ hält das BSI fest, dass sich die erwarteten Vorteile in der Praxis häufig nicht vollständig einstellen. Als Ursache nennt es meist kritische Erfolgsfaktoren, die vor der Cloud-Nutzung nicht ausreichend betrachtet wurden (BSI, OPS.2.2 Cloud-Nutzung, Edition 2023). Der folgende Fahrplan orientiert sich an diesem Baustein und am Cloud Adoption Framework von Microsoft, einem Leitfaden für die Einführung von Cloud-Diensten.
Schritt 1: Ziele und Cloud-Strategie festlegen
Am Anfang steht die Frage, was die Cloud für Ihr Unternehmen leisten soll. Der Baustein OPS.2.2 sieht dafür eine Strategie für die Cloud-Nutzung vor. Sie beschreibt Ziele, Chancen und Risiken, rechtliche und organisatorische Rahmenbedingungen sowie technische Anforderungen. Außerdem legt sie fest, welche Dienste in welchem Bereitstellungsmodell bezogen werden sollen, also etwa aus einer öffentlichen Cloud (Public Cloud) oder einer nur für Sie betriebenen Umgebung (Private Cloud). Für größere Vorhaben empfiehlt das BSI eine Roadmap, die festlegt, wann und wie ein Cloud-Dienst eingeführt wird.
Formulieren Sie die Ziele prüfbar. „Modern werden“ ist kein Ziel. „Der Fileserver wird bis zum Ende des Wartungsvertrags abgelöst“ ist eines.
Schritt 2: Bestand und Abhängigkeiten erfassen
Erfassen Sie alle Anwendungen, Server, Datenbestände und Schnittstellen. Notieren Sie je System, wer es fachlich verantwortet, wie wichtig es für den Betrieb ist und mit welchen anderen Systemen es Daten austauscht. Das BSI empfiehlt, alle geplanten und genutzten Cloud-Dienste zu dokumentieren und für jeden Dienst eine Service-Definition zu erstellen, also eine Beschreibung, was der Dienst leisten muss.
Gerade die Abhängigkeiten werden oft unterschätzt. Eine Warenwirtschaft, die nachts Daten an eine Buchhaltungssoftware übergibt, lässt sich nur zusammen mit dieser Schnittstelle sinnvoll umziehen.
Schritt 3: Für jede Anwendung den Migrationsweg wählen
Nicht jede Anwendung wird auf dieselbe Weise migriert. Microsoft beschreibt im Cloud Adoption Framework acht Strategien, die je Arbeitslast gewählt werden (Microsoft Learn: Auswählen Ihrer Cloudmigrationsstrategien):
| Strategie | Was passiert | Passt, wenn … |
|---|---|---|
| Ablösen (Retire) | Die Anwendung wird außer Betrieb genommen. | sie kaum noch Nutzen bringt. |
| Beibehalten (Retain) | Die Anwendung bleibt, wo sie ist. | sie stabil läuft oder aus rechtlichen oder technischen Gründen nicht umziehen kann. |
| Rehost | Umzug mit minimalen Änderungen, etwa als virtueller Server. | die Anwendung stabil ist und keine baldige Modernisierung ansteht. |
| Replatform | Wechsel auf Plattformdienste mit wenig Codeänderung, etwa eine verwaltete Datenbank. | Wartung von Betriebssystemen und Lizenzen sinken soll. |
| Refactor | Der Programmcode wird überarbeitet. | technische Altlasten abgebaut werden sollen. |
| Rearchitect | Die Architektur der Anwendung wird umgebaut. | Teile unabhängig voneinander skalieren müssen. |
| Rebuild | Die Anwendung wird mit Cloud-Diensten neu entwickelt. | das Altsystem zu unflexibel geworden ist. |
| Replace | Eine fertige Cloud-Software (Software as a Service, SaaS) ersetzt die Anwendung. | ein Standardprodukt die Anforderungen mit wenig Anpassung erfüllt. |
Zwei Hinweise von Microsoft sind für den Mittelstand besonders nützlich. Erstens behebt ein reiner Umzug (Rehost) keine bestehenden Leistungs- oder Architekturprobleme. Zweitens eignet sich Rehost laut Microsoft nur, wenn die Anwendung mindestens zwei Jahre ohne Modernisierung bleiben kann. Sonst entsteht doppelter Aufwand.
Schritt 4: Anbieter auswählen und Vertrag gestalten
Für die Auswahl empfiehlt das BSI ein Anforderungsprofil mit Leistungsbeschreibung. Im Vertrag sollten nach OPS.2.2 unter anderem geregelt sein:
- der Standort, an dem der Anbieter die Leistung erbringt,
- Eskalationsstufen und Kommunikationswege,
- das sichere Löschen Ihrer Daten,
- Kündigungsregelungen und die geordnete Beendigung,
- die Offenlegung aller Subunternehmen.
Lassen Sie sich die Informationssicherheit des Anbieters regelmäßig nachweisen. Das BSI nennt dafür unter anderem ISO/IEC 27001 und den eigenen Kriterienkatalog C5. Prüfen Sie dabei, ob der Geltungsbereich des Nachweises den genutzten Dienst tatsächlich umfasst.
Verarbeitet der Anbieter personenbezogene Daten in Ihrem Auftrag, ist das in der Regel eine Auftragsverarbeitung nach Art. 28 DSGVO. Die Datenschutzkonferenz nennt Cloud-Computing ohne inhaltlichen Datenzugriff des Betreibers ausdrücklich als Beispiel. Liegt der Anbieter außerhalb der EU oder des EWR, gelten zusätzlich die Anforderungen der Art. 44 ff. DSGVO (Datenschutzkonferenz, Kurzpapier Nr. 13).
Schritt 5: Migration und Einbindung planen
Vor dem Umzug sollte ein Migrationskonzept stehen. Das BSI nennt dafür organisatorische Regelungen und die Aufgabenverteilung, die Anpassung bestehender Betriebsprozesse und die Frage, ob Mitarbeitende zusätzlich geschult werden müssen. Für die Einbindung in Ihre IT prüfen Sie Schnittstellen, Netzanbindung, das Verwaltungsmodell für Administratoren und den Umgang mit Daten.
Klären Sie dabei, wer nach der Migration wofür zuständig ist. Bei Microsoft-Clouddiensten bleiben die Daten, die Endgeräte, die Benutzerkonten und die Zugriffsverwaltung immer in Ihrer Verantwortung, gleich welches Dienstmodell Sie nutzen (Microsoft Learn: Gemeinsame Verantwortung in der Cloud). Mehrfaktor-Anmeldung und getrennte Administratorkonten gehören deshalb vor den ersten Umzug, nicht danach.
Schritt 6: Testlauf, Umstellung und Notfallvorsorge
Das BSI empfiehlt, die Migration zunächst in einem Testlauf zu prüfen. Beginnen Sie mit einer Anwendung, deren Ausfall den Betrieb wenig stört. So sammeln Sie Erfahrung mit Werkzeugen, Abläufen und Kosten, bevor kritische Systeme folgen.
Vor der Umstellung sollten Notfallvorkehrungen vollständig und aktuell sein. Für jeden Cloud-Dienst gehört dazu ein Notfallkonzept mit Zuständigkeiten, Ansprechpersonen und Regeln zur Datensicherung. Prüfen Sie auch, ob Sie zusätzlich zu den Sicherungen des Anbieters eigene Datensicherungen brauchen. Mehr dazu lesen Sie im Ratgeber Backup als Managed Service.
Nach dem Wechsel in den Produktivbetrieb gleichen Sie ab, ob der Anbieter die vereinbarten Anforderungen erfüllt.
Schritt 7: Betrieb und Weiterentwicklung
Mit dem Umzug beginnt der laufende Betrieb. Nach OPS.2.2 sollten Dokumentationen und Richtlinien regelmäßig aktualisiert werden. Ebenso sollte regelmäßig kontrolliert werden, ob die vertraglich zugesagten Leistungen erbracht werden. Die Reaktion auf Systemausfälle sollte geplant und geübt werden.
Behalten Sie die Kosten im Blick. Bei Diensten, die nach Verbrauch abgerechnet werden, helfen Budgets, Warnschwellen und ein fester Termin, an dem ungenutzte Ressourcen abgeschaltet werden. Planen Sie auch den Ausstieg mit: Die Verträge sollten regeln, wie das Vertragsverhältnis geordnet beendet werden kann, ohne dass Ihr Geschäftsbetrieb leidet.
Cloud-Migration und NIS2
Das NIS-2-Umsetzungsgesetz gilt in Deutschland seit dem 6. Dezember 2025 (BSI: Fragen und Antworten zu NIS-2). Betroffene Einrichtungen müssen nach § 30 BSIG Maßnahmen zum Risikomanagement umsetzen. Dazu gehören unter anderem Backup-Management und Wiederherstellung nach einem Notfall sowie die Sicherheit der Lieferkette, einschließlich der Beziehungen zu Diensteanbietern. Ein Cloud-Anbieter wird damit Teil Ihrer Lieferkette. Ob Ihr Unternehmen betroffen ist und was daraus folgt, klären wir auf der Seite NIS2 und Risikomanagement.
Häufige Stolpersteine
- Alles auf einmal: Ein Umzug in Wellen, beginnend mit einer überschaubaren Anwendung, macht Fehler früh sichtbar.
- Unklare Zuständigkeiten: Ohne schriftlich festgelegte Rollen bleibt nach der Migration offen, wer Warnungen bearbeitet und Änderungen freigibt.
- Altlasten mitnehmen: Verwaiste Konten, zu weit gefasste Berechtigungen und alte Datenbestände sollten vor dem Umzug bereinigt werden.
- Nutzer vergessen: Neue Werkzeuge und Abläufe brauchen Schulung und frühe Information der Mitarbeitenden.
Cloud-Migration mit der GSL Groß GmbH
Die GSL Groß GmbH betreut kleine und mittelständische Unternehmen in Rheinland-Pfalz und Hessen von Idar-Oberstein aus; im Raum Darmstadt arbeitet sie dafür mit einem Partnersystemhaus zusammen. Unser Angebot rund um Microsoft 365 und Azure finden Sie auf der Seite Cloud-Lösungen. Den laufenden Betrieb Ihrer IT zum monatlichen Festpreis beschreibt die Seite Managed Services – IT zum Festpreis.
Sie möchten Ihren Fahrplan in die Cloud gemeinsam aufstellen und die ersten Schritte festlegen? Sprechen Sie uns an.