Cloud-Migration: So bereiten Sie Ihre Unternehmensinfrastruktur vor

Cloud-Migration sollte nicht mit der Serverauswahl beginnen, sondern mit der Prüfung geschäftlicher Abhängigkeiten. Solange das Team nicht weiß, welche Systeme Bestellungen annehmen, wo Daten liegen und wer nach einem Ausfall den Betrieb wiederherstellt, verlagert der Umzug nur das Risiko. Das praktische Ergebnis der Vorbereitung sind eine abgestimmte Systemübersicht, Bereitschaftskriterien, ein Umschaltplan und ein nachvollziehbares Betriebsbudget.

Für Betreiber eines Online-Shops, B2B-Portals oder unternehmensinternen Websystems lautet die wichtigste Frage: Kann das Unternehmen seine Vorgänge während und nach der Umstellung abwickeln? Eine erreichbare Startseite beweist noch nicht, dass Zahlungen bestätigt, Bestände aktualisiert und Dokumente an das ERP übermittelt werden. Genau diese Abläufe müssen vor dem Start geprüft werden.

Im Folgenden geht es um die Vorbereitung einer Infrastrukturmigration von eigener Hardware, gemieteten Servern oder einer anderen Cloud-Umgebung. Dies ist keine Anleitung zum CMS-Wechsel oder zur Migration von SEO-Adressen. Die Anwendung kann auf derselben Plattform bleiben, während sich Netzwerk, Speicher, Datenbank, Zugriffsrechte und Betreuung erheblich ändern.

1. Halten Sie Anlass und Projektgrenzen fest

Beschreiben Sie das Problem, das die Migration lösen soll: schwierige Wiederherstellung, fehlende Leistung in Spitzenzeiten, auslaufende Hardwareunterstützung oder umständliche Umgebungsverwaltung. „In der Cloud sein“ ist kein überprüfbares Ergebnis. Dagegen lässt sich zeigen, ob die Bestellverarbeitung innerhalb einer vereinbarten Zeit wiederhergestellt oder eine Testumgebung nach einem dokumentierten Verfahren bereitgestellt werden kann.

Erfassen Sie den Ausgangszustand: normale und maximale Last, Antwortzeiten kritischer Vorgänge, Fehlerhäufigkeit, Datenmenge und tatsächliche Kosten. Wählen Sie einen repräsentativen Zeitraum, der Ihre Arbeitszyklen abdeckt. Wird der Shop von Aktionen geprägt, reichen Beobachtungen an ruhigen Tagen für die Ressourcenplanung nicht aus.

Legen Sie gesondert fest, was nicht zur ersten Welle gehört: Redesign, CRM-Austausch, Katalogumbau oder eine vollständige Neuentwicklung der Anwendung. Die Kombination aller Änderungen erschwert die Suche nach Fehlerursachen. Für ältere Komponenten ist der Ansatz der GOV.UK-Leitlinien zum Umgang mit Legacy-Technologie hilfreich: Bewerten Sie Risiken und Fähigkeiten des Systems, statt es allein wegen seines Alters für ungeeignet zu erklären.

2. Erfassen Sie Abhängigkeiten entlang der Geschäftsabläufe

Die Bestandsaufnahme muss mehr als Server umfassen. Erfassen Sie Anwendungen, Datenbanken, Dateiablagen, Nachrichtenwarteschlangen, Suche, Cache, Aufgabenplaner sowie Zahlungs- und Logistikintegrationen. Für jede Komponente werden Verantwortliche, Zweck, Umgebung, Version, Konfigurationsquelle und Wiederherstellungsverfahren benötigt. Unklare Zuständigkeit ist ein konkretes Termin- und Betriebsrisiko.

Prüfen Sie Verbindungen in beide Richtungen

In einem beispielhaften Online-Shop erstellt ein Kunde eine Bestellung, der Zahlungsdienst sendet eine Bestätigung, das CRM nimmt die Anfrage entgegen, das ERP reserviert die Ware und der Versanddienst liefert eine Sendungsnummer zurück. Dies ist ein Lernbeispiel, keine GL.ua-Fallstudie. Dokumentieren Sie für jede Verbindung Adresse, Protokoll, Autorisierung, zulässige Verzögerung, Wiederholungsversuche und Verhalten bei Nichterreichbarkeit des benachbarten Systems.

Prüfen Sie auch Rückrufe: Ein externer Dienst greift möglicherweise auf eine alte IP-Adresse zu oder erlaubt Anfragen nur aus dem bisherigen Netzwerk. Der Datenaustausch am Tag zeigt keinen monatlichen Export oder nächtlichen Abgleich. Gleichen Sie Gespräche mit Prozessverantwortlichen mit Konfiguration, Protokollen und Netzwerkbeobachtungen ab. Eine automatisierte Inventarisierung hilft, erklärt aber nicht allein die geschäftliche Bedeutung einer Verbindung.

Gruppieren Sie Systeme nach gemeinsamem Risiko

Greift eine Anwendung häufig auf die Datenbank zu, kann ihre Verteilung auf verschiedene Umgebungen Latenz und Übertragungskosten verändern. Nutzen mehrere Dienste gemeinsame Dateien, muss beim separaten Umzug eines Dienstes die Datenkonsistenz geprüft werden. In den Google-Cloud-Empfehlungen zur Bewertung von Workloads gehören Bestandsaufnahme und Ermittlung von Abhängigkeiten zur Migrationsvorbereitung. Die praktische Konsequenz: Planen Sie Wellen anhand der Verbindungen, nicht nach der Reihenfolge der Server in einer Liste.

3. Machen Sie Readiness zu Freigabekriterien

Readiness bedeutet eine durch Nachweise bestätigte Bereitschaft zum Umzug. Geben Sie sich nicht mit „fast fertig“ zufrieden. Bestimmen Sie für jede Welle, was geprüft wurde, wer das Ergebnis abnimmt und welches ungelöste Problem die Umstellung stoppt. Die Kriterien müssen Technik, Daten, Sicherheit, Finanzen und Bereitschaftsteam abdecken.

Diese Tabelle ist eine Arbeitsvorlage, kein allgemeiner Zertifizierungsstandard. Ergänzen Sie Ihre eigenen Einschränkungen. Ein Periodenabschluss oder eine Verkaufsaktion kann beispielsweise auch für eine technisch bereite Welle ungeeignet sein. Die verantwortliche Person für den Geschäftsprozess muss das Änderungsfenster und die Arbeitsweise bei vorübergehend eingeschränkten Funktionen abstimmen.

Die Entscheidungen können je Komponente unterschiedlich ausfallen: weitgehend unverändert umziehen, an einen verwalteten Dienst anpassen, einen Teil neu aufbauen, am bisherigen Ort belassen oder außer Betrieb nehmen. Bauen Sie nicht automatisch alles für eine neue Architektur um. Ein Pilot soll echte Unsicherheiten prüfen, ohne den gesamten Verkaufsfluss zu gefährden.

4. Bereiten Sie eine sichere Zielumgebung vor

Legen Sie vor dem Umzug produktiver Daten die Struktur von Konten, Netzwerken, Umgebungen und Zugriffen fest. Trennen Sie Tests vom Produktivsystem. Dokumentieren Sie, welche Komponenten tatsächlich öffentlich erreichbar sein müssen und welche nur innerhalb des vereinbarten Bereichs kommunizieren sollen. Entscheidungen über konkrete Einstellungen muss die zuständige Sicherheitsfachkraft prüfen.

Erstellen Sie eine Liste der Dienstkonten und Geheimnisse: Passwörter, Schlüssel und Integrationstoken. Legen Sie Verantwortliche sowie Verfahren für Speicherung, Erneuerung und Widerruf fest. Ungeprüftes Kopieren alter Serverkonfigurationen kann überflüssige Rechte und längst vergessene Zugänge übernehmen. Prüfen Sie den Notfallzugang gesondert: Er muss den zuständigen Personen zur Verfügung stehen, darf aber nicht zum gemeinsamen Alltagskonto werden.

Klären Sie, wer im gewählten Servicemodell Betriebssystem, Anwendung und Datenbank aktualisiert, Sicherungen erstellt und auf Vorfälle reagiert. Ein Cloud-Anbieter übernimmt nicht automatisch alle Pflichten des Kunden. NIST SP 800-144 behandelt Sicherheit und Datenschutz in öffentlichen Clouds; es ist ein Grundlagendokument, kein Nachweis, dass ein konkretes Projekt heutige Anforderungen erfüllt.

Prüfen Sie bei Kundendaten die Speicherorte der Hauptkopien, Sicherungen und Protokolle, die Vertragsbedingungen und den Zugriff von Auftragnehmern. Ziehen Sie keine rechtlichen Schlüsse allein aus dem Namen einer Anbieterregion. Einschränkungen für personenbezogene oder regulierte Daten sollten vor der Dienstauswahl mit kompetenten Fachleuten abgestimmt werden. Prüfen Sie anschließend, ob Protokolle tatsächlich am vorgesehenen Ort ankommen und keine Geheimnisse offenlegen.

5. Berechnen Sie Gesamtkosten statt nur virtueller Maschinen

Ein Vergleich der bisherigen Serverrechnung mit dem Preis einer einzelnen Cloud-Maschine reicht nicht. Das Kostenmodell muss Rechenleistung, Datenbanken und Speicher, Redundanz, Datenübertragung, Netzwerkkomponenten, Protokolle, Monitoring, Lizenzen und Support enthalten. Ergänzen Sie Testumgebungen, vorübergehende Replikation und den Zeitraum, in dem alte und neue Infrastruktur gleichzeitig bezahlt werden.

Einmalige Arbeiten sind Bestandsprüfung, Planung, Einrichtung der Umgebung, Datenübertragung, Integrationsanpassung, Tests, Probe, Umschaltung und Dokumentation. Laufende Kosten entstehen durch Ressourcen und die Teamarbeit nach dem Start. Führen Sie Unsicherheiten gesondert auf: unvollständige Bestände, unklare Lizenzbedingungen oder nötige Komponentenumbauten. Das ist ehrlicher als ein genauer Kostenvoranschlag ohne geprüfte Ausgangsdaten.

Vergleichen Sie gleichwertige Lastszenarien

Erstellen Sie Modelle für Normalbetrieb, Spitzenzeiten und Wiederherstellung nach Ausfällen. Berücksichtigen Sie Datenwachstum und Aufbewahrungsdauer der Sicherungen. Vergleichen Sie Systeme mit ähnlichen Anforderungen an Verfügbarkeit und Betreuung: Eine billigere Umgebung ohne Redundanz ist kein gleichwertiger Ersatz für eine Umgebung mit geprüfter Wiederherstellung.

Weisen Sie zur Kostensteuerung jeder Ressource Verantwortliche zu, verwenden Sie verständliche Projektkennzeichnungen und vereinbaren Sie Budgetalarme sowie regelmäßige Rechnungsprüfungen. Verstehen Sie einen Alarm nicht als automatische Ausgabengrenze: Das Verhalten der Budgetwerkzeuge muss für den gewählten Dienst geprüft werden. Vergleichen Sie nach der Migration Prognose und tatsächlichen Verbrauch und suchen Sie nach Abweichungsursachen, statt nur das Budget zu erhöhen.

6. Proben Sie den vollständigen Geschäftsablauf

Die Wellenplanung im Microsoft Cloud Adoption Framework hilft, Workload-Bewertung und Umzugsreihenfolge zu verbinden. Für das Unternehmen müssen verständliche Abnahmenachweise hinzukommen. Ein Pilot ist nicht abgeschlossen, wenn der Server läuft, aber niemand das Ergebnis des Vorgangs im benachbarten System geprüft hat.

1. Stellen Sie eine Datenkopie in der vorbereiteten Umgebung wieder her und prüfen Sie ihre Vollständigkeit mit dem vereinbarten Verfahren.
2. Durchlaufen Sie den kritischen Weg: Anmeldung, Suche, Warenkorb, Bestellung, Testzahlung und Übergabe an CRM oder ERP.
3. Prüfen Sie Hintergrundaufgaben, wiederholte Nachrichten, Fehlerbehandlung und Verbindungswiederaufnahme nach einer Unterbrechung.
4. Bilden Sie repräsentative Last nach und vergleichen Sie Verzögerungen und Fehler mit den Ausgangsmessungen.
5. Prüfen Sie Alarme, Wiederherstellung aus Sicherungen und die Anleitung für den Bereitschaftsdienst.
6. Proben Sie die Umschaltung und dokumentieren Sie Schrittdauer und Abbruchbedingungen.

Die Testumgebung darf nicht versehentlich echtes Geld abbuchen, Kunden benachrichtigen oder tatsächliche Sendungen anlegen. Stimmen Sie Testmodi der Integrationen und den Umgang mit personenbezogenen Daten vorher ab. Zur Ergebnisbestätigung reicht das technische Team nicht aus: Verantwortliche für Vertrieb, Lager und Buchhaltung müssen ihre Prozessabschnitte prüfen.

Ändert sich beim Umzug auch die Webanwendung, trennen Sie Infrastrukturkriterien und funktionale Abnahme. Für den Webteil kann die Entwicklung von Online-Shops und Unternehmenswebsites durch GL.ua als Orientierung dienen; die CMS-Auswahl allein löst jedoch keine Fragen zu Netzwerk, Redundanz oder Betrieb.

7. Stimmen Sie Umschaltung, Rückkehr und realistische Termine ab

Der Umschaltplan muss Schrittfolge, Ausführende, Kommunikation und die Person enthalten, die über Fortsetzung oder Abbruch entscheidet. Beschreiben Sie, wann Schreibvorgänge im alten System enden, wie die letzte Datenänderung übertragen wird und wann das neue System führend wird. Berücksichtigen Sie Adress-Caching und externe IP-Freigabelisten gesondert.

Rückkehr nach neuen Schreibvorgängen braucht eine eigene Entscheidung

Eine Netzwerkroute zurückzusetzen ist einfacher, als zwei Datenbanken mit inzwischen unterschiedlichen Bestellungen abzugleichen. Der Rollback-Plan muss deshalb den Umgang mit neuen Daten erklären: wie sie erhalten, abgeglichen und ohne doppelte Verarbeitung übertragen werden. Replikation und Sicherung ersetzen diese Entscheidung nicht automatisch. Ist eine sichere Rückkehr nach einem bestimmten Schritt unmöglich, kennzeichnen Sie diese Grenze und den Plan für die Wiederherstellung im neuen System ausdrücklich.

Vereinbaren Sie vor dem Start die zulässige Wiederherstellungszeit und den zulässigen Datenverlust — RTO beziehungsweise RPO. Maßgeblich sind geschäftliche Anforderungen, nicht ein Standardwert aus einer Präsentation. Prüfen Sie bei der Probe, ob Architektur und Verfahren diese Anforderungen erfüllen können. Eine dokumentierte Kennzahl ohne Test bleibt ein Ziel, keine nachgewiesene Fähigkeit.

Termine hängen von Datenmenge und Änderungsrate, Leitungskapazität, Anzahl der Abhängigkeiten, Komponentenkompatibilität, Zugriffsfreigaben und Verfügbarkeit der Beteiligten ab. Für Probe, Abnahme und Stabilisierung sind eigene Zeitfenster nötig. Versprechen Sie keinen Abschlusstermin allein anhand der Serverzahl: Eine komplexe Integration kann den gesamten kritischen Pfad bestimmen.

8. Schließen Sie die Migration mit der Betriebsübergabe ab

Prüfen Sie nach der Umschaltung nicht nur den Infrastrukturzustand, sondern abgeschlossene Geschäftsvorgänge: Kommen Bestellungen an, wachsen Warteschlangen, stimmen Bestände und werden Zahlungen oder Nachrichten doppelt verarbeitet? Legen Sie Zuständigkeiten und Abschlusskriterien für die Stabilisierung fest. Schalten Sie die alte Umgebung erst nach abgestimmter Prüfung von Daten, Sicherungen und Rückkehrbedarf ab.

Übergeben Sie dem Team eine aktuelle Systemübersicht, rollenbasierte Zugänge, Bereitstellungs- und Wiederherstellungsverfahren, Supportkontakte und einen Plan regelmäßiger Prüfungen. Entfernen Sie unnötige temporäre Zugänge, prüfen Sie verbleibende Ressourcen und Abschlussrechnungen. Andernfalls kann ein technisch abgeschlossener Umzug zwei kostenpflichtige Umgebungen und eine Konfiguration hinterlassen, die niemand betreuen kann.

Treffen Sie die Bereitschaftsentscheidung anhand von Nachweisen: Abhängigkeiten sind bekannt, Daten lassen sich wiederherstellen, kritische Abläufe funktionieren, Sicherheit ist geprüft, Kosten sind nachvollziehbar und das Team weiß, wie es bei Störungen handeln muss. Fehlt ein Nachweis, passen Sie lieber die Welle an, statt Unsicherheit mit einem Starttermin zu verdecken.

Planen Sie den Infrastrukturumzug eines Online-Shops oder Unternehmensportals? Besprechen Sie den Webteil des Projekts und seine Integrationen mit GL.ua: Beginnen Sie mit einer Liste der Systeme, kritischen Vorgänge und Wiederherstellungsanforderungen. Dieses Briefing hilft, Anwendungsarbeiten von Infrastrukturaufgaben zu trennen und Zuständigkeiten vor Beginn der Änderungen festzulegen.