Ein Vertragsbeginn ist noch keine Betriebsübernahme
Der Termin steht, die neue Infrastruktur ist bereit und beide Dienstleister haben ihre Projektpläne abgestimmt. Trotzdem kann der Wechsel stocken, wenn ein administrativer Zugang fehlt, ein nächtlicher Datenlauf unbekannt ist oder niemand über den Abbruch einer Migration entscheiden darf. Der Übergang muss deshalb sowohl technische Zustände als auch Wissen und Verantwortung übertragen.
Die folgenden fünf Risikofelder bieten eine praktische Struktur für die Vorbereitung. Ihr Gewicht hängt von Anwendung, Datenumfang und Betriebsmodell ab. Ausgangspunkt ist ein gemeinsames Verzeichnis der Leistungen und Abhängigkeiten, ergänzt um überprüfbare Übergabeergebnisse. Ein erledigter Termin im Projektplan genügt als Nachweis nicht.
Der BSI-Baustein OPS.2.3 „Nutzung von Outsourcing“, Edition 2023 (PDF) behandelt auch die geplante und ungeplante Beendigung von Outsourcing-Verhältnissen. Die nachstehenden Umsetzungsvorschläge beziehen diesen Lebenszyklusgedanken auf die praktische Übergabe.
Risiko 1: Dokumentation ist vorhanden, aber nicht nutzbar
Eine Sammlung von Präsentationen, Tickets und Installationsnotizen beschreibt selten zuverlässig den aktuellen Betrieb. Kritische Informationen können ausschließlich bei einzelnen Personen liegen: die Reihenfolge eines Neustarts, ein Sonderfall im Monatsabschluss oder die Bedeutung einer Warnmeldung.
Erstellen Sie ein verbindliches Übergabeverzeichnis mit Anwendungen, Versionen, Schnittstellen, Betriebsaufgaben und bekannten Einschränkungen. Ordnen Sie jedem Bestandteil eine verantwortliche Person sowie ein Prüfkriterium zu. Ungeklärte Lücken bleiben als Risiken sichtbar und erhalten einen Bearbeitungstermin.
Nachweis: Das übernehmende Team führt einen typischen Betriebsablauf selbst aus. Das bisherige Team beobachtet und ergänzt fehlendes Wissen. Dieses umgekehrte Begleiten zeigt, ob die Unterlagen zur tatsächlichen Handlung befähigen.
Risiko 2: Die Daten sind kopiert, aber fachlich unvollständig
Eine technisch erfolgreiche Übertragung sagt noch nichts über Vollständigkeit und Nutzbarkeit aus. Anlagen, Verknüpfungen, Zeitstempel und Bearbeitungsstände können fehlen oder anders interpretiert werden. Während einer längeren Migration verändern sich unter Umständen weiterhin Daten im Ausgangssystem.
Planen Sie daher Probeläufe mit repräsentativem Datenvolumen und einem fachlichen Abgleich. Definieren Sie, wie Änderungen während der Übertragung übernommen werden und ab wann das alte System keine Schreibzugriffe mehr annimmt. Falls Parallelbetrieb erforderlich ist, muss die Führung der Daten eindeutig geregelt sein.
Nachweis: Der Abgleich kombiniert technische Mengen- oder Integritätsprüfungen mit fachlichen Stichproben und vollständigen Tests kritischer Vorgänge. Fehlerlisten werden zugeordnet und vor dem Wechsel entsprechend ihrer Bedeutung abgearbeitet.
Risiko 3: Zuständigkeiten wechseln nur auf dem Papier
Unklare Grenzen zwischen Infrastruktur, Anwendung und Fachverfahren erschweren die Störungsbearbeitung. Besonders kritisch ist die Übergangsphase, in der beide Anbieter noch Aufgaben ausführen, aber jeweils vom anderen eine Reaktion erwarten.
Beschreiben Sie deshalb für jeden Betriebszustand, wer meldet, analysiert, entscheidet, kommuniziert und Änderungen ausführt. Legen Sie den Zeitpunkt der Verantwortungsübernahme fest und benennen Sie eine übergreifende Koordination. Der Fachbereich benötigt einen verständlichen Meldeweg, auch wenn die technische Ursache noch unklar ist.
Nachweis: Eine gemeinsame Störungsübung prüft Kontaktwege, Vertretungen und Entscheidungsbefugnisse. Die Übung sollte eine Abhängigkeit außerhalb des neuen Providers einbeziehen, damit auch die Zusammenarbeit über dessen Leistungsgrenze hinaus sichtbar wird.
Risiko 4: Zugriffe, Zertifikate und Betriebswerkzeuge fehlen
Eine Anwendung kann im Test funktionieren und trotzdem nach dem Wechsel ausfallen, wenn Zertifikate ablaufen, technische Konten an den alten Provider gebunden sind oder die Überwachung keine produktiven Signale erhält. Diese Abhängigkeiten werden bei einer rein anwendungsbezogenen Planung leicht übersehen.
Erfassen Sie administrative und technische Konten, Namensauflösung, Netzfreigaben, Zertifikate, Lizenzen, Überwachung und Sicherungswege. Prüfen Sie für jeden Bestandteil, ob eine Übertragung möglich ist oder ein Ersatz eingerichtet werden muss. Geheimnisse werden über geschützte Verfahren übergeben und anschließend entsprechend dem Zugriffskonzept erneuert.
Nachweis: Das neue Team kann aus der vorgesehenen Betriebsumgebung auf die benötigten Komponenten zugreifen, Alarme empfangen und eine Sicherung wiederherstellen. Nach dem geregelten Abschluss werden nicht mehr benötigte Zugriffe des bisherigen Providers entzogen und dokumentiert.
Risiko 5: Es gibt keinen belastbaren Rückfall- und Stabilisierungsplan
„Bei Problemen gehen wir zurück“ ist erst dann ein Plan, wenn Zeitgrenzen, Auslöser und Datenfolgen geklärt sind. Sobald im neuen System produktive Änderungen entstehen, kann ein Rückwechsel diese Informationen verlieren oder widersprüchliche Bestände erzeugen.
Legen Sie vorab fest, wer anhand welcher Kriterien den Wechsel freigibt oder abbricht. Definieren Sie den letzten Zeitpunkt eines einfachen Rückwechsels und das Vorgehen danach. Je nach Datenmodell kann eine gezielte Korrektur im neuen System sicherer sein als die Rückkehr zum alten Stand.
Nachweis: Der Ablauf wird vor dem Produktivtermin geprobt. Nach der Umschaltung folgt eine vereinbarte Stabilisierungsphase mit erhöhter Aufmerksamkeit, klaren Kontaktwegen und einem Abschluss anhand von Betriebsdaten. Der alte Betrieb endet erst nach erfüllten Abschlusskriterien.
Die Freigabe an konkrete Ergebnisse binden
Ein illustrativer Sonderfall zeigt die Bedeutung fachlicher Prüfungen: Ein Portal funktioniert nach der Umschaltung, aber ein wöchentliches Abrechnungsverfahren wurde noch nie unter dem neuen Betreiber ausgeführt. Die Freigabe allein auf Basis eines kurzen Funktionstests würde diesen Teil des Services übersehen.
- Leistungsumfang: Regelmäßige und seltene Betriebsaufgaben sind vollständig zugeordnet.
- Übernahme: Dokumentation, Wissen und notwendige Zugriffe sind praktisch geprüft.
- Daten: Kritische Vorgänge bestehen den fachlichen Abgleich einschließlich Anlagen und Historien.
- Entscheidung: Wechsel, Abbruch und Behandlung neuer Daten haben benannte Verantwortliche.
- Abschluss: Restpunkte, Altzugänge, Datenbestände und Stilllegung werden kontrolliert abgearbeitet.
Ein Providerwechsel ist abgeschlossen, wenn die vereinbarte Leistung unter der neuen Verantwortung verlässlich erbracht wird. Dieser Nachweis verbindet technische Tests mit dem Wissen der Fachbereiche und verhindert, dass ungelöste Projektaufgaben unbemerkt in den Regelbetrieb wandern.