Wenn ein Werkstillstand mehr kostet als ein komplettes Netzwerkprojekt, ist klar: Wer eine Netzwerkmigration planen will, braucht keine allgemeine Checkliste, sondern ein belastbares Vorgehensmodell. Genau dort scheitern viele Programme – nicht an der Technik, sondern an unklaren Abhängigkeiten, schlecht getakteten Cutovers und fehlender Governance zwischen IT, OT, Betrieb, Security und externen Partnern.
Netzwerkmigration planen heißt Geschäftsrisiken steuern
In Enterprise-Umgebungen ist eine Netzwerkmigration selten nur ein Austausch von Switches, Firewalls oder WLAN-Komponenten. Meist hängt daran deutlich mehr: Standortkonsolidierung, NAC-Umstellung, Segmentierung, neue Security-Vorgaben, Backbone-Erweiterung, Provider-Wechsel oder die Anbindung von Produktionssystemen. In Smart-Factory- oder kritischen Infrastrukturprojekten kommen zusätzliche Zwänge dazu – enge Wartungsfenster, validierte Systeme, Legacy-Komponenten und Lieferketten, die keine Unterbrechung verzeihen.
Deshalb ist die wichtigste Frage am Anfang nicht, welche Hardware beschafft wird. Die entscheidende Frage lautet: Welche geschäftskritischen Services dürfen zu keinem Zeitpunkt beeinträchtigt werden, und welche technischen Entscheidungen ergeben sich daraus? Diese Reihenfolge trennt operative Projektsteuerung von rein technischer Umsetzung.
Wer die Netzwerkmigration nur als Infrastrukturmaßnahme betrachtet, plant zu kurz. Wer sie als Transformationsprojekt aufsetzt, gewinnt Kontrolle über Risiken, Ressourcen und Entscheidungswege.
Die Planungsphase entscheidet über den Cutover
Viele Probleme entstehen Wochen vor dem eigentlichen Migrationstermin. Der Cutover selbst macht nur sichtbar, was in der Planung bereits schief lief. Deshalb muss die Vorphase deutlich tiefer sein als eine reine Bestandsaufnahme.
Zuerst braucht es ein klares Zielbild. Soll das Netzwerk standardisiert, segmentiert, skaliert oder sicherer gemacht werden? Geht es um technische Schulden, Performance, Compliance oder um die Vorbereitung auf künftige Rollouts? Ohne dieses Zielbild entstehen Designentscheidungen im Tagesgeschäft, und genau das verlängert Projekte und erhöht Nacharbeit.
Danach folgt die Abhängigkeitsanalyse. In Konzernlandschaften laufen Services selten isoliert. Authentifizierung, DHCP, DNS, WAN-Anbindung, Produktionssysteme, Zutrittskontrolle, Drucker, VoIP, MES, ERP-nahe Schnittstellen oder externe Provider hängen oft an stillen Annahmen, die in keiner aktuellen Dokumentation stehen. Wer diese Abhängigkeiten nicht vorab aufdeckt, migriert formal erfolgreich und produziert operativ Störungen.
Ebenso wichtig ist die Stakeholder-Landkarte. Netzwerkteams sehen häufig Layer 2 und Layer 3. Der Betrieb sieht Schichtmodelle, Verfügbarkeiten und Eskalationen. Die Security bewertet Policies und Zugriffe. Die Werks- oder Standortleitung will wissen, ob die Produktion sicher weiterläuft. Jeder dieser Blickwinkel ist legitim – und muss in eine gemeinsame Steuerungslogik übersetzt werden.
Welche Daten vor der Migration wirklich zählen
Eine belastbare Planung braucht Daten, aber nicht jede Information ist gleich relevant. Entscheidend sind die Datenpunkte, die Migrationsentscheidungen beeinflussen.
Dazu gehören aktuelle Topologien, Portnutzung, VLAN- und IP-Strukturen, Routing-Beziehungen, Firewall-Regeln, WAN-Pfade, Redundanzen, DHCP-Bereiche, DNS-Abhängigkeiten und die reale Auslastung kritischer Segmente. In produktionsnahen Umgebungen kommen OT-Komponenten hinzu, etwa PLC-nahe Kommunikation, SCADA-Anbindungen, industrielle PCs, Altgeräte ohne aktuelle Firmware und Systeme mit fest verdrahteten Netzannahmen.
Der zentrale Punkt: Dokumentation allein reicht nicht. In vielen Enterprise-Umgebungen ist die Dokumentation veraltet, unvollständig oder lokal gepflegt. Daher müssen Planungsstände immer mit Realitätsdaten abgeglichen werden – durch Discovery, Konfigurationsanalyse, Site Surveys und technische Validierung mit den Betriebsverantwortlichen.
Gerade bei gewachsenen Netzwerken gilt: Je älter der Standort, desto höher die Wahrscheinlichkeit versteckter Sonderlösungen. Das ist kein Randthema, sondern oft der Grund, warum Standardmigrationen an einzelnen Bereichen scheitern.
Das richtige Migrationsmodell wählen
Nicht jede Umgebung verträgt dieselbe Vorgehensweise. Wer eine Netzwerkmigration planen möchte, muss das Migrationsmodell an Betriebsrealität und Risikoprofil ausrichten.
In weniger kritischen Office- oder Campus-Umgebungen kann ein gebündelter Cutover sinnvoll sein, wenn Testtiefe, Vorbereitung und Rollback stimmen. In Produktionswerken, Logistikzentren oder KRITIS-nahen Umgebungen ist häufig ein phasenweises Modell besser. Dann werden Segmente, Hallen, Gebäude oder Services in kontrollierten Wellen migriert.
Der Vorteil eines Big-Bang-Cutovers liegt in der kürzeren Übergangsphase. Der Nachteil ist offensichtlich: Wenn etwas falsch eingeschätzt wurde, ist der Impact sofort groß. Das phasenweise Modell reduziert Risiko und erleichtert Lernen zwischen den Wellen, erzeugt aber mehr temporäre Komplexität, etwa durch Parallelbetrieb, Übergangsregeln oder zusätzliche Abstimmung.
Es gibt keine universell richtige Methode. Es hängt davon ab, wie tolerant das Geschäft gegenüber Unterbrechungen ist, wie standardisiert die Standorte sind und wie schnell technische Teams auf Incidents reagieren können.
Governance statt Feuerwehrmodus
Sobald mehrere Standorte, Provider, Hersteller oder interne Fachbereiche beteiligt sind, reicht technische Exzellenz allein nicht mehr. Dann braucht das Projekt eine saubere Governance.
Das beginnt bei einer klaren Rollenverteilung. Wer trifft Designentscheidungen? Wer verantwortet Freigaben? Wer bewertet Betriebsrisiken? Wer führt den Cutover? Wer kommuniziert im Störungsfall an Management, Standort und Service Desk? Wenn diese Fragen offenbleiben, eskalieren selbst lösbare Probleme unnötig.
Ein funktionierendes Steuerungsmodell umfasst in der Praxis einen belastbaren Entscheidungsprozess, ein RAID-Log für Risiken, Annahmen, Probleme und Abhängigkeiten, eine saubere Change- und Freeze-Planung sowie ein konsistentes Reporting. Gerade in internationalen Programmen ist Reporting kein Selbstzweck. Es ist das Instrument, mit dem Management Vertrauen behält und Eskalationen früh genug adressiert werden.
Hier zeigt sich oft der Unterschied zwischen Infrastrukturprojekt und Transformation. Infrastrukturteams fokussieren auf Technik. Erfolgreiche Programme verbinden Technik, Betrieb, Governance und Timing.
Tests, Pilotierung und Rollback sind keine Formalitäten
Viele Migrationspläne behandeln Tests als Pflichtpunkt vor Go-Live. Das ist zu kurz gedacht. Tests müssen die reale Betriebslogik abbilden, nicht nur die technische Grundfunktion.
Ein Ping-Test beweist nicht, dass ein Werk stabil produziert. Ein erfolgreicher Login sagt nichts über Drucker, Scanner, Voice, Maschinenanbindung oder Authentifizierungsketten aus. Gute Testplanung definiert deshalb geschäftsnahe Testfälle. Welche Abläufe müssen nach der Umstellung sicher funktionieren? Welche Nutzergruppen oder Systeme sind kritisch? Welche Fehler wären tolerierbar, welche nicht?
Ein Pilot hilft, aber nur wenn er repräsentativ ist. Ein sauberer Pilotstandort sollte nicht der einfachste sein, sondern ausreichend nah an der Komplexität der Zielumgebung liegen. Sonst erzeugt der Pilot falsche Sicherheit.
Noch wichtiger ist der Rollback-Plan. Viele Projekte schreiben Rollback in die Unterlagen, ohne ihn operativ durchzuplanen. Ein echter Rollback braucht klare Trigger, Zeitgrenzen, Verantwortlichkeiten und technische Voraussetzungen. Wenn nach zwei Stunden niemand mehr weiß, ob zurückgebaut werden soll oder weiter analysiert wird, ist der Schaden oft größer als die ursprüngliche Störung.
Typische Fehler beim Netzwerkmigration planen
Die häufigsten Probleme sind erstaunlich konstant. Erstens wird die Komplexität von Altumgebungen unterschätzt. Zweitens werden lokale Sonderlocken zu spät sichtbar. Drittens fehlt eine abgestimmte Cutover-Kommunikation mit Betrieb, Service Desk und Management. Viertens werden Abhängigkeiten zu NAC, Security Policies oder externen Providern nicht konsequent mitgesteuert.
Ein weiterer Klassiker ist die falsche Ressourcenplanung. Während der Migration werden oft die besten Techniker in operative Störungen gezogen, weil das Tagesgeschäft parallel weiterläuft. Dann fehlt genau im kritischen Fenster die Entscheidungskraft im Projekt. Wer das vermeiden will, plant dedizierte Rollen, Eskalationspfade und verfügbare Experten verbindlich ein.
Auch Vendor-Management wird regelmäßig unterschätzt. Wenn Hersteller, Carrier, lokale Dienstleister und interne Teams unterschiedliche Terminlogiken haben, scheitert nicht die Architektur, sondern die Koordination. Deshalb müssen Liefertermine, Konfigurationsfreigaben, Vor-Ort-Ressourcen und Supportfenster früh vertraglich und operativ synchronisiert werden.
So entsteht ein belastbarer Projektzuschnitt
Ein gutes Migrationsprogramm ist weder überbürokratisch noch improvisiert. Es braucht genau so viel Struktur, dass Entscheidungen schnell und Risiken kontrollierbar bleiben.
In der Praxis bewährt sich ein Zuschnitt mit klaren Phasen: Assessment, Design-Freigabe, Pilot, Wellenplanung, Cutover-Steuerung und Stabilisierung. Entscheidend ist nicht die Bezeichnung, sondern die inhaltliche Schärfe je Phase. Vor allem die Übergänge müssen sauber definiert sein. Ein Standort darf erst in die Cutover-Planung gehen, wenn Design, Abhängigkeiten, Testszenario, Kommunikationsplan und Rollback freigegeben sind.
Für Enterprise-Umgebungen mit mehreren Standorten ist Standardisierung der größte Hebel. Je stärker Templates, Konfigurationsmuster, Runbooks und Freigabeprozesse vereinheitlicht sind, desto planbarer werden Kosten, Dauer und Qualität. Genau dort entsteht Skalierung – nicht durch mehr Druck im Rollout, sondern durch weniger Varianz im Vorgehen.
Wer solche Programme verantwortet, braucht deshalb beides: technisches Verständnis und PMO-Disziplin. ITNB arbeitet in genau diesem Spannungsfeld – zwischen Architektur, Steuerung und operativer Umsetzung in komplexen Infrastruktur- und Transformationsprojekten.
Was Entscheider wirklich steuern sollten
Für CIOs, Factory IT Leads, Infrastructure Program Leads oder PMO-Verantwortliche ist die Kernfrage nicht, ob eine Migration technisch machbar ist. Sie ist fast immer machbar. Die eigentliche Frage lautet, ob sie planbar, steuerbar und im laufenden Betrieb verantwortbar ist.
Darauf gibt es keine Abkürzung. Wer früh sauber bewertet, Abhängigkeiten transparent macht, Governance ernst nimmt und den Cutover wie einen geschäftskritischen Eingriff behandelt, reduziert nicht nur Ausfälle. Er verkürzt auch Entscheidungswege, senkt Nacharbeiten und erhöht die Belastbarkeit des gesamten Programms.
Am Ende gewinnt nicht das Team mit den meisten Folien, sondern das mit dem klarsten Plan für den Moment, in dem etwas nicht nach Plan läuft.
