Hosting-Migration im Unternehmen: Cutover und Rückfall planen

Kurzantwort: Wie plant man eine Hosting-Migration?

Eine Hosting-Migration wird als kontrollierte Änderung an einem vollständigen Anwendungssystem geplant. Zuerst werden Anwendung, Daten, Abhängigkeiten, Zugänge und Betriebsziele inventarisiert. Danach entsteht die Zielumgebung, eine Probemigration wird mit technischen und fachlichen Prüffällen abgenommen, und der produktive Wechsel erhält ein definiertes Änderungsfenster, einen Datenabgleich, klare Freigabekriterien und einen ausführbaren Rückfallweg.

Der Umschalttag ist nur ein Teil des Vorhabens. Vorbereitung, Test, Kommunikation, Überwachung nach dem Cutover und geregelte Stilllegung entscheiden darüber, ob die neue Umgebung tatsächlich übernommen werden kann. Das BSI verlangt für Änderungen eine geeignete Planung, Genehmigung, Dokumentation, Tests und Rückfall-Lösungen. Diese Grundsätze lassen sich unmittelbar auf eine Hosting-Migration übertragen.

Hosting-Migration, Betriebsmodell und Anbieterwechsel trennen

Eine Hosting-Migration beantwortet die operative Frage, wie eine konkrete Anwendung von einer Ausgangs- in eine Zielumgebung wechselt. Die Entscheidung zwischen Eigenbetrieb und Managed Hosting klärt dagegen, wer Infrastruktur, Betriebssystem, Datenbank, Anwendung, Monitoring und Wiederherstellung verantwortet. Ein Cloud-Anbieterwechsel kann zusätzlich vertragliche Export-, Übergangs- und Löschfragen auslösen. Diese Entscheidungen hängen zusammen, sind aber nicht dasselbe Projektartefakt.

Der Migrationsplan setzt deshalb ein beschlossenes Zielbild voraus. Ist noch offen, welche Komponenten DAG, ein Infrastrukturbetreiber, ein Softwarehersteller oder das eigene Team betreuen, lässt sich weder ein belastbarer Cutover noch eine spätere Abnahme planen. Verantwortungsgrenzen werden vor technischen Schritten festgehalten, nicht erst bei der ersten Störung.

Die Anwendung als Abhängigkeitskarte inventarisieren

Die Bestandsaufnahme beginnt beim fachlichen Ergebnis: Welche Nutzer und Prozesse benötigen die Anwendung, wann ist sie kritisch und welche Unterbrechung ist vertretbar? Von dort wird rückwärts auf Web- und Anwendungsdienste, Datenbanken, Dateispeicher, Hintergrundjobs, Identitäten, Netzwege und externe Integrationen abgebildet. Unbekannte Verbindungen werden als offene Punkte geführt; sie dürfen nicht stillschweigend aus dem Umfang fallen.

Zu jeder Komponente gehören Version, Konfiguration, Verantwortlicher, Zugang, Lizenz- oder Supportgrenze, Datenklasse, Sicherung und Wiederanlaufreihenfolge. Auch unscheinbare Abhängigkeiten wie ausgehende E-Mail, DNS, Zertifikatserneuerung, Zeitsynchronisation, geplante Jobs, Webhooks oder feste IP-Freigaben können den Wechsel blockieren. Ein Portscan oder eine Serverliste ersetzt diese fachliche Abbildung nicht.

• Anwendung, Laufzeit, Datenbank, Dateispeicher und Suchindex
• Nutzer, Rollen, Verzeichnisdienst, technische Konten und Dienstschlüssel
• DNS-Namen, Zertifikate, Firewallregeln, ausgehende Verbindungen und feste Freigaben
• APIs, Webhooks, Dateiaustausch, Zeitpläne, Warteschlangen und externe Dienste
• Backups, Protokolle, Monitoring, Alarmwege und Betriebsdokumentation
• fachliche Spitzenzeiten, Abschlussläufe, Aufbewahrung und zulässige Unterbrechung

Die Zielumgebung gegen messbare Übernahmekriterien bauen

Die Zielumgebung wird nicht nur nach CPU, Arbeitsspeicher und Speicherplatz beschrieben. Betriebssystem- und Laufzeitversionen, Netzwerkzonen, Verschlüsselung, Zugriff, Protokollierung, Sicherung, Monitoring und Zuständigkeiten müssen zur Anwendung passen. Abweichungen zur Ausgangsumgebung werden bewusst entschieden und getestet; eine Migration ist kein geeigneter Moment für ungeplante gleichzeitige Modernisierungen.

Für jede Schicht wird festgelegt, wer bereitstellt, prüft, freigibt und nach der Übergabe betreibt. Die Abnahme verwendet beobachtbare Kriterien: Die Anwendung startet, definierte Nutzer können sich anmelden, notwendige Daten sind vollständig, Integrationen erzeugen den erwarteten fachlichen Zustand, Sicherung und Monitoring melden korrekt. Allgemeine Aussagen wie ‚Server erreichbar‘ reichen für eine Betriebsübernahme nicht aus.

Vor dem Cutover einen wiederherstellbaren Ausgangsstand sichern

Eine laufende Replikation oder Kopie schützt nicht automatisch vor einem fachlich falschen Datenstand. Vor der produktiven Umschaltung wird festgelegt, welche Daten und Konfigurationen zusammen einen konsistenten Ausgangspunkt bilden und wie dieser wiederhergestellt wird. Das BSI ordnet Datensicherung und Restore gemeinsam ein und weist darauf hin, dass ein Backup ohne erprobte Wiederherstellung keinen ausreichenden Nachweis liefert.

Der Sicherungspunkt umfasst je nach Anwendung Datenbank, Dateien, Konfiguration, Automationsdefinitionen und die Information, welche Softwareversion dazu passt. Geheimnisse werden nicht unkontrolliert in allgemeine Exportpakete kopiert. Sie erhalten einen getrennten, geschützten Wiederanlaufweg. Ein bereits durchgeführter Restore-Test reduziert Unsicherheit; er ersetzt trotzdem nicht die Prüfung des konkreten Migrationsstands.

Eine Probemigration mit denselben Übergängen wie produktiv durchführen

Die Probemigration soll nicht nur zeigen, dass Daten importiert werden können. Sie durchläuft Extraktion, Übertragung, Transformation, Startreihenfolge, Identitätsanbindung, Schnittstellen und fachliche Prüffälle möglichst so, wie sie später im Produktivwechsel vorgesehen sind. Jeder manuelle Schritt wird dabei sichtbar; improvisierte Korrekturen werden entweder als wiederholbare Regel dokumentiert oder vor dem Cutover beseitigt.

Technische Prüfungen kontrollieren Vollständigkeit, Integrität, Versionen, Berechtigungen, Jobs und Fehlerprotokolle. Fachliche Prüfungen kontrollieren reale Ergebnisse: Kann ein Vorgang gefunden, bearbeitet und an das nächste System übergeben werden? Stimmen Status, Anhänge, Zeitbezug und Berechnung? Die Freigabe gehört den Rollen, die diese Wirkung beurteilen können, nicht allein dem Migrationsteam.

Delta-Übernahme und Schreibstopp auf den Prozess abstimmen

Zwischen Probemigration und Cutover verändert sich der produktive Bestand weiter. Der Plan muss deshalb erklären, wie neue und geänderte Daten in die Zielumgebung gelangen. Je nach Anwendung kann dies durch Replikation, wiederholbaren Delta-Export oder ein begrenztes Schreibstoppfenster erfolgen. Das Verfahren muss auch Löschungen, Beziehungen und fehlgeschlagene Übertragungen behandeln.

Kurz vor der Umschaltung werden Hintergrundjobs, externe Schreibwege und Benutzeraktionen in eine definierte Reihenfolge gebracht. Wo ein Schreibstopp nötig ist, werden Beginn, betroffene Nutzer, erlaubte Ausnahmen und Ende kommuniziert. Wo Parallelbetrieb vorgesehen ist, muss eine eindeutige Schreibhoheit verhindern, dass zwei Umgebungen auseinanderlaufende Wahrheiten erzeugen.

DNS, Zertifikate, Geheimnisse und Integrationen einzeln umschalten

Die sichtbare URL ist nur ein Übergang. Zertifikate und ihre Erneuerung, Absender für E-Mail, Callback-Adressen, Webhooks, technische Konten, Firewallregeln und feste IP-Listen müssen auf das Ziel vorbereitet sein. Neue Geheimnisse werden im Ziel kontrolliert hinterlegt; nicht mehr benötigte Schlüssel der Ausgangsumgebung werden erst nach stabiler Übernahme widerrufen.

Zeitpläne, Warteschlangen und ausgehende Integrationen benötigen besondere Aufmerksamkeit. Werden sie in beiden Umgebungen gleichzeitig aktiv, können doppelte E-Mails, Exporte oder Buchungen entstehen. Der Cutover-Plan benennt deshalb für jede aktive Verbindung einen Eigentümer, den genauen Umschaltpunkt, eine Funktionsprüfung und den Rückfallzustand.

Den Cutover über ein eindeutiges Entscheidungsfenster steuern

Vor dem Start bestätigen Technik, Fachverantwortung und Betrieb, dass Zielumgebung, Sicherung, Migrationslauf, Kommunikationsweg und Rückfall vorbereitet sind. Während des Fensters führt ein gemeinsames Protokoll durch die Schritte. Jede Freigabe bezieht sich auf einen beobachteten Zustand; Zeitdruck darf eine fehlgeschlagene Pflichtprüfung nicht in einen Erfolg umdeuten.

Die Umschaltung wird erst abgeschlossen, wenn vorher definierte Kernprüfungen bestanden sind. Dazu gehören Erreichbarkeit, Anmeldung, lesender und schreibender Kernprozess, Datenstand, wichtigste Integrationen, Monitoring und Sicherung. Fehler erhalten eine klare Entscheidung: innerhalb des Fensters beheben, betroffene Funktion begrenzen oder Rückfall auslösen.

• Startfreigabe: Verantwortliche, Sicherung und Zielzustand bestätigt
• Datenphase: letzter Export oder Delta vollständig und nachvollziehbar verarbeitet
• Umschaltung: DNS, Routing, Identität und aktive Integrationen kontrolliert geändert
• Kernprüfung: technische und fachliche Mindestfälle bestanden
• Entscheidung: Übernahme, begrenzter Weiterbetrieb oder Rückfall dokumentiert
• Kommunikation: Nutzer, Support und beteiligte Dienstleister erhalten den tatsächlichen Status

Rückfall mit Datenstand und Entscheidungskriterien ausführbar machen

Ein Rückfall ist mehr als das Einschalten des alten Servers. Sobald das Ziel Schreibvorgänge angenommen hat, muss geklärt sein, ob und wie diese Änderungen zurückgeführt werden können. Deshalb definiert der Plan ein Rückfallfenster, konkrete Auslöser, die entscheidungsbefugte Rolle und den letzten konsistenten Datenstand. Manche Fehler lassen sich innerhalb des Fensters beheben; andere gefährden Datenintegrität oder Kernprozesse und erfordern die Rückkehr.

NIST SP 800-34 beschreibt Notfallplanung als Verbindung von Priorisierung, Wiederherstellungsstrategie, dokumentiertem Plan, Tests und Pflege. Für die Migration bedeutet das: Rückfallwege werden vor dem Ereignis geprobt und mit den zuständigen Personen durchgesprochen. Ist ein verlustfreier Rückfall nach neuen Schreibvorgängen technisch nicht möglich, muss diese Grenze vor dem Cutover bekannt und bei der Freigabe berücksichtigt sein.

Beispielprozess: Eine interne Auftragsanwendung in neues Hosting überführen

Ein Anwendungsszenario: Eine interne Auftragsanwendung nutzt eine Datenbank, legt erzeugte Dokumente im DMS ab, sendet Status an das ERP und verschickt E-Mails. Die Bestandsaufnahme zeigt zusätzlich einen nächtlichen Import und eine feste IP-Freigabe beim ERP. Beides wäre bei einem reinen Serverumzug leicht übersehen worden.

Das Team baut die Zielumgebung, stellt eine pseudonymisierte Testkopie wieder her und prüft Anmeldung, Auftragssuche, Dokumentablage, ERP-Übergabe und E-Mail zunächst ohne reale Außenwirkung. Nach der Probemigration werden Export und Validierung wiederholbar dokumentiert. Für den Cutover wird die alte Anwendung auf lesend gesetzt, das Delta übertragen, die feste IP-Freigabe umgestellt und erst danach der schreibende Betrieb im Ziel freigegeben.

Während des Rückfallfensters bleiben Ausgangsumgebung und Sicherung unverändert verfügbar. Monitoring beobachtet Kernfunktion, Fehlerrate, Warteschlangen und Integrationen. Nach fachlicher Abnahme übernimmt der vereinbarte Betrieb die Umgebung; alte technische Konten und Zugänge werden kontrolliert widerrufen, und die Ausgangsumgebung wird nach geklärter Aufbewahrung stillgelegt.

Nach der Umschaltung stabilisieren, übergeben und stilllegen

Nach dem Cutover folgt eine befristete Stabilisierungsphase mit erhöhter Beobachtung. Offene Abweichungen werden nach Wirkung priorisiert, nicht als ungeordnete Restliste übergeben. Der Betrieb erhält aktuelle Architektur, Zugänge, Sicherungs- und Wiederherstellungsweg, Monitoring, Runbooks, Anbietergrenzen und Ansprechpartner. Erst wenn diese Übergabe angenommen ist, gilt die Migration als betriebsbereit abgeschlossen.

Die Ausgangsumgebung wird nicht dauerhaft als unkontrollierte Schatteninstallation behalten. Nach Ende des Rückfallfensters werden Jobs deaktiviert, Zugänge und Geheimnisse widerrufen, DNS- und Firewallreste entfernt und Daten nach den festgelegten Aufbewahrungs- und Löschentscheidungen behandelt. Benötigte Nachweise bleiben erhalten; produktive Doppelwege enden.

Hosting-Migration in acht Schritten vorbereiten

Beginnen Sie mit einer begrenzten, geschäftlich verstandenen Anwendung. Der Plan wird belastbar, wenn jede technische Aktivität an eine Entscheidung, einen Prüffall und eine verantwortliche Rolle gebunden ist.

• 1. Fachliche Kritikalität, Unterbrechungsgrenze und Verantwortliche festlegen.
• 2. Anwendung, Daten, Identitäten, Netzwerk und Integrationen vollständig inventarisieren.
• 3. Zielarchitektur, Betriebsgrenzen und messbare Abnahmekriterien beschließen.
• 4. Wiederherstellbaren Ausgangsstand und Rückfallverfahren vorbereiten.
• 5. Probemigration einschließlich Systemübergängen und Fachtests durchführen.
• 6. Delta, Schreibhoheit, Kommunikationsweg und Cutover-Fenster festlegen.
• 7. Umschaltung protokolliert ausführen und Übernahme oder Rückfall entscheiden.
• 8. Stabilisierung, Betriebsübergabe und Stilllegung der Altumgebung abschließen.