Im ersten Teil dieser Beitragsreihe wurde der regulatorische und organisatorische Rahmen von Rechenzentrumsumzügen im Umfeld Kritischer Infrastrukturen betrachtet. Deutlich wurde, dass solche Vorhaben keine rein technischen Projekte sind, sondern langfristige Transformationsprozesse, die unter regulatorischer Aufsicht stattfinden und entsprechend steuerbar, prüfbar und nachvollziehbar sein müssen.

Der zweite Teil widmet sich nun der praktischen Umsetzung. Wie wird aus diesen Leitplanken ein steuerbarer Prozess? Welche Phasen haben sich bewährt und wo liegen typische Risiken, die in der Praxis regelmäßig unterschätzt werden?

Initiierung: das Projekt richtig aufsetzen

Die Durchführung eines Rechenzentrumsumzugs beginnt lange vor der ersten technischen Aktivität. In der Initiierungsphase wird nicht primär geplant, sondern entschieden, wie mit Unsicherheit umgegangen wird. Gerade im Umfeld Kritischer Infrastrukturen ist zu Projektbeginn selten klar, welche Systeme tatsächlich umgezogen, abgeschaltet oder ersetzt werden können. Entscheidend ist daher, Anforderungen bewusst als fortschreibbar zu definieren und nicht als vermeintlich abschließendes Zielbild.

Zu den zentralen Themen dieser Phase gehören die Definition von Projektumfang und Abgrenzung, die Klärung von Rollen, Verantwortlichkeiten und Entscheidungsbefugnissen sowie die frühe Einbindung von Organisationseinheiten wie Betrieb, Informationssicherheit, Einkauf und Governance.

Ein häufiger Fehler besteht darin, den Rechenzentrumsumzug isoliert zu betrachten. In der Praxis ist er fast immer mit weiteren Vorhaben verknüpft, etwa mit Cloud-Migrationen, Konsolidierungen oder organisatorischen Veränderungen. Die Initiierung muss daher klar festlegen, was explizit Teil des Umzugs ist und was nicht, um spätere Zielkonflikte zu vermeiden. 

Ist-Zustand: Realität statt Annahmen

Die Erhebung des Ist-Zustands ist eine der kritischsten Phasen des gesamten Vorhabens. Ziel ist nicht Detailplanung, sondern ein realistisches Bild der vorhandenen Komplexität. Dazu gehören sowohl die physische Infrastruktur als auch logische Abhängigkeiten, externe Anbindungen und organisatorische Zuständigkeiten.

In der Praxis zeigt sich immer wieder, dass Dokumentationen unvollständig oder veraltet sind, Wissen über Systeme und Sonderregelungen auf wenige Personen verteilt ist und fachliche Sichtweisen nicht immer mit physischen Abhängigkeiten übereinstimmen.

Gerade im Umfeld Kritischer Infrastrukturen führt diese Unsicherheit häufig dazu, dass Systeme vorsorglich weiterbetrieben oder zusätzliche Komponenten aufgebaut werden. Ohne eine bewusste Klärung des Ist-Zustands wächst so die Komplexität im Projektverlauf weiter an, statt reduziert zu werden.

Der Ist-Zustand bildet zudem die Grundlage für realistische Aussagen zu Parallelbetrieb, Flächenbedarf und Übergangsdauer. Reduktionsziele lassen sich erst bewerten, wenn klar ist, welche Systeme tatsächlich abgeschaltet werden dürfen und zu welchem Zeitpunkt. 

Übergang ins Zielrechenzentrum: Abnahme vor Umzug

Ein häufiger Erfolgsfaktor aus der Praxis ist die klare Trennung zwischen der Bereitstellung des Zielrechenzentrums und der Migration produktiver Systeme. Der operative Umzug sollte erst beginnen, wenn Raum, Stromversorgung, Kühlung, Sicherheitszonen, Zutrittsregelungen und logistische Rahmenbedingungen formal abgenommen wurden.

In dieser Phase wird das Zielrechenzentrum als Betriebsumgebung aufgebaut. Dazu gehören Rack-Strukturen, Stromversorgung und Verkabelung, Netzwerk und Sicherheitskomponenten sowie zentrale Basisdienste wie Monitoring, Logging, Zeitdienste oder Backup.

Erfahrungsgemäß lassen sich Risiken deutlich reduzieren, wenn produktive Systeme erst dann migriert werden, wenn diese Basis stabil verfügbar, getestet und dokumentiert ist. Der Rechenzentrumsumzug wird dadurch zu einem schrittweisen Übergang und nicht zu einem Sprung ins Unbekannte. 

Migrationsvorbereitung: Verifikation statt Planung auf Papier

Auf Basis des Ist-Zustands wird der konkrete Umzug vorbereitet. Ein entscheidender Schritt ist dabei die Verifikation des tatsächlichen Umzugsumfangs gemeinsam mit fachlich und technisch verantwortlichen Rollen. Fachbereiche und Systemverantwortliche bestätigen, welche Systeme migriert werden, welche Randbedingungen gelten und welche Abhängigkeiten bestehen.

Dabei zeigt sich regelmäßig, dass nicht alle Systeme einem einheitlichen Migrationspfad folgen können. Einige verbleiben länger im alten Rechenzentrum, andere werden parallel betrieben oder funktional ersetzt. Der Umzug ist damit kein einmaliges Ereignis, sondern eine Abfolge abgestimmter Schritte.

Für die Steuerung haben sich geregelte Antrags- und Ticketprozesse bewährt, über die Rack-Plätze, Energie- und Anschlussbedarfe koordiniert werden. Diese Verfahren schaffen Transparenz und verhindern, dass Änderungen informell und unkoordiniert erfolgen. 

Durchführung: Umzug als wiederkehrender Prozess

Der operative Umzug folgt in der Regel einem klaren, wiederkehrenden Ablauf. Dazu gehören der abgestimmte Abbau im alten Rechenzentrum, Transport und Einbau im Zielrechenzentrum, Anschluss und technische Basisprüfungen sowie die fachliche und technische Abnahme durch verantwortliche Rollen.

Erst mit dieser Freigabe gilt ein System als erfolgreich umgezogen. Wartungsfenster werden häufig genutzt, um historisch gewachsene Komplexität gezielt zu reduzieren, etwa durch die Trennung fachlich unabhängiger Anwendungen oder die Bereinigung alter Abhängigkeiten. Solche Eingriffe erfolgen bewusst, mit klarer Freigabe und angepasster Dokumentation.

Rollback-Szenarien sind grundsätzlich vorzusehen, werden jedoch nicht als Standardlösung eingeplant. Ziel ist es, Probleme innerhalb der vorgesehenen Wartungsfenster zu identifizieren und zu beheben. Klare Zuständigkeiten, Entscheidungsbefugnisse und Kommunikationswege sind hierfür essenziell. 

Parallelbetrieb und Rückbau: der unterschätzte Teil

Parallelbetrieb ist im Umfeld Kritischer Infrastrukturen kein Fehlzustand, sondern ein bewusst eingesetztes Übergangsszenario. Er ermöglicht Tests, Stabilisierung und regulatorische Freigaben, bindet jedoch Zeit, Fläche und Ressourcen. Entscheidend ist daher eine klare zeitliche Begrenzung sowie Transparenz über die damit verbundenen Kosten und Abhängigkeiten.

Der Rückbau des alten Rechenzentrums ist ein eigenständiger und risikobehafteter Abschnitt. Solange noch Systeme parallel betrieben werden, besteht ein erhöhtes Risiko manueller Fehler, etwa durch verfrühte Demontage oder das Entfernen gemeinsamer Abhängigkeiten. Strukturierte Rückbaupläne, klare Freigaben und genehmigte Runbooks sind hier unverzichtbar.

Ein Rechenzentrumsumzug gilt erst dann als abgeschlossen, wenn das alte Rechenzentrum vollständig außer Betrieb genommen wurde, alle Daten gelöscht sind, Leitungen getrennt und Zugangsberechtigungen entzogen wurden. Erst mit dieser formalen Trennung endet die operative Verantwortung und der Übergang in den stabilen Linienbetrieb ist vollzogen. 

Fazit: Durchführung ist Steuerung unter Unsicherheit.

Die Durchführung eines Rechenzentrumsumzugs im Umfeld Kritischer Infrastrukturen ist kein linearer Vollzug eines Plans, sondern ein gesteuerter Prozess über einen längeren Zeitraum. Schlüsselübergabe, Inbetriebnahme, Migration, Parallelbetrieb und Rückbau greifen ineinander und müssen kontinuierlich abgestimmt werden.

Erfolgsentscheidend sind nicht technische Einzelmaßnahmen, sondern realistische Annahmen, klare Verantwortlichkeiten, transparente Kommunikation, verfügbare Expertise und die Fähigkeit, auch unter Unsicherheit handlungsfähig zu bleiben.

Wer den Umzug als reines Transportprojekt versteht, unterschätzt seine Komplexität. Wer ihn als strukturierten Entscheidungs- und Steuerungsprozess begreift, schafft die Grundlage für einen stabilen, prüfbaren und langfristig tragfähigen Betrieb. 

Wie ORDIX unterstützen kann

Die praktische Umsetzung von Rechenzentrumsumzügen im regulierten Umfeld erfordert neben technischer Expertise vor allem Erfahrung im Umgang mit Unsicherheit, Governance‑Anforderungen und komplexen Übergangsszenarien.

Seminarempfehlung