Von MPLS zu SD-WAN: Checkliste für eine saubere Migration
T-Shirt-Größen für Standorte, Standardisierung und Provider-Wahl mit Blick aufs Peering: die Checkliste für den Wechsel von MPLS zu SD-WAN.
Viele MPLS-Verträge stammen aus einer Zeit, in der Anwendungen im eigenen Rechenzentrum liefen und Standorte vor allem untereinander sprechen mussten. Heute geht der Großteil des Verkehrs in die Cloud, und jede Vertragsverlängerung wirft dieselbe Frage auf: Warum so viel Geld für Leitungen, die den Verkehr erst durchs halbe Land zum zentralen Breakout schleppen?
Der Wechsel zu SD-WAN beantwortet diese Frage, aber nur, wenn die Migration sauber geplant ist. Aus unseren Projekten, vom Mittelständler bis zum Rollout über mehr als 250 Standorte, hat sich eine Reihenfolge bewährt, die wir hier als Checkliste teilen.
Erst sortieren: Standorte in T-Shirt-Größen denken
Der häufigste Planungsfehler ist, jeden Standort als Einzelfall zu behandeln. Wer 40, 100 oder 300 Lokationen einzeln plant, produziert 300 Sonderlösungen, und managt sie danach auch so.
Der bessere Weg: Standorte nach Anforderungen gruppieren und in Größenklassen einteilen, wie bei T-Shirts. Ein Beispielraster:
- S – kleine Büros, Pop-up-Flächen, Baustellen: eine Internetleitung plus Mobilfunk (5G/LTE), kompakte Hardware, Standard-Bandbreite.
- M – Standardbüros: zwei Leitungen unterschiedlicher Provider, aktive Redundanz, mittlere Bandbreitenklasse.
- L – Hauptstandorte, Produktion, Logistik: zwei getrennt geführte Leitungen plus Mobilfunk als dritter Weg, hohe Bandbreiten, erweiterte Anforderungen an Verfügbarkeit.
Wo die Grenzen zwischen S, M und L verlaufen, ist unternehmensspezifisch: nach Nutzerzahl, kritischen Anwendungen oder Umsatzrelevanz. Entscheidend ist, dass es wenige Klassen gibt und jede neue Lokation einer davon zugeordnet wird.
Templates statt Einzelkunstwerke
Pro Größe entsteht genau ein Template: Hardware-Modell, Bandbreitenklasse, Redundanzmuster, QoS- und Security-Richtlinien, Konfigurationsbausteine, Dokumentation. Ein neuer Standort bedeutet dann nicht Planung von null, sondern: Größe wählen, Template ausrollen.
Diese Standardisierung zahlt sich mehrfach aus. Rollouts werden schneller, weil die Konfiguration aus der Vorlage kommt statt aus Handarbeit. Die Fehlerquote sinkt, weil Abweichungen sofort auffallen. Das laufende Management wird planbar, weil sich Störungsbilder über gleichartige Standorte hinweg wiederholen. Und die Ersatzteilhaltung schrumpft auf wenige Gerätetypen zusammen.
Ausnahmen wird es immer geben, eine Produktionshalle mit OT-Anbindung folgt anderen Regeln als ein Vertriebsbüro. Der Punkt ist: Ausnahmen sind bewusste, dokumentierte Abweichungen vom Template, nicht der Normalfall.
Leitungen anbinden: Redundanz endet nicht am Hausanschluss
Zwei Leitungen am Standort klingen nach Redundanz, sind es aber nicht automatisch. Kommen beide vom selben Provider, teilen sie sich häufig Technik, Trasse oder Hausführung, und fallen gemeinsam aus. Deshalb gehören an redundante Standorte Leitungen unterschiedlicher Provider.
Und selbst das reicht noch nicht ganz. Der oft übersehene Punkt ist das Peering : Auch getrennte Provider tauschen ihren Verkehr an denselben Internetknoten aus. Hat das Peering eines Providers dort ein Problem, etwa eine Störung am Knoten, überlastete Ports oder ein Routing-Fehler, dann hilft die zweite Leitung nur, wenn ihr Verkehr tatsächlich andere Wege nimmt: anderes Peering, andere Upstreams, andere AS-Pfade. Zwei Leitungen, deren Verkehr am Ende über denselben Austauschpunkt läuft, sind auf dieser Ebene eine einzige.
Bei der Provider-Auswahl lohnt sich deshalb neben Preis und Bandbreite ein Blick darauf, wie die Anbieter ans Internet angebunden sind. Mit ASKAEMI, unserem eigenen Autonomous System (AS 51834), sehen wir Peering-Störungen direkt in den Routing-Daten, und genau dieses Wissen fließt in die Leitungsauswahl je Standort ein. Mobilfunk (5G/LTE) ergänzt das Bild als dritter, technologisch getrennter Weg, der weder Trasse noch Knoten mit den Festnetzleitungen teilt.
Sicherheit von Anfang an mitdenken
Mit SD-WAN wandert der Internet-Breakout an die Standorte, der Verkehr läuft nicht mehr komplett durch die zentrale Firewall im Rechenzentrum. Das ist gewollt (kürzere Wege, bessere Cloud-Performance), verlangt aber ein Sicherheitsmodell, das mitzieht: SASE/SSE verlagert Prüfung und Richtlinien in die Cloud, nah an Nutzer und Standorte. Wer das erst nach der Migration angeht, baut doppelt.
In Wellen migrieren, nicht im Big Bang
Der Rollout startet mit einer Pilotwelle aus kleinen Standorten der Größe S. Dort zeigt sich, ob Templates, Logistik und Umschaltprozesse funktionieren, mit überschaubarem Risiko. Die Erkenntnisse fließen zurück ins Template, dann folgen die weiteren Wellen nach Größenklassen.
Je Standort gilt: Parallelbetrieb von MPLS und SD-WAN, bis die neue Anbindung nachweislich stabil läuft, mit definiertem Rollback-Pfad. Und die MPLS-Kündigungsfristen werden von hinten terminiert, damit keine Doppelzahlung länger läuft als nötig.
Nach dem Rollout: managen, messen, optimieren
Mit dem letzten migrierten Standort beginnt die eigentliche Arbeit. Dazu gehören Monitoring je Leitung, gepflegte Templates und vor allem das Provider-Management: Störungen erkennen, beim richtigen Anbieter melden, Entstörung treiben und eskalieren, wenn es hakt. Wer viele Standorte mit jeweils mehreren Providern hat, unterschätzt diesen Aufwand leicht. Wie das in der Praxis über mehr als 250 Standorte aussieht, zeigt unser Praxisbeispiel aus der Industrie .
Die Checkliste kompakt
- Standorte inventarisieren und in Größenklassen (S/M/L) einteilen
- Pro Größe ein Template definieren: Hardware, Bandbreite, Redundanz, Richtlinien
- Anwendungen und Abhängigkeiten je Standortklasse klären
- Provider je Standort diversifizieren, inklusive Blick auf Peering, Upstreams und AS-Pfade
- Mobilfunk (5G/LTE) als dritten, getrennten Weg einplanen
- SASE/SSE-Architektur vor der Migration festlegen
- Pilotwelle mit kleinen Standorten fahren und Templates nachschärfen
- Parallelbetrieb und Rollback je Standort vorsehen
- MPLS-Kündigungsfristen rückwärts terminieren
- Management nach dem Rollout klären: Monitoring, Provider-Eskalation, Template-Pflege
Der Wechsel von MPLS zu SD-WAN ist weniger ein Technikprojekt als eine Abfolge von Standardisierungsentscheidungen. Wer in Templates und Größenklassen denkt und bei der Leitungswahl bis zum Peering hinschaut, bekommt ein Netz, das schneller ausgerollt ist, seltener ausfällt und sich dauerhaft managen lässt.
