MPLS wird selten durch eine einzelne technische Entscheidung ersetzt. In gewachsenen Standortnetzen hängen Routing, Internet-Breakout, Security, Namensauflösung, Sprachdienste, Providerverträge und Betriebsprozesse zusammen. Wer nur die Leitung austauscht, verschiebt Risiken. Wer zuerst die Abhängigkeiten sichtbar macht, kann dagegen Standort für Standort modernisieren.
Das Ziel ist nicht „MPLS um jeden Preis abschalten“. Das Ziel ist ein nachvollziehbarer Zugriffspfad, der Anwendungen passend zu Identität, Standort, Gerät und Risiko erreichbar macht – mit weniger Abhängigkeit von zentralen Backhauls.
1. Standorte in belastbare Klassen einteilen
Eine Migrationsplanung beginnt nicht mit der größten Niederlassung, sondern mit wiederkehrenden Standortmustern. Typische Klassen sind:
- kleine Büros mit Standard-SaaS und wenigen lokalen Diensten,
- Filialen mit Kasse, Druckern oder agentenlosen Geräten,
- Produktions- und Logistikstandorte mit OT-nahen Abhängigkeiten,
- größere Hubs mit lokaler Infrastruktur,
- temporäre Standorte und Pop-up-Flächen,
- Standorte mit regulatorischen oder besonders hohen Verfügbarkeitsanforderungen.
Für jede Klasse werden Anwendungen, Nutzerzahlen, Verfügbarkeitsziel, heutige Leitungen, lokale Security-Komponenten und notwendige Ausnahmen erfasst. Dadurch entsteht eine Rolloutlogik statt einer Sammlung individueller Sonderprojekte.
2. Verkehrswege vor der Zielarchitektur verstehen
Die entscheidende Frage lautet: Welcher Verkehr muss tatsächlich wohin?
Zu prüfen sind Internet- und SaaS-Verkehr, private Anwendungen, DNS, Authentisierung, Managementzugänge, Druck- und Sprachdienste sowie nicht benutzergebundene Systeme. Dazu gehören auch vermeintliche Kleinigkeiten wie IP-Allowlisting, feste Quelladressen oder hart codierte Ziele.
Zscaler Branch Connector kann Standortverkehr zu ZIA und ZPA weiterleiten und wird zentral über das Zscaler-Portal verwaltet. Welche Topologie und Weiterleitungslogik geeignet ist, hängt jedoch vom konkreten Standortprofil ab. Produktfunktion ersetzt deshalb nicht die Architekturprüfung.
3. Das Zielbild pro Anwendung festlegen
Nicht jeder Datenstrom braucht denselben Weg. SaaS und Internet können direkt über einen kontrollierten Security-Service geführt werden. Private Anwendungen benötigen einen definierten ZPA-Pfad. Agentenlose Geräte brauchen eine andere Zuordnung als verwaltete Nutzergeräte. Für verbleibende Legacy-Abhängigkeiten kann zeitweise ein Übergangspfad nötig sein.
Für jeden relevanten Anwendungsweg sollten feststehen:
- fachlicher und technischer Owner,
- gewünschter Zielpfad,
- Identitäts- und Gerätekontext,
- Sicherheitskontrollen,
- Verfügbarkeitsanforderung,
- Testfall und Rückfalloption,
- Termin zum Abbau des Altpfads.
So wird verhindert, dass „temporäre“ Ausnahmen dauerhaft Teil der Architektur bleiben.
Mikrosegmentierung als zusätzlicher Wert der Branch-Transformation
In vielen klassischen Standortarchitekturen soll Mikrosegmentierung über weitere VLANs, Firewall-Zonen oder Access-Listen erreicht werden. Das Ziel ist richtig: Ein Gerät soll nicht automatisch alle anderen Systeme im Standortnetz erreichen. Der Ansatz wird aber oft nicht bis zur gewünschten Granularität umgesetzt, weil jedes neue Segment Routing, Regelpflege, Dokumentation und Fehlersuche erweitert.
Zscaler beschreibt für Branch Connector eine Architektur, die East-West-Segmentierung ermöglicht und laterale Bewegung begrenzen kann. Der grundlegende Unterschied: Zugriff wird auf benötigte Anwendungen und Ziele ausgerichtet, nicht auf die pauschale Erreichbarkeit eines ganzen Netzes.
Zusätzliche Granularität entsteht, wenn Geräte oder Quellen im Standortdesign als einzelne Hostadressen behandelt werden. Eine einzelne IPv4-Adresse entspricht einem `/32`-Präfix. Statt beispielsweise ein gesamtes `/24` als gemeinsame Policy-Einheit zu betrachten, kann eine `/32`-Quelle einer eng definierten Zielbeziehung zugeordnet werden. Mikrosegmentierung wird damit nicht zwingend zu einem separaten Infrastrukturprojekt, sondern kann als Architekturgewinn der Branch-Modernisierung mit umgesetzt werden.
Das ist kein Automatismus und keine pauschale „Gratisfunktion“. Erforderlich sind:
- eine eindeutige und belastbare Geräte-zu-IP-Zuordnung,
- ein kontrolliertes DHCP- oder Adressierungskonzept,
- definierte Zielanwendungen, Ports und Protokolle,
- passende ZIA-, ZPA- und Branch-Policies,
- eine bewusste Behandlung von DNS, Updates und gemeinsamer Infrastruktur,
- negative Tests für nicht erlaubte Querkommunikation,
- Monitoring, Owner und Review-Datum für Ausnahmen.
Ob Geräte im konkreten Zscaler-Branch-Design standardmäßig oder bewusst als `/32` modelliert werden, muss gegen Plattformstand, Adressvergabe und Zielarchitektur geprüft werden. Der belastbare Claim lautet daher: Branch Connector schafft die technische Grundlage für feinere East-West-Segmentierung; ein hostgenaues `/32`-Policy-Modell kann daraus echte Mikrosegmentierung im Standort machen.
4. Mit einem repräsentativen Standort pilotieren
Der bequemste Standort ist selten der beste Pilot. Geeignet ist ein Standort, der typische Anwendungen und mindestens eine reale Schwierigkeit enthält, aber beherrschbar bleibt.
Der Pilot prüft nicht nur Erreichbarkeit. Er misst auch:
- Verhalten bei Ausfall eines Zugangswegs,
- Zeit bis zur Fehlerlokalisierung,
- Transparenz im Monitoring,
- Umgang mit nicht verwalteten Geräten,
- Anwendungsperformance,
- Helpdesk- und Eskalationsabläufe,
- Wiederholbarkeit der Konfiguration.
Zscaler dokumentiert für Branch Connector sowohl Konfigurationsschritte als auch Monitoring-Ansichten. Diese Informationen sind eine technische Grundlage; Abnahmekriterien und Betriebsübergabe bleiben projektspezifische Aufgaben.
5. Parallelbetrieb mit klarer Exit-Regel
Ein begrenzter Parallelbetrieb kann Risiken senken. Er braucht aber eine klare Exit-Regel: Welche Tests müssen bestanden sein? Welche Anwendung darf noch über den Altpfad laufen? Wer entscheidet über die Abschaltung? Wann wird eine Ausnahme erneut bewertet?
Ohne diese Regeln entstehen doppelte Kosten und unklare Zuständigkeiten. Mit ihnen wird der Parallelbetrieb zu einem kontrollierten Migrationsinstrument.
6. Kosten nicht mit Anbieterpreisen verwechseln
Ein belastbarer Business Case trennt heutige und künftige Kostenblöcke. Dazu gehören Leitungen, lokale Appliances, Lizenzen, Betrieb, Störungen, Rollout und einmalige Migration. Angebots- und Lizenzpreise müssen aus aktuellen, kundenspezifischen Unterlagen stammen.
Der SourcingBlox Rechner für MPLS und Zero Trust Branch verwendet deshalb ausschließlich veränderbare Annahmen. Er liefert keine Preisbehauptung, sondern macht sichtbar, welche Eingaben die eigene Wirtschaftlichkeitsbetrachtung bestimmen.
7. Betrieb vor dem Rollout standardisieren
Vor einer größeren Welle müssen Rollen, Monitoring, Störungsannahme, Eskalation, Change-Prozess und Dokumentation stehen. Eine technische Lösung ist erst dann skalierbar, wenn ein weiterer Standort nach demselben Muster aufgenommen und betrieben werden kann.
SourcingBlox verbindet dafür Discovery, Standortklassifizierung, Zscaler-Architektur, Pilot und Betriebsübergabe. Das Ergebnis ist kein pauschales Abschaltversprechen, sondern eine priorisierte Migrationssequenz mit nachvollziehbaren Entscheidungen.
Ein konkretes Beispiel: die Filiale mit drei Verkehrsarten
Nehmen wir eine Filiale mit Büroarbeitsplätzen, Kassensystemen und Gebäudetechnik. Heute läuft nahezu alles über MPLS zum Rechenzentrum. Im Zielbild werden die Wege getrennt betrachtet.
Browser- und SaaS-Verkehr der Mitarbeitenden kann über einen lokalen Internetzugang und ZIA geführt werden. Der Zugriff auf private Anwendungen folgt einem definierten ZPA-Pfad. Kasse und Gebäudetechnik erhalten eigene, eng begrenzte Kommunikationsbeziehungen. DNS, Zeitsynchronisation, Updates und zentrale Managementsysteme werden ausdrücklich mit erfasst.
Die Migration erfolgt nicht als gemeinsamer Umschaltmoment. Zuerst wird die neue Konnektivität aufgebaut und überwacht. Danach wechseln ausgewählte Verkehrsklassen mit dokumentiertem Test und Rückfallweg. Erst wenn die repräsentativen Geschäftsprozesse abgenommen sind, kann der alte Pfad entfallen.
Dieses Muster macht zwei Dinge sichtbar: Erstens ist „der Standort“ keine einzelne Verbindung. Zweitens entsteht der Nutzen aus der Kombination aus direkterem Zugriff, klarerer Segmentierung und wiederholbarem Betrieb – nicht allein aus einer günstigeren Leitung.
Welche Unterlagen vor einer Entscheidung vorliegen sollten
Ein belastbarer Entscheidungsstand besteht mindestens aus:
- Standortinventar mit Klassen und Prioritäten,
- Anwendungs- und Datenflussmatrix,
- Zieltopologie je Standortklasse,
- dokumentierten Legacy-Abhängigkeiten,
- Pilotdesign mit Abnahme- und Rückfallkriterien,
- Rolloutwellen und Change-Fenstern,
- Betriebs- und Eskalationsmodell,
- Kostenmodell mit Quelle und Datum jeder Annahme.
Der Rechner ist dabei nur ein Baustein. Er kann zeigen, welche Variablen wirtschaftlich entscheidend sind. Er kann nicht beurteilen, ob ein Produktionssystem eine feste Quelladresse braucht, ob ein Carrier die geforderte Verfügbarkeit erreicht oder ob eine Anwendung im Zielpfad korrekt funktioniert.
Messpunkte nach der ersten Rolloutwelle
Nach der ersten Welle sollten Architektur- und Wirtschaftlichkeitsannahmen überprüft werden. Relevante Messpunkte sind unter anderem Rolloutdauer pro Standort, Zahl ungeplanter Ausnahmen, Störungsvolumen, Zeit bis zur Diagnose, Anwendungsqualität und tatsächlich entfallene Altkomponenten.
Abweichungen sind kein Beweis für ein gescheitertes Konzept. Sie liefern die Daten, mit denen Standortklassen, Templates und Betriebsabläufe vor der nächsten Welle verbessert werden.