Freitagabend, der alte WiFi Controller ist wieder einmal überlastet. Eine Hotelrezeption setzt zwischen den Check-ins Access Points zurück, ein Einzelhandelsgeschäft verliert die Zahlungsverbindung, eine Krankenhausstation meldet unzuverlässige klinische Mobilität, oder Bewohner in einem verwalteten Gebäude stehen vor einem Support-Büro Schlange, weil das Mandantenportal die Authentifizierung eingestellt hat. Das Migrationsprogramm hat sich bereits verzögert, und jede "temporäre" Übergangslösung befindet sich nun in der Produktionsumgebung.
Diese Situation ist der Ausgangspunkt für die Migration von Altsystemen. Das Problem ist nicht, dass Hardware oder Software veraltet ist. Das Problem ist, dass eine Organisation ein Betriebsmodell um eine fragile Infrastruktur, undokumentierte Abhängigkeiten, manuelle Verwaltung, abgelaufenen Support und Identitätsdienste herum aufgebaut hat, die niemand abschalten möchte. Dieses Playbook behandelt WiFi, Identität und mandantenfähige Netzwerkdienste als eigenständige Migrationsziele und nicht als bloße Infrastruktur, um die man sich erst nach dem Umzug der Anwendungen kümmert.
Warum die Migration von Altsystemen einen echten Plan erfordert
Ein ausfallender Netzwerk-Stack fällt selten isoliert aus. Ein Ausfall des Hotel-WiFi kann den Zimmerzugang, Integrationen in das Property-Management-System, den Login für Treueprogramme und die Abläufe zur Gäste-Rückgewinnung beeinträchtigen. Ein Einzelhändler verliert möglicherweise die Verbindung zwischen Kassen, Zahlungsdiensten, Warenwirtschaftssystemen und dem Kunden-WiFi. Im Gesundheitswesen kann die Abhängigkeitskette Verzeichnisdienste, RADIUS, Zertifikate, Integrationen für den Schwesternruf, medizinische Geräte und mobile Anwendungen umfassen. In einer Wohnanlage kann ein gemeinsamer Authentifizierungsdienst Mieter, Auftragnehmer, Gebäudepersonal, Kameras, Aufzüge und Gemeinschaftseinrichtungen unterstützen.
Der Business Case ist daher betrieblicher und nicht kosmetischer Natur. Erfassen Sie die Vorfälle, fehlgeschlagenen Authentifizierungen, manuellen Resets, Ausfallminuten, Notfalleinsätze der Techniker, veralteten Lizenzen und knappen Ersatzteile. Identifizieren Sie dann, was diese Fehler verhindern. Eine Migration kann den Verwaltungsaufwand reduzieren, die Supportfähigkeit verbessern, Abdeckungs- und Authentifizierungsprobleme klarer aufdecken, das Onboarding vereinfachen und Sicherheitsteams eine sauberere Basis für Zugriffsüberprüfungen bieten.
Praktische Regel: Wenn das Unternehmen nicht erklären kann, wer für eine Identitätsquelle verantwortlich ist, wer Richtlinienänderungen genehmigt und wer ein Rollback autorisieren darf, ist es nicht bereit für den Cutover.
Der öffentliche Sektor im Vereinigten Königreich liefert eine nützliche Warnung vor einem Aufschub. Eine parlamentarische Antwort des Vereinigten Königreichs aus dem Jahr 2025 zu Altsystemen schätzte, dass Altsysteme im Jahr 2024 28 % der Systeme in Ministerien der Zentralregierung ausmachten, gegenüber 26 % im Jahr 2023. Dieselbe Quelle belegte, dass 60 % der digitalen Regierungsdienste in die Cloud migriert waren, dieser Fortschritt jedoch 13 Jahre gedauert hatte, während 28 % des Bestands immer noch Altsysteme waren. Die mehrheitliche Cloud-Einführung beseitigte nicht den harten Kern alter Abhängigkeiten.
Ein Eins-zu-eins-Ersatz bewahrt oft dieselben Schwachstellen unter neuen Logos. Wenn die alte Plattform auf gemeinsam genutzten Konten, manuellen VLAN-Änderungen, anfälligem RADIUS-Routing oder einem einzigen Management-Endpunkt basiert, macht der Umzug auf neue Hardware den Fehler nur schwerer erkennbar. Bauen Sie den Plan um die Faktoren Inhaberschaft, Nachweis von Abhängigkeiten, Migrationswellen, Identitätsvertrauen, Parallelbetrieb und Rollback herum auf. Das Ergebnis ist kein reines Hardware-Upgrade. Es ist die Ablösung eines fehlerhaften Betriebsmodells, ohne dass Gäste, Klinikpersonal, Mitarbeiter oder Bewohner auf der Strecke bleiben.
Bewertung des Bestands, bevor Sie eine einzige Arbeitslast verschieben
Beginnen Sie mit einer Bestandsaufnahme, nicht mit einer Lieferantenpräsentation. Erstellen Sie ein verifiziertes Register, das jeden Controller, Access Point, Switch, jede Firewall, jedes Captive Portal, jedes Verzeichnis, jede Zertifizierungsstelle, jeden RADIUS-Server, jedes VLAN, jede SSID und jede Management-Konsole erfasst. Erfassen Sie den Standort, den Eigentümer, den Mandanten oder die Geschäftseinheit, das Modell, die Firmware, den Support-Status, den beobachteten Datenverkehr, die Authentifizierungsmethode, die Konfigurationsquelle und bekannte Abhängigkeiten.
Das Wort verifiziert ist entscheidend. Eine Tabelle, die aus Beschaffungsunterlagen erstellt wurde, erfasst keine unmanaged Access Points, verwaisten Integrationen, temporären SSIDs und von lokalen Teams installierten Geräte. Vergleichen Sie Konfigurationsexporte mit dem tatsächlichen Datenverkehr, Monitoring-Daten, Service-Tickets und Interviews mit den Personen, die die jeweiligen Standorte betreuen.
Personen, Geräte und Vertrauensbeziehungen zuordnen
Behandeln Sie Identität als eigene Bestandsaufnahme. Trennen Sie Mitarbeiter, Auftragnehmer, Gäste, Patienten, Studenten, Bewohner, IoT-Geräte und Dienstkonten. Dokumentieren Sie für jede Gruppe die Single Source of Truth, den Onboarding- und Offboarding-Prozess, die Gültigkeitsdauer von Anmeldedaten, den Zertifikatsbesitz, den Genehmigungspfad und die Notfallzugriffsmethode.
Testen Sie dann repräsentative Arbeitsabläufe statt allgemeiner Konnektivität. Ein Hotel benötigt Check-in, Zimmerzugang, Gäste-WiFi und Übergaben an das Property-Management-System. Ein Einzelhändler benötigt Point-of-Sale-Konnektivität, Loyalty-Anmeldung, Handgeräte und Store-Failover. Ein Krankenhaus benötigt klinische Mobilität, vernetzte Geräte, Mitarbeiterauthentifizierung und Ausfallsicherheit auf Stationsebene. Ein Wohnkomplex benötigt Mieter-Onboarding, Gemeinschaftseinrichtungen, Besucherzugang und die Isolierung zwischen den Bewohnern.
Treffen Sie Migrationsentscheidungen auf Basis von Fakten
Klassifizieren Sie jedes Asset oder jeden Workflow nach geschäftlicher Kritikalität, Datensensibilität, Kompatibilitätsrisiko und Dringlichkeit. Kennzeichnen Sie nicht unterstützte Protokolle, ablaufende Zertifikate, Single Points of Failure, undokumentierte Firewall-Regeln, hartcodierte Dienstkonten und Lücken in der Datenqualität. Weisen Sie einen verantwortlichen Eigentümer zu und definieren Sie die Nachweise, die für das Bestehen jeder Phase erforderlich sind.
| Asset oder Workflow | Zu erfassende Nachweise | Risikobewertung | Migrationswelle |
|---|---|---|---|
| RADIUS und Verzeichnispfad | Authentifizierungsprotokolle, Mapping der Single Source of Truth, Failover-Konfiguration, Service-Eigentümer | Hoch, wenn standortübergreifend gemeinsam genutzt | Frühe Basiswelle |
| Captive Portal und Gäste-Identität | Weiterleitungs-Flows, Voucher- oder Profil-Einträge, Einwilligungsnachweise, CRM- und PMS-Abhängigkeiten | Hoch in kundenorientierten Umgebungen | Pilotprojekt nach Standort oder Tenant |
| Klinische oder operative SSIDs | Geräteregister, Authentifizierungsmethode, klinische Workflow-Tests, Support-Zeitfenster | Kritisch, wo die Servicekontinuität entscheidend ist | Kontrollierte, standortspezifische Welle |
| Mandantenfähige Services | Mandanten-Trennungsregeln, iPSK oder gleichwertige Konfiguration, SSO-Flows, Support-Zuständigkeit | Hoch, wo eine Isolation vertraglich vorgeschrieben ist | Wellen nach Mandanten-Kohorten |
| Access Points und Controller | Firmware, Support-Status, Verbindungsverlauf, Konfigurations-Backup, physischer Standort | Mittel bis hoch, je nach Abdeckung | Ausrichtung an validierten Service-Wellen |
Ein Anbieter kann bei der Asset-Erfassung helfen, aber kein Tool kann ein unvollständiges Mapping der Verantwortlichkeiten reparieren. Das Register sollte zur Entscheidungsdatenbank des Programms werden. Wenn ein Element keinen Eigentümer, keinen Nachweis von Abhängigkeiten oder keinen Rollback-Pfad hat, gehört es nicht in eine Go-Live-Welle.
Die Wahl des richtigen Migrationsansatzes
Wählen Sie den Ansatz, der zu den Rahmenbedingungen passt. Trends hinterherzulaufen ist eine schlechte Migrationsmethode, insbesondere wenn das Netzwerk Identitäten und kritische Betriebsabläufe trägt.
Rehost verschiebt einen bestehenden Dienst mit minimalen Änderungen auf eine neuere Infrastruktur. Nutzen Sie diese Methode für einen dringenden Hardware- oder Hypervisor-Ausstieg, eine stabile RADIUS-Bereitstellung oder eine Plattform, die sich immer noch berechenbar verhält, aber eine betriebliche Grenze erreicht hat. Sie ist schnell, übernimmt jedoch manuelle Prozesse, Lizenzannahmen, Konfigurationsfehler und technische Schulden.
Replatforming ändert die Laufzeitumgebung, während das Kernverhalten des Dienstes beibehalten wird. Ein Captive Portal könnte auf verwaltete Container migriert werden, oder eine Verzeichnisintegration auf eine unterstützte Service-Ebene. Dies ist der vernünftige Mittelweg, wenn die Geschäftslogik solide ist, die Betriebsplattform jedoch teuer oder schwer zu warten ist.
Refactoring ändert das interne Design. Das kann bedeuten, statische Netzwerkregeln durch Richtliniendienste zu ersetzen, APIs bereitzustellen oder Identitätsentscheidungen von der Portal-Präsentation zu trennen. Refactoring schafft ein besseres Fundament, erfordert jedoch klarere Produktentscheidungen und mehr Tests als ein Lift and Shift.
Eine Strangler-Migration betreibt alte und neue Dienste parallel, während jeweils ein Standort, ein Mandant, eine SSID oder ein Workflow nacheinander umgestellt wird. Für WiFi- und Identitätsumgebungen ist dies in der Regel der sicherste Standard, da das Team die Koexistenz validieren, Richtlinienergebnisse vergleichen und eine definierte Benutzergruppe auf die alte Ebene zurückführen kann.
| Ansatz | Beste Eignung | Hauptvorteil | Hauptrisiko |
|---|---|---|---|
| Rehost | Dringender Infrastrukturausstieg | Minimale Serviceänderung | Bewahrt Designschwächen |
| Replatform | Stabile Integrationen mit kostspieliger Laufzeit | Bessere Unterstützbarkeit ohne Neuschreiben | Kompatibilitätsaufwand bleibt bestehen |
| Refactor | Neugestaltung von Richtlinien, API und Orchestrierung | Stärkeres langfristiges Betriebsmodell | Höherer Aufwand für Bereitstellung und Tests |
| Strangler | Gemeinsame Identität und standortübergreifende Netzwerke | Kleine Kohorten und schnelles Fallback | Koexistenz muss technisch gelöst werden |
Ein praktisches Programm kann eine stabile RADIUS-Plattform rehosten, das Gäste-Portal replatformen und die Richtliniendurchsetzung refaktoren. Erfassen Sie die gewählte Methode, abgelehnte Alternativen, den Koexistenzzeitraum, den Eigentümer und die Beendigungsbedingung für jeden Workload. Organisationen, die verwaltete professionelle Dienstleistungen evaluieren, können auch das professionelle Dienstleistungsangebot von Purple neben ihrem internen Bereitstellungsmodell prüfen.
Vermeiden Sie einen Big-Bang-Cutover, es sei denn, die Umgebung ist einfach, die Synchronisierung ist erprobt und das Rollback-Fenster ist vertretbar. In einer mandantenfähigen Umgebung bedeutet "alles auf einmal" meistens "alle Support-Anrufe auf einmal".
Daten und Identitäten migrieren, ohne Vertrauen zu verspielen
Identität ist das Rückgrat der Migration. Wenn sie ausfällt, sind die Access Points zwar betriebsbereit und die Switches leiten den Datenverkehr weiter, aber der Dienst ist für die Person, die ihn benötigt, trotzdem nicht verfügbar.
Beginnen Sie mit der Erfassung jeder Authentifizierungsquelle. Berücksichtigen Sie RADIUS-Server, Captive Portals, Integrationen für das Hotelmanagement (Property-Management-Systeme), Active Directory-Forests, Entra ID-Verbindungen, Google Workspace, Okta, gemeinsam genutzte Dienstkonten, Gerätezertifikate und lokale Notfallkonten. Entscheiden Sie, welche Quellen fortbestehen, welche vorübergehend synchronisiert und welche stillgelegt werden müssen, bevor der neue Dienst die führende Rolle übernehmen kann.
Koexistenz bewusst aufbauen
Führen Sie die Verzeichnissynchronisation phasenweise durch. Gleichen Sie Identitäten anhand stabiler Attribute ab, beheben Sie Duplikate vor der Freigabe des Zugriffs und definieren Sie, wie deaktivierte oder ausgeschiedene Benutzer in den neuen Dienst übertragen werden. Nutzen Sie die Migration nicht als Ausrede, um ein zweites, unkontrolliertes Identitätsverzeichnis zu erstellen. Jedes temporäre Konto benötigt einen Verantwortlichen, eine Ablaufbedingung und ein Audit-Protokoll.
Zertifikate erfordern dieselbe Disziplin. Erfassen Sie die Zertifizierungsstellen, Vorlagen, ausstellenden Systeme, Verantwortlichkeiten für die Verlängerung, Vertrauensketten und Gerätebestände, die EAP-TLS oder 802.1X nutzen. Erneuern Sie Zertifikate in einer kontrollierten Reihenfolge, beginnend mit einer repräsentativen Benutzergruppe. Halten Sie den alten Vertrauenspfad so lange verfügbar, bis die neue Kette die Authentifizierungs- und Sperrprüfungen auf allen relevanten Geräteklassen erfolgreich durchlaufen hat.
"Eine Migration von Anmeldedaten ist eine Dienstmigration. Behandeln Sie Passwort-Resets, Zertifikatsverlängerungen und Kontodeaktivierungen als Änderungen mit direkten Auswirkungen auf die Kunden."
Die Identität von Gästen erfordert einen separaten Arbeitsablauf. Bewahren Sie die Beziehung zwischen Profilen, Einwilligungen, Gutscheinen, Loyalitätsdaten und wiederkehrenden Nutzern, sofern das Unternehmen darauf angewiesen ist. Testen Sie die Registrierung, den wiederkehrenden Zugriff, vergessene Daten, den Ablauf, das Opt-out und die supportgestützte Wiederherstellung. Gäste sollten nicht feststellen müssen, dass die Migration nur deshalb erfolgreich war, weil ihr bisheriger Zugriff verschwunden ist.
Sequenzieren Sie den Zugriff, nicht nur die Hardware
Verschieben Sie Identitätsdienste vor weitreichenden SSID und VLAN Änderungen. Migrieren Sie dann eine definierte SSID, einen Standort, einen Mandanten oder einen Arbeitsablauf, während Sie das Authentifizierungs- und Datenverkehrsverhalten überwachen. Halten Sie im Gesundheitswesen klinische und gerätebezogene Pfade vom allgemeinen Mitarbeiterzugang getrennt. Sichern Sie in Wohnumgebungen die Mandantenisolierung, während Sie den Dienst ändern, der diese bereitstellt. Überprüfen Sie im Gastgewerbe die Übergabe an das Property-Management-System, bevor Sie den neuen Gäste-Flow für jedes Zimmer freigeben.
Nutzen Sie die Purple data and security overview als Referenzpunkt bei der Bewertung von Identitäts-, Sicherheits- und Datenverarbeitungsanforderungen. Die Wahl des Tools ist weniger wichtig als der Nachweis der Akzeptanz. Bevor der Datenverkehr der neuen Identitätsebene folgt, müssen eine erfolgreiche Authentifizierung, korrekte Autorisierung, Zertifikatsvertrauen, Verzeichnisdeaktivierung, Portalfertigstellung, VLAN Zuweisung und die Wiederherstellung nach einer Dienstunterbrechung nachgewiesen werden.
Tests, Cutover und Rollback, die wirklich funktionieren
Planen Sie die Umstellung rückwärts, beginnend mit dem Rollback. Die meisten unzureichenden Pläne beschreiben, wie der neue Dienst aktiviert wird, und fügen dann eine vage Anweisung hinzu, "bei Bedarf zurückzusetzen". Das ist kein Rollback-Plan. Ein echter Rollback benennt den Auslöser, den Entscheidungsträger, die technische Maßnahme, den Kommunikationsverantwortlichen und das Zeitlimit.
Nutzen Sie einen Parallelbetrieb als Testinstrument
Betreiben Sie die alte und die neue Identitäts- und Netzwerkebene für ein definiertes Zeitfenster parallel. Nutzen Sie Shadow-RADIUS-Anfragen, sofern die Architektur dies zulässt, gespiegelte Captive Portal-Abläufe, Konfigurationsvergleiche und synthetische Test-Logins für Gäste. Testen Sie erfolgreiche und fehlgeschlagene Authentifizierungen, abgelaufene Zertifikate, deaktivierte Konten, Roaming, VLAN-Zuweisung, DNS-Abhängigkeit, Firewall-Verhalten und den Ausfall eines Verzeichnis- oder RADIUS-Endpunkts.
Testen Sie nach Geschäftsbereichen. Ein Hotelbereich, ein Einzelhandelsstandort, eine freigegebene Gerätegruppe auf einer Station oder ein Wohngebäude ist aussagekräftiger als ein Labortest, der reale Integrationen ausschließt. Führen Sie ein Nachweispaket mit Zeitstempeln, Testidentitäten, Gerätetypen, Richtlinienergebnissen, Fehlern und Freigaben.
Schreiben Sie das Runbook Minute für Minute
Die Cutover-Sequenz sollte Folgendes beinhalten:
- Änderungsstopp einführen: Stoppen Sie nicht zusammenhängende Änderungen an Netzwerken, Verzeichnissen, Zertifikaten und Portalen.
- Ist-Zustand sichern: Exportieren Sie Konfigurationen, protokollieren Sie Richtlinienversionen, bewahren Sie Identitätszuordnungen und bestätigen Sie, dass Wiederherstellungsdateien nutzbar sind.
- Kohorte migrieren: Schalten Sie den definierten Standort, Mandanten, SSID oder Workflow um - keine unklare „Umgebung“.
- Verhalten beobachten: Überwachen Sie Authentifizierungen, Weiterleitungen, Access-Point-Anmeldungen, Support-Kontakte, Anwendungstransaktionen und die Mandantentrennung.
- Erweitern oder rückgängig machen: Fahren Sie erst fort, wenn der benannte Verantwortliche die Exit-Kriterien bestätigt hat. Falls ein Auslöser aktiv wird, führen Sie das geprobte Rollback aus.
Die Planungsnotizen nennen Beispiele wie eine Authentifizierungsfehlerrate von über 1,5 %, Endlosschleifen bei der Captive Portal-Weiterleitung und Beitrittsfehler von Access Points über einem vereinbarten Schwellenwert. Nutzen Sie diese Beispiele nur, wenn Ihre Baseline sie stützt, und legen Sie den endgültigen Trigger vor dem Änderungsfenster gemeinsam mit den Service-Verantwortlichen fest. Es geht nicht darum, eine universelle Zahl zu wählen. Es geht darum, Diskussionen im Krisenstab zu vermeiden.
Proben Sie den Rollback mit denselben Personen, die auch den Produktivbetrieb leiten. Ein Fallback, das nur auf dem Papier existiert, wird scheitern, wenn Zertifikate, Caches, Routen und menschliche Entscheidungen unter Druck zusammenwirken.
Realitätscheck für Kosten, Zeitplan und Compliance
Die optimistische Bereitstellungsschätzung eines Anbieters ist kein budgetreifer Entwurf für den Vorstand. Bauen Sie das Modell um Discovery, Bereinigung, Integrationen, Tests, interne Arbeitszeit, Support-Abdeckung, Lizenzierung, Kommunikation, Schulung, Ausfallzeiten und unvorhergesehene Kosten herum auf. Beziehen Sie die Netzwerkschicht als Bereitstellungsarbeit ein: WiFi Design, Identitätsdienste, Captive Portals, Zertifikate, Routing, Mandantenisolierung und standortspezifischen Cutover-Support. Eine Migration ist nicht günstig, wenn die alte Plattform auf unbestimmte Zeit in Betrieb bleibt.
Der öffentliche Sektor im Vereinigten Königreich liefert eine deutliche Warnung vor aufgeschobenen Arbeiten. Der State of Digital Government Review verzeichnete im Jahr 2024 veraltete Technologien bei 28 % der Systeme der Zentralregierung. Er stellte außerdem fest, dass der Anteil veralteter Systeme bei Polizeibehörden und NHS Trusts zwischen 10 % und 60-70 % liegt, verwies auf kritische Dienste, die auf Systemen aus den 1970er Jahren basieren, und nannte Altlasten in 153 Systemen in 16 Ministerien. Diese Zahlen sind keine Preisliste des Privatsektors. Sie zeigen, warum die Erkennung und Behebung von Abhängigkeiten in das Bereitstellungsbudget gehören und nicht in eine Gemeinkostenposition, die gestrichen wird.
Eine Analyse der Kosten von Altsystemen im öffentlichen Sektor in Großbritannien ergab, dass veraltete IT-Systeme 4 - 7 % der jährlichen Ausgaben des öffentlichen Sektors an Produktivitätsverlusten kosten. Nutzen Sie diese Zahl als Anlass, um die operative Verschwendung in Ihrer Organisation zu messen - einschließlich manueller Identitätsverwaltung, wiederholter Support-Anrufe, fehlgeschlagener Gäste-Zugriffe und Behelfslösungen für Netzwerkdienste. Stellen Sie dies jedoch nicht als garantierte Migrationsersparnis dar.
| Branche | Indikativer Kostenrahmen | Typische Dauer | Wichtigste Compliance-Treiber |
|---|---|---|---|
| Hotellerie | Umfang basierend auf Anzahl der Standorte, Gäste-Identität, PMS-Integration, WiFi Design und Support-Abdeckung | Ablaufplanung orientiert an Belegung und Veranstaltungen | Zahlungssicherheit, Datenschutz, Zugriffsprotokolle, Lieferantensicherheit |
| Einzelhandel | Umfang basierend auf Filialunterschieden, POS-Abhängigkeiten, Treueprogramm-Identität, WiFi und Verkaufszeiten | Pilotprojekt außerhalb der Spitzenverkaufszeiten, dann Rollout nach Kohorten | PCI DSS, Datenschutz, Endpoint-Kontrollen, Auditierbarkeit |
| Gesundheitswesen | Umfang basierend auf klinischen Workflows, Gerätevalidierung, Ausfallsicherheit des Funknetzwerks und Change-Governance | Längere Planungs- und Validierungsfenster | Patientensicherheit, Datenschutz, Gewährleistung für Medizinprodukte, Kontinuität |
| Wohn- und Studentenanlagen | Umfang basierend auf Mandatentrennung, Onboarding, Gemeinschaftseinrichtungen und Gebäudesystemen | Wellen nach Gebäuden oder Portfolios | Datenschutz, vertragliche Isolation, Zugriffsgovernance, Lieferantenkontrollen |
Bewerten Sie bei Gastnetzwerken die Einwilligung, Aufbewahrung, Zugriffsprotokolle, Identitätsverarbeitung und Mandantentrennung, bevor Sie sich auf ein Design festlegen. Nutzen Sie das Purple guest WiFi compliance check tool, um diesen Status zu überprüfen und finanzierungsbedürftige Lücken zu identifizieren.
Das ONS bietet eine weitere wichtige Lektion. Berichte über die Altsystem-Migration des ONS zeigten, dass Budgetbeschränkungen den Abschied von Altsystemen verlangsamten, trotz Fortschritten beim Ersatz von 80 % der Altdienste. Dieselbe Quelle berichtete, dass 90 % der Organisationen technische Schulden bei Windows aufwiesen, 60 % viele nicht unterstützte Windows Server oder Desktops hatten und 51 % Ausfallzeiten meldeten, die mit technischen Schulden zusammenhingen. Der Druck durch das Lebensende von Systemen beseitigt nicht den Bedarf an Kontinuitätsplanung.
Gleichen Sie das Programm mit PCI DSS 4.0, ISO 27001, Cyber Essentials, NIS2 (wo anwendbar) und branchenspezifischen Verpflichtungen ab. Compliance wird Schwachstellen in den Annahmen aufdecken - kalkulieren Sie daher die Kosten für Sicherheitskontrollen, Nachweise, Tests und die betriebliche Verantwortung vor dem Änderungsfenster ein.
Monitoring nach der Migration und kontinuierliche Stilllegung
Der Go-Live ist erst der Anfang der Verantwortlichkeit. Sobald der neue Dienst den Produktivbetrieb übernimmt, benötigt das Team eine Baseline, die beweist, ob die Migration den Betrieb verbessert hat oder ob nur dieselben Fehler in eine andere Konsole verschoben wurden.
Verfolgen Sie die RADIUS-Authentifizierungslatenz, die Ausfallrate des Captive Portals, den Erfolg beim Hinzufügen von Access Points, die Vorlaufzeit für die Zertifikatsverlängerung, Richtlinienabweichungen, Supportkontakte und Serviceziele auf Mandantenebene, wo eine Isolierung mehrerer Mandanten wichtig ist. Weisen Sie jedem Signal einen namentlich genannten Verantwortlichen, einen Eskalationspfad und einen Überprüfungsrhythmus zu. Ein Dashboard ohne einen verantwortlichen Bediener ist reine Dekoration.
Eine Stabilitätskurve durchführen
Nutzen Sie einen Überprüfungsrhythmus von 30, 60 und 90 Tagen. Die erste Überprüfung sollte Konfigurationsabweichungen, fehlende Warnmeldungen, wiederkehrende Authentifizierungsfehler und Support-Workarounds aufdecken. Die zweite sollte testen, ob der Dienst ohne das Eingreifen des Migrationsteams läuft. Die dritte sollte entscheiden, ob die Altplattform für die Abschaltung bereit ist.
Erklären Sie die Migration nicht für erfolgreich, nur weil die neue Plattform ein ruhiges Wochenende lang live war. Vergleichen Sie das Verhalten über Geschäftszyklen, Mandantengruppen, Geräteklassen und betriebliche Ereignisse hinweg. Das Gastgewerbe benötigt Belegungsschwankungen, der Einzelhandel Handelsbedingungen, das Gesundheitswesen genehmigte klinische Arbeitsabläufe und Wohnanlagen das Onboarding von Mietern sowie den gemeinsamen Zugang.
Ausserbetriebnahme in kontrollierten Phasen
Deaktivieren Sie den Legacy-Dienst erst, wenn die Exit-Kriterien erfüllt sind und der Business Owner die Freigabe erteilt hat. Gehen Sie beim Rückbau methodisch vor:
- Administrativer Abschluss: Stoppen Sie Änderungen, schließen Sie Supportwege, archivieren Sie genehmigte Konfigurationen und aktualisieren Sie die Eigentumsnachweise.
- Widerruf von Vertrauen: Widerrufen Sie veraltete Zertifikate, deaktivieren Sie alte Dienstkonten, entfernen Sie ungenutzte Verzeichnissynchronisierungen und beseitigen Sie verbleibende Zugriffspfade.
- Netzwerk-Ausserbetriebnahme: Entfernen Sie alte VPN-Tunnel, Richtlinien, Integrationen und Verwaltungsabhängigkeiten, und geben Sie anschließend Adressbereiche und Lizenzen frei.
- Wissensübergabe: Speichern Sie die endgültige Architektur, das Entscheidungsprotokoll, die Testnachweise, den Vorfallsverlauf und die Betriebsabläufe dort ab, wo das Support-Team sie finden kann.
Eine Analyse der britischen Regierung zur Komplexität von Altsystemen beschrieb diese als alt, anfällig, nicht unterstützbar und als Hindernis für die Transformation. Diese Quelle hat das Ausmaß des Problems bereits dargelegt. Ihre Aufgabe nach der Migration ist es, sicherzustellen, dass die alte Infrastruktur nicht als herrenlose Sicherheitsgrenze bestehen bleibt.
Purple bietet cloudbasierte WiFi-Authentifizierung und identitätsbasiertes Networking für Gäste, Mitarbeiter und Multi-Tenant-Umgebungen mit Integrationen für Verzeichnisdienste und Netzwerkplattformen. Besuchen Sie Purple, um zu prüfen, ob die Funktionen für Identität, Gästezugang, Analysen und Migration zu Ihrem Migrationsplan für Altsysteme passen.
