Alcatel-Lucent OmniPCX zu Microsoft Teams migrieren

Es gibt zwei Sorten von TK-Projekten. Die einen starten, weil jemand eine Vision hat. Die anderen starten, weil ein Wartungsvertrag ausläuft und der Vertrieb deines Systemhauses plötzlich sehr freundlich anruft. Wenn du hier gelandet bist, gehörst du vermutlich zur zweiten Sorte: Die OmniPCX Enterprise läuft seit Jahren stabil im Technikraum, niemand fasst sie an, und genau deshalb weiß auch niemand mehr, was eigentlich alles daran hängt.

Die gute Nachricht zuerst: Die Ablösung einer OmniPCX durch Microsoft Teams Phone ist kein Forschungsprojekt. Der Weg ist erprobt, die Schnittstellen sind offen, und die Endgeräte, die du vielleicht behalten willst, sind unter Umständen sogar direkt unterstützt. Die schlechte Nachricht: Die Technik ist selten das Problem. Über den Erfolg entscheiden die Bestandsaufnahme, der Trunk-Vertrag und die Frage, wie lange du bereit bist, zwei Telefonanlagen gleichzeitig zu bezahlen.

Dieser Beitrag gehört zu unserer Serie Teams-Telefonie. Dort findest du das große Bild: Lizenzen, Architektur, Betriebsmodelle. Hier geht es konkret um den Weg von der OmniPCX Enterprise zu Teams Phone – von der ersten Inventur bis zu dem Tag, an dem du der alten Anlage den Strom abdrehst. Wenn du für die Entscheidung eine zweite Meinung willst, findest du sie auf unserer Seite zur Teams-Telefonie-Beratung.

FAKTEN Microsoft bietet vier Wege ans Telefonnetz an: Microsoft Teams Calling Plan, Operator Connect, Teams Phone Mobile und Direct Routing. Sie schließen sich nicht aus – du darfst mehrere davon parallel im selben Tenant betreiben. Direct Routing setzt einen von Microsoft zertifizierten Session Border Controller voraus. Nicht zertifizierte Geräte darf Microsoft im Supportfall ablehnen. Der Teams SIP Gateway unterstützt unter anderem Alcatel-Lucent-Enterprise-DeskPhones der Serien M3, M5, M7, M8 sowie die s-Varianten. Deine Tischtelefone müssen also nicht zwangsläufig in den Elektroschrott.

 

1. Bestandsaufnahme: Was wirklich an der OmniPCX hängt

Jedes Migrationsprojekt, das schiefgeht, geht an derselben Stelle schief: Jemand hat die Anlage anhand der Nebenstellenliste geplant. Die Nebenstellenliste ist aber nur die Spitze. Darunter liegt eine über fünfzehn oder zwanzig Jahre gewachsene Konfiguration, in die jede Abteilung irgendwann eine Sonderlocke hat eintragen lassen. Rechne mit vier bis acht Wochen für eine ordentliche Erhebung. Das klingt viel, bis du die Alternative erlebst: eine Abschaltung am Freitagabend und am Montagmorgen einen Aufzugnotruf, der ins Leere läuft.

Abbildung 1: Die sechs Baustellen der Bestandsaufnahme – und in welcher Reihenfolge du sie abarbeitest.

Der Rufnummernplan – und warum die Excel-Tabelle lügt

Fang beim Rufnummernplan an, aber glaube ihm nicht. Exportiere die Konfiguration aus der OmniPCX und ziehe parallel die Verbindungsdatensätze der letzten zwölf Monate. Dann vergleichst du drei Listen: was konfiguriert ist, was benutzt wird und was die Personalabteilung an aktiven Beschäftigten kennt. Die Differenzen sind der eigentliche Projektinhalt.

Durchwahlbereich: Welcher Block gehört wirklich dir, und ist er zusammenhängend? Historisch gewachsene Anlagen haben oft zwei oder drei Blöcke von verschiedenen Anbietern, weil vor zwölf Jahren mal ein Standort dazukam.

Interne Rufnummernlänge: Drei-, vier- oder fünfstellig? Und gibt es Standorte, die sich intern überschneiden und nur über eine Amtskennziffer auseinandergehalten werden?

Nummern ohne Person: Konferenzräume, Faxgeräte, Warteschlangen, Ansagen, Testanschlüsse. Sie brauchen in Teams keine Nutzerlizenz, aber sehr wohl ein Konzept.

Nicht portierbare Nummern: Alles, was an einem Anschluss klebt, den du nicht mitnimmst – etwa Servicerufnummern oder Nummern aus fremden Ortsnetzen.

Kurzwahlen und Sprechwege: Die interne 9 für den Pförtner, die 112 im Hausnetz, die Standortkurzwahl. Nutzer merken sich Ziffern, keine Namen.

Aus dem Abgleich entsteht das wichtigste Dokument des ganzen Projekts: die Migrationstabelle. Eine Zeile pro Rufnummer, mit Zielsystem, Zielobjekt, Welle und Status. Sie ist später die Konfigurationsgrundlage für den SBC, die Checkliste für den Betrieb und der einzige Ort, an dem jemand nachsehen kann, warum ein Anruf dort gelandet ist, wo er gelandet ist. Führe sie an einer Stelle. Nicht in fünf Kopien im Postfach.

Sonderanschlüsse: die Liste, die niemand hat

Hier wird es interessant. An einer klassischen TK-Anlage hängen Geräte, die seit Jahren niemand mehr angefasst hat und die trotzdem funktionieren müssen. In fast jedem Projekt tauchen mindestens drei davon erst auf, wenn man mit einem Analogtester durchs Haus geht oder die Aderpaare im Verteiler zählt. Die Bestandsliste steht selten in einer Datei, sondern in den Köpfen der Haustechnik.

Sonderanschluss	Typisches Problem	Weg in der Teams-Welt
Aufzugsnotruf	Stromversorgung und Erreichbarkeit rechtlich gefordert, oft eigene Leitung	Analogport am SBC oder Analog-Adapter, alternativ dedizierte Mobilfunklösung; separat prüfen
Brandmeldeanlage, Aufschaltung	Übertragungsweg zur Leitstelle, teils vertraglich fixiert	In der Regel nicht über Teams; eigenen Übertragungsweg behalten
Türsprechstelle, Torsprechanlage	Analog oder proprietär, Türöffner per DTMF	SIP-fähige Sprechstelle oder Analog-Adapter; DTMF-Verhalten testen
Fax	Faxdienst über Direct Routing ist heikel, T.38 nicht überall stabil	Nach Möglichkeit auf Faxserver oder Fax-to-Mail umstellen
EC-Terminal, Frankiermaschine	Modemverbindung über Analogleitung	Auf IP-Anbindung umstellen; Modem über VoIP ist kein Plan
Alarmierung, Personenrufanlage	Zeitkritisch, oft mit eigener Logik	Herstellerseitige SIP-Unterstützung prüfen, sonst eigenständig belassen
Betriebsfunk, DECT-Flächenversorgung	Handover, Notrufschleifen, Abdeckung	Teams-tauglich per SIP-Gateway-fähigem DECT-System oder als Insel weiterbetreiben

 

WARNUNG Notruf, Aufzug und Brandmeldeanlage sind keine IT-Themen, die du nebenbei mitmigrierst. Es hängen Prüfpflichten, Versicherungsauflagen und im Zweifel Menschenleben daran. Behandle sie als eigenes Teilprojekt mit eigenem Verantwortlichen, eigenem Test und eigener Abnahme – und plane sie zeitlich VOR der Abschaltung, nicht danach. Wer diese Punkte auf die Restliste schiebt, findet sie am Abschalttag wieder.

 

Vermittlungsplätze und die Frage, was Vermitteln eigentlich heißt

Der Vermittlungsplatz ist der Punkt, an dem die meisten Migrationen emotional werden. In der OmniPCX sitzt jemand an einem Arbeitsplatz mit Belegtlampenfeld, sieht auf einen Blick, wer telefoniert, wer im Haus ist und wer sich abgemeldet hat, und vermittelt in unter drei Sekunden. Teams kann das in dieser Form nicht ab Werk. Teams kann Anrufwarteschlangen, automatische Telefonzentralen, Delegierung und Anwesenheitsinformationen – aber die Bedienlogik ist eine andere.

Kläre also früh und ehrlich, was die Vermittlung tatsächlich tut. In vielen Organisationen ist der Vermittlungsplatz längst ein Empfangstresen, der zwanzig Anrufe am Tag durchstellt – dafür reicht Teams mit einer Warteschlange und einer sauber gepflegten Verzeichnisstruktur. In anderen ist er eine Leitstelle mit dreihundert Vermittlungen täglich, Besuchermanagement und Alarmierungsfunktion. Dann brauchst du eine Vermittlungsplatzlösung eines Drittanbieters auf Teams-Basis – und die gehört ins Budget und in den Pilot, nicht in die Nachbesserung.

Funktion der OmniPCX	Teams-Pendant	Bewertung
Nebenstelle mit Durchwahl	Nutzer mit Teams Phone und Rufnummer	Eins zu eins abbildbar
Sammelanschluss, Rufgruppe	Anrufwarteschlange (Call Queue)	Abbildbar, Verteilstrategie neu festlegen
Ansage vor Melden, Zeitsteuerung	Automatische Telefonzentrale (Auto Attendant)	Abbildbar, Feiertagskalender neu pflegen
Chef-Sekretariat-Schaltung	Delegierung mit Stellvertretung	Abbildbar, Bedienung ist anders
Belegtlampenfeld am Vermittlungsplatz	Anwesenheit im Client, Drittanbieterlösung	Nur eingeschränkt; Aufwand realistisch schätzen
Nachtschaltung, Wochenendumleitung	Zeitpläne der Telefonzentrale	Abbildbar, deutlich komfortabler
Gebührenerfassung je Kostenstelle	Anrufanalysen, Drittanbieter-Reporting	Anders gelöst; Anforderung hinterfragen
Direktruftasten, Tastenerweiterung	Kurzwahlen, Anrufgruppen, DeskPhone-Tasten	Teilweise; Endgerätewahl beeinflusst das Ergebnis

 

TIPP Nimm dir zwei Tage und setze dich neben die Vermittlung. Nicht ins Meeting mit der Bereichsleitung – neben die Vermittlung. Was dort in zwei Tagen an Sonderfällen vorbeikommt, steht in keinem Anforderungsdokument, entscheidet aber darüber, ob die Migration am Ende als Fortschritt oder als Zumutung wahrgenommen wird.

 

2. Die Anbindungsentscheidung: Wer liefert dir die Amtsleitung?

Sobald du weißt, was du migrierst, kommt die Frage, wie Teams ans öffentliche Telefonnetz kommt. Microsoft bietet dafür vier Modelle an, und die Auswahl wirkt auf den Folien angenehm übersichtlich. In der Praxis wird sie meistens nicht von der Technik entschieden, sondern von deinem Carrier-Vertrag. Dazu gleich mehr.

Modell	Wer betreibt was	Passt, wenn	Haken
Calling Plan	Microsoft liefert Nummern und Minuten	kleine Standorte, schneller Start	Verfügbarkeit und Tarifmodell prüfen; wenig Einfluss auf Routing
Operator Connect	Carrier betreibt die Technik, Einrichtung im Teams Admin Center	du willst wenig Betriebsaufwand	nur mit teilnehmenden Anbietern; kein eigenes Routing, keine PBX-Koexistenz
Teams Phone Mobile	Mobilfunkanbieter, Mobilnummer wird Teams-Nummer	stark mobile Belegschaft	keine Nummern für Warteschlangen und Telefonzentralen
Direct Routing	du oder dein Partner betreibt den SBC	Koexistenz, Sondergeräte, eigenes Routing	Betriebsverantwortung, Zertifikate, Monitoring liegen bei dir

 

Und ja, du darfst mischen. Microsoft beschreibt das ausdrücklich als gängiges Muster: Operator Connect für die Büroarbeitsplätze, Direct Routing für die Anbindung der alten Anlage, für Analoggeräte und für Sonderrouting. Genau diese Mischung ist während einer OmniPCX-Ablösung meist die realistische Antwort.

Abbildung 2: Die Anbindungsentscheidung in zwei Weichen – die erste stellt dein Carrier-Vertrag, nicht deine Architektur.

Der Klassiker: Der Trunk-Vertrag läuft noch drei Jahre

Das ist die Situation, die in ALE-Bestandsprojekten am häufigsten auftritt und die in keiner Herstellerpräsentation vorkommt. Der Wartungsvertrag für die OmniPCX läuft aus, das ist der Auslöser für das Projekt. Der SIP-Trunk-Vertrag dagegen wurde vor zwei Jahren für fünf Jahre verlängert, weil das damals günstiger war. Damit hast du dein Zielbild nicht mehr frei gewählt: Wenn dein Anbieter kein Operator Connect anbietet, bleibt dir Direct Routing – oder du zahlst dich aus dem Vertrag frei.

WARNUNG Prüfe den Trunk-Vertrag, bevor du die Architektur entscheidest, nicht danach. Konkret zu klären: Restlaufzeit und Kündigungsfrist, ob der Anbieter am Operator-Connect-Programm teilnimmt, ob eine Teilkündigung einzelner Kanäle möglich ist, wie die Kosten bei sinkender Kanalzahl aussehen und wie lange eine Portierung des Rufnummernblocks dauert. Der unangenehme Fall: Der Vertrag läuft noch Jahre, der Anbieter bietet kein Operator Connect an, und eine vorzeitige Ablösung kostet mehr als der SBC. Dann hat faktisch dein Carrier über deine Teams-Architektur entschieden. Das ist kein Drama – Direct Routing ist ein sauberer Weg. Es ist nur schlecht, das erst nach der Designphase zu merken.

 

Wenn Direct Routing: SBC auswählen und betreiben

Direct Routing ist in Ablöseprojekten ohnehin oft gesetzt, weil du für die Koexistenz einen Punkt brauchst, an dem OmniPCX, Teams und Carrier zusammenlaufen. Genau das ist die Aufgabe des Session Border Controllers. Er ist während der Migration nicht nur Sicherheitskomponente, sondern die zentrale Weiche: Er entscheidet je Rufnummer, ob ein Anruf in die alte oder die neue Welt geht.

FAKTEN Voraussetzungen für Direct Routing laut Microsoft: ein zertifizierter SBC, ein vollqualifizierter Name des SBC aus einer in deinem Microsoft-365-Tenant verifizierten Domäne (die Standarddomäne onmicrosoft.com geht nicht), ein öffentliches Zertifikat einer vertrauenswürdigen Zertifizierungsstelle, eine öffentliche IP-Adresse und ein DNS-Eintrag. Signalisierung läuft per SIP über TLS zu sip.pstnhub.microsoft.com, sip2 und sip3 als Ausweichpunkte; Zielport 5061. Medien laufen über die Microsoft-Medienprozessoren, sofern du Media Bypass nicht aktivierst. Microsoft empfiehlt, auf dem SBC mindestens zwei Medienports je gleichzeitigem Gespräch einzuplanen. Unterstützte Codecs zwischen Teams und SBC sind SILK, G.711, G.722 und G.729. Die Zertifizierung gilt jeweils für konkrete Firmwarestände. Höhere Versionen mit gleicher Haupt- und Nebenversion sind abgedeckt – die Liste der zertifizierten Geräte gehört trotzdem vor jede Beschaffung auf den Tisch.

 

Bei der Auswahl geht es weniger um Datenblätter als um die Frage, wer das Ding betreibt. Ein SBC ist kein Gerät, das man einmal einrichtet und dann vergisst: Zertifikate laufen ab, Firmware will gepflegt werden, und wenn im Sommer plötzlich jeder zweite Anruf einseitig stumm ist, brauchst du jemanden, der ein SIP-Trace lesen kann. Entscheide vor dem Kauf, ob du das selbst machst, ob es dein Partner übernimmt oder ob du es als Dienstleistung einkaufst.

Wir betreiben unseren eigenen anynode-SBC von TE-SYSTEMS mit Direct Routing und easybell-Trunks im täglichen Einsatz – nicht als Laboraufbau, sondern als Telefonanlage des eigenen Hauses. Das ist der Grund, warum wir bei der Frage nach dem Betriebsaufwand nicht schätzen müssen. anynode ist in der Microsoft-Liste der für Direct Routing zertifizierten SBC geführt, ebenso wie die Geräte von AudioCodes, Ribbon, Oracle, Cisco und anderen. Für die Anbindung einer OmniPCX ist wichtig, dass der SBC gleichzeitig zum Carrier, zu Teams und zur alten Anlage sprechen kann – das können die genannten Kandidaten, unterscheiden sich aber deutlich in Lizenzmodell, Bedienung und Betriebsaufwand.

TIPP Lass dir vom Anbieter des SBC eine Konfiguration zeigen, in der beide Trunks parallel laufen – zur OmniPCX und zu Teams –, bevor du bestellst. Wenn dabei die Antwort kommt, das sei alles kein Problem, frag nach dem Interoperabilitätsbericht für die OmniPCX Enterprise. Es gibt sie. Wer sie nicht kennt, hat den Aufbau noch nicht gemacht.

 

3. Koexistenz: Wenn OmniPCX und Teams sich das Haus teilen

Ein Big Bang ist bei einer gewachsenen TK-Anlage in den seltensten Fällen vernünftig. Alles, was mehr als etwa hundert Nebenstellen hat, migrierst du in Wellen – und das bedeutet zwangsläufig eine Phase, in der beide Systeme parallel laufen und eingehende Rufe auf beide verteilt werden. Diese Phase ist technisch beherrschbar, organisatorisch anstrengend und finanziell unangenehm, weil du in dieser Zeit zweimal Betrieb bezahlst.

Abbildung 3: Zielbild der Koexistenz – der SBC hängt zwischen Carrier, alter Anlage und Teams.

Wer ist der Ankerpunkt für eingehende Rufe?

Das ist die zentrale Designentscheidung der Koexistenzphase, und sie kennt genau zwei saubere Antworten. Entweder kommt der Amtsverkehr weiterhin an der OmniPCX an und die Anlage leitet migrierte Nebenstellen an Teams weiter. Oder der Trunk wandert an den SBC, und der SBC verteilt anhand der Migrationstabelle. Alles dazwischen – zwei Trunks, geteilte Nummernblöcke, jeder macht ein bisschen – endet in Anrufen, die niemand mehr nachvollziehen kann.

Modell	Vorteil	Nachteil	Empfehlung
Anker bleibt OmniPCX	kein Eingriff in den Trunk, schneller Start	alte Anlage bleibt bis zuletzt kritisch; Umleitung belegt zwei Kanäle je Ruf	für kurze Koexistenz und kleine Umgebungen
Anker wird der SBC	alte Anlage kann früh entlastet werden, saubere Steuerung je Rufnummer	Umstellung des Trunks als eigener Meilenstein, Portierungsfenster nötig	Regelfall bei mittleren und großen Migrationen
Zwei getrennte Trunks	vermeintlich einfach, keine Kopplung nötig	Rufnummern müssen gesplittet werden, Portierung wird zum Dauerthema	nur bei echten Standortsplits sinnvoll

 

In den meisten Projekten ist die zweite Variante die richtige: Der SIP-Trunk wandert früh an den SBC, die OmniPCX bekommt vom SBC einen SIP-Trunk gestellt und merkt vom Rest der Welt nichts. Ab diesem Moment ist jede weitere Welle eine Änderung in der Migrationstabelle und kein Eingriff mehr in die alte Anlage. Das ist auch politisch angenehm, weil du für jede Welle keinen Wartungstermin des Systemhauses mehr brauchst.

Abbildung 4: Ein eingehender Ruf in der Koexistenzphase – die Entscheidung fällt im SBC anhand der Migrationstabelle.

Interne Rufe zwischen beiden Welten

Extern klingelt es – gut. Aber die Belegschaft telefoniert vor allem intern, und genau da wird die Koexistenz unangenehm. Wer in der alten Welt die vierstellige Nebenstelle 4711 wählt, will nicht hören, dass die Kollegin jetzt eine andere Nummer hat. Also musst du die interne Wählbarkeit über die Systemgrenze hinweg erhalten. Praktisch heißt das: Der SBC übersetzt die kurze interne Nummer in ein E.164-Format und wieder zurück, in beide Richtungen, für jede migrierte Nebenstelle.

Nummernnormalisierung sauber definieren: Was passiert mit vierstelligen internen Nummern, was mit Kurzwahlen, was mit der Amtskennziffer 0, die es in Teams so nicht gibt?

Anrufer-Anzeige prüfen: In der Koexistenz kommt die Rufnummer je nach Weg unterschiedlich an. Wenn intern plötzlich die volle Amtsnummer im Display steht, ist das kein Fehler, aber ein Beschwerdegrund.

Rückwärtsrichtung nicht vergessen: Der Weg von Teams zur OmniPCX wird gerne getestet. Der Weg von einem alten Systemapparat zu einem migrierten Teams-Nutzer seltener – und genau da fehlt dann eine Regel.

Weiterleitung und Rückfrage: Ein Ruf, der von außen kommt, in Teams landet, dorthin weitergeleitet und dann zurück an die alte Anlage vermittelt wird, läuft dreimal über den Trunk. Kanalbedarf und Gesprächsqualität entsprechend einplanen.

WICHTIG Plane die Kanalzahl auf dem Trunk für die Koexistenzphase großzügiger als für den Endzustand. Jeder Ruf, der zwischen den Welten weitergereicht wird, belegt zwei Kanäle statt einem. Wer hier auf die spätere Zielgröße optimiert, produziert im dritten Monat der Migration Besetztzeichen – und zwar genau dann, wenn alle hinschauen.

 

Die Koexistenz hat ein Verfallsdatum

Schreib das Abschaltdatum in den Projektauftrag, bevor die erste Welle startet. Ohne festes Datum passiert Folgendes: Die ersten achtzig Prozent migrieren zügig, dann kommen die Sonderfälle, dann kommt der Sommer, dann meldet eine Abteilung grundsätzliche Bedenken an – und drei Jahre später betreibst du immer noch beide Systeme, bezahlst zwei Wartungen und hast in beiden Welten halbgare Prozesse. Ein Koexistenzfenster von drei bis sechs Monaten ist in mittelgroßen Umgebungen realistisch. Alles jenseits eines Jahres ist kein Migrationsprojekt mehr, sondern ein Dauerzustand mit Projektnamen.

4. Migration in Wellen: der Plan, der auch bei Gegenwind hält

Abbildung 5: Typischer Ablauf einer OmniPCX-Ablösung mit Koexistenzfenster.

Pilot: klein, laut und repräsentativ

Der Pilot ist nicht dazu da, die Technik zu beweisen – die funktioniert im Labor sowieso. Er ist dazu da, die Sonderfälle zu finden. Nimm zwanzig bis vierzig Personen und stelle sie bewusst quer zusammen: jemanden aus der Vermittlung, jemanden aus dem Vertrieb mit ständiger Rufumleitung aufs Mobiltelefon, jemanden aus der Buchhaltung mit Sammelanschluss, jemanden aus der Geschäftsführung mit Sekretariatsschaltung und unbedingt jemanden aus der Produktion oder der Lagerlogistik mit DECT-Gerät.

Nimm ausdrücklich auch die zwei Menschen mit, von denen alle sagen, mit denen werde es schwierig. Wenn deren Anforderungen im Pilot gelöst sind, hast du die Argumente für die restlichen Wellen. Wenn nicht, weißt du es früh genug, um zu reagieren – und nicht erst, wenn dreihundert Leute umgestellt sind.

Wellenschnitt: nach Organisation, nicht nach Etage

Der häufigste Planungsfehler ist der Schnitt nach Gebäudeteilen, weil das für die Verkabelung praktisch ist. Für die Anwender ist es das Gegenteil: Ein Team, das über zwei Etagen verteilt sitzt, telefoniert dann wochenlang über die Systemgrenze. Schneide nach Organisationseinheit – wer viel miteinander telefoniert, wandert zusammen. Das reduziert genau die Übergänge, die in der Koexistenz die Probleme machen.

Welle	Wer	Warum diese Reihenfolge
Welle 0 (Pilot)	20 bis 40 Personen, quer geschnitten	Sonderfälle finden, bevor sie Massenphänomen werden
Welle 1	IT und interne Dienste	Wer den Support macht, sollte das System vorher selbst benutzt haben
Welle 2 bis n	Fachbereiche, nach Telefonbeziehung gebündelt	wenig Verkehr über die Systemgrenze, schnelle Erfolge
Vorletzte Welle	Vermittlung und Empfang	erst umstellen, wenn die Zielorganisation im Wesentlichen in Teams ist
Letzte Welle	Sonderanschlüsse und Restposten	brauchen Einzelbetrachtung, blockieren sonst alles andere

 

Was in der Praxis schiefgeht

Aus Projekten mit klassischen TK-Ablösungen wiederholen sich einige Muster so zuverlässig, dass man die Uhr danach stellen kann. Keines davon ist ein technisches Rätsel. Alle kosten Zeit, wenn man sie nicht vorher einplant.

Die vergessene Analogleitung: Irgendwo hängt ein Gerät, das seit 2011 niemand gesehen hat und das genau am Abschalttag gebraucht wird.

Das Zertifikat: Das Zertifikat des SBC läuft ab, weil niemand dafür zuständig war. Symptom: Ab einem Moment geht gar nichts mehr. Setz eine Erinnerung, doppelt.

Die Rufumleitung ins Nirgendwo: Eine Nebenstelle war auf eine Mobilnummer umgeleitet, die Umleitung lebt in der alten Anlage weiter, die Nummer ist migriert. Ergebnis: Schleife oder Stille.

Die Schatten-Nummer: Ein Fachbereich hat auf Visitenkarten eine Durchwahl gedruckt, die in keiner Liste steht, weil sie über eine Sonderkonfiguration lief.

Die Erwartungshaltung: Anwender erwarten, dass der neue Client sich exakt wie der alte Systemapparat verhält. Zehn Minuten Einweisung je Team sparen dir zwei Wochen Ticketaufkommen.

Die Notfallrufnummer: Standortdaten für Notrufe müssen gepflegt sein, bevor der erste Nutzer produktiv geht – nicht danach.

TIPP Führe ab Welle 1 eine Liste mit dem Titel „Funktioniert anders als vorher“ und hänge sie ins Intranet. Nicht als Entschuldigung, sondern als Orientierung. Anwender akzeptieren erstaunlich viel, wenn sie vorher wissen, was sich ändert. Was sie nicht akzeptieren, ist die Antwort „das ist jetzt eben so“ am Telefon.

 

Der Abschalttag und was danach kommt

Die eigentliche Abschaltung ist unspektakulär, wenn die Vorarbeit stimmt: Der letzte SIP-Trunk zur OmniPCX wird deaktiviert, die Migrationstabelle enthält keine Einträge mehr mit Ziel „alt“, fertig. Lass die Anlage danach trotzdem noch zwei bis vier Wochen stromlos, aber unangetastet stehen, bevor sie abgebaut wird. Es kostet nichts und erspart dir die Diskussion, ob in der Konfiguration nicht doch noch etwas stand, das jetzt fehlt.

Und dann kündige die Verträge. Wirklich. In mehr als einem Projekt lief die Wartung für eine längst abgebaute Anlage noch ein volles Jahr weiter, weil die Kündigung niemandem zugeordnet war. Setz den Kündigungstermin am Projektstart in den Plan, mit Namen dahinter.

5. Andere Hersteller, gleiches Muster

Wenn du in einer Unternehmensgruppe unterwegs bist, steht an anderen Standorten vermutlich kein ALE-System, sondern etwas von Unify oder Avaya. Die gute Nachricht: Der Ablauf ist derselbe. Bestandsaufnahme, Anbindungsentscheidung, Koexistenz, Wellen, Abschaltung – das Muster ändert sich nicht, wenn das Typenschild ein anderes ist. Was sich unterscheidet, sind Details bei den Endgeräten, bei den Schnittstellen und beim Ökosystem der verfügbaren Interoperabilitätsberichte.

Thema	Alcatel-Lucent OmniPCX	Unify OpenScape	Avaya
SIP-Trunk zur Anlage	vorhanden, gut dokumentiert	vorhanden	vorhanden
Tischtelefone weiternutzen	M-Serie über Teams SIP Gateway unterstützt	je Modell prüfen	J100-SIP-Serie über SIP Gateway unterstützt
Herstellereigene Teams-Kopplung	Rainbow-Connector für Teams verfügbar	herstellerseitig vorhanden	herstellerseitig vorhanden
Eigener zertifizierter SBC	nein, Drittanbieter nötig	OpenScape SBC ist in der Microsoft-Liste geführt	Avaya SBCE ist in der Microsoft-Liste geführt

 

Wir behandeln die beiden Nachbarfälle in eigenen Beiträgen: Unify OpenScape zu Microsoft Teams migrieren und Avaya zu Microsoft Teams migrieren. Wenn du mehrere Standorte mit unterschiedlichen Anlagen hast, lohnt sich der Blick in alle drei – und dann eine gemeinsame Zielarchitektur statt drei paralleler Einzelprojekte. Den Rahmen dafür beschreibt die Übersicht zur Teams-Telefonie.

WICHTIG Ein Punkt, der bei ALE-Bestandskunden regelmäßig für Verwirrung sorgt: Alcatel-Lucent Enterprise bietet mit dem Rainbow-Connector selbst eine Kopplung an Microsoft Teams an. Das ist eine Integration, keine Migration – die OmniPCX bleibt dabei die Telefonanlage und Teams wird zur Oberfläche. Das kann ein sinnvoller Zwischenschritt sein, wenn die Anlage noch Jahre laufen soll. Es ist aber kein Weg zu Teams Phone, sondern einer daran vorbei. Wenn dein Ziel ist, die TK-Anlage loszuwerden, prüfe genau, welche der beiden Richtungen dir dein Anbieter gerade anbietet.

 

Häufige Fragen

Können wir unsere Rufnummern behalten?

In aller Regel ja. Der Durchwahlblock wird entweder portiert oder bleibt beim bisherigen Anbieter und wird über Direct Routing weiterverwendet – das ist einer der praktischen Vorteile von Direct Routing gegenüber einem Anbieterwechsel. Kläre früh, ob dein Block zusammenhängend ist und ob einzelne Sonderrufnummern von der Portierung ausgenommen sind. Portierungen brauchen Vorlauf; sie sind kein Vorgang für die letzte Projektwoche.

Müssen wir alle Tischtelefone wegwerfen?

Nicht zwangsläufig. Der Teams SIP Gateway unterstützt unter anderem ALE-DeskPhones der Serien M3, M5, M7 und M8 sowie die s-Varianten, jeweils ab einem bestimmten Firmwarestand. Der Funktionsumfang ist dabei kleiner als bei einem zertifizierten Teams-Telefon: Anrufen, Annehmen, Halten, Weiterleiten, Voicemail und Anrufumleitung per Kennziffer. Für Arbeitsplätze, an denen das Telefon vor allem ein Telefon ist, reicht das gut. Für die Vermittlung reicht es nicht.

Direct Routing oder Operator Connect – was ist billiger?

Das lässt sich seriös nur mit deinen Zahlen beantworten, und meistens ist der reine Minutenpreis nicht der entscheidende Posten. Bei Direct Routing zahlst du SBC, Betrieb und Know-how, bekommst dafür Kontrolle über das Routing und die Möglichkeit zur Koexistenz. Bei Operator Connect zahlst du einen Servicepreis und sparst Betriebsaufwand, gibst aber Gestaltungsspielraum ab. Rechne über die gesamte Vertragslaufzeit und nimm die Betriebsstunden ehrlich mit hinein.

Wie lange dauert so ein Projekt insgesamt?

Für eine mittelgroße Organisation mit ein paar hundert Nebenstellen ist ein Gesamtzeitraum von sechs bis zwölf Monaten von der Bestandsaufnahme bis zur Abschaltung realistisch – der größte Anteil davon ist Bestandsaufnahme, Beschaffung und Wellenmigration, nicht Technik. Wer schneller sein muss, weil ein Vertrag endet, kann das Koexistenzfenster verkürzen, zahlt das aber mit mehr Aufwand pro Welle.

Was passiert mit unserem Call-Center?

Das ist der Punkt, an dem viele Migrationen ein zweites Teilprojekt bekommen. Teams bietet Anrufwarteschlangen und automatische Telefonzentralen, und für viele Serviceteams reicht das. Sobald du Skill-basiertes Routing, Wallboards, Aufzeichnung, verbindliche Servicelevel oder eine Kopplung ans CRM brauchst, ist eine Contact-Center-Lösung auf Teams-Basis der richtige Weg. Diese Entscheidung gehört an den Anfang, weil sie die Rufnummernplanung beeinflusst.

Brauchen wir zwingend Media Bypass?

Nein. Ohne Media Bypass laufen die Sprachdaten über die Medienprozessoren von Microsoft, und das funktioniert in den allermeisten Umgebungen gut. Media Bypass kann die Sprachqualität verbessern, wenn Nutzer und SBC am selben Standort sitzen – es erhöht aber die Komplexität. Fang ohne an, miss die Qualität und entscheide dann anhand von Daten statt anhand eines Datenblatts.

Wer kümmert sich im Störungsfall um was?

Bei Direct Routing bist du bei Problemen am SBC zuerst beim SBC-Hersteller: Microsoft erwartet für eine Eskalation einen Untersuchungsbericht des Herstellers und kann Supportfälle mit nicht zertifizierten Geräten ablehnen. Bei Operator Connect liegt die PSTN-Seite beim Anbieter, die Teams-Seite bei Microsoft. Kläre die Zuständigkeiten schriftlich, bevor der erste Ausfall sie für dich klärt.

Was, wenn der Wartungsvertrag schon ausgelaufen ist?

Dann läuft die Anlage weiter, aber ohne Netz. Ersatzteile werden zum Gebrauchtmarkt, Fehleranalyse zur Freundschaftsleistung. Das ist kein Grund zur Panik, aber ein guter Grund, das Koexistenzfenster kurz zu halten und die Bestandsaufnahme trotzdem nicht zu überspringen – gerade dann brauchst du eine vollständige Dokumentation dessen, was die Anlage heute tut.

Fazit

Die Ablösung einer OmniPCX Enterprise durch Microsoft Teams Phone ist ein Handwerksprojekt, kein Abenteuer. Die Reihenfolge entscheidet: erst wissen, was da ist, dann den Carrier-Vertrag lesen, dann die Anbindung festlegen, dann in Wellen migrieren – mit einem Abschalttermin, der von Anfang an im Auftrag steht.

Die drei Punkte, an denen Projekte tatsächlich scheitern, sind unspektakulär: eine unvollständige Bestandsaufnahme der Sonderanschlüsse, ein Trunk-Vertrag, der die Architektur vorgibt und den niemand rechtzeitig gelesen hat, und ein Koexistenzfenster ohne Enddatum. Wer diese drei im Griff hat, hat den Rest im Griff. Die Technik dahinter – zertifizierter SBC, Direct Routing, Nummernnormalisierung – ist erprobtes Handwerk.

Wenn du gerade vor dieser Entscheidung stehst und eine unabhängige Einschätzung zu Architektur, Anbindung und Migrationsplan willst: Wir betreiben Direct Routing mit eigenem anynode-SBC und easybell-Trunks im täglichen Einsatz und begleiten Ablösungen klassischer TK-Anlagen. Mehr dazu auf der Seite zur Teams-Telefonie-Beratung und in der Übersicht zur Teams-Telefonie.

Quellen

Microsoft Learn – PSTN connectivity options: https://learn.microsoft.com/en-us/microsoftteams/pstn-connectivity

Microsoft Learn – Plan Direct Routing: https://learn.microsoft.com/en-us/microsoftteams/direct-routing-plan

Microsoft Learn – Session Border Controllers certified for Direct Routing: https://learn.microsoft.com/en-us/microsoftteams/direct-routing-border-controllers

Microsoft Learn – Plan for Operator Connect: https://learn.microsoft.com/en-us/microsoftteams/operator-connect-plan

Microsoft Learn – Plan SIP Gateway (kompatible Endgeräte): https://learn.microsoft.com/en-us/microsoftteams/devices/sip-gateway-plan

Microsoft Learn – Plan for Shared Calling: https://learn.microsoft.com/en-us/microsoftteams/shared-calling-plan

Microsoft Operator Connect Directory (teilnehmende Anbieter): https://microsoftpartners.microsoft.com/abs/Operator-Directory/

Alcatel-Lucent Enterprise – OmniPCX Enterprise Communication Server: https://www.al-enterprise.com/en/products/platforms/omnipcx-enterprise-communication-server

Alcatel-Lucent Enterprise – Microsoft Teams Integration (Rainbow Connector): https://www.al-enterprise.com/en/products/applications/microsoft-teams-integration

TE-SYSTEMS – anynode und Microsoft Teams: https://www.anynode.de/anynode-and-microsoft-teams/

Alle Quellen abgerufen am 02.09.2026. Preise, Verfügbarkeiten und Zertifizierungsstände ändern sich – vor jeder Beschaffung beim Hersteller und beim Anbieter gegenprüfen.