Unify OpenScape zu Microsoft Teams migrieren

Es gibt Telefonanlagen, die man ablöst, weil sie kaputt sind. Und es gibt Telefonanlagen, die man ablöst, weil man irgendwann keine belastbare Antwort mehr auf die Frage bekommt, wie es weitergeht. OpenScape gehört fast immer in die zweite Kategorie. Die Anlage läuft. Sie läuft sogar ziemlich gut. Sie läuft in vielen Häusern seit über einem Jahrzehnt, mit einer Verfügbarkeit, von der manches Cloud-Produkt nur träumt. Was fehlt, ist nicht Technik, sondern Planungssicherheit.

Wer heute eine OpenScape 4000 oder eine OpenScape Business betreibt, hat in zwanzig Jahren vier Namen auf dem Wartungsvertrag gesehen: Siemens, dann Unify, dann Atos, seit Oktober 2023 Mitel. Und Mitel selbst hat im März 2025 in den USA ein Chapter-11-Verfahren durchlaufen und ist im Juni 2025 unter der Kontrolle seiner früheren Kreditgeber daraus hervorgegangen. Das ist kein Weltuntergang, und es bedeutet ausdrücklich nicht, dass deine Anlage morgen ausgeht. Es bedeutet aber, dass die Frage „Wie lange plane ich hier eigentlich noch auf Sicht?“ berechtigt ist – und dass sie inzwischen auch von Menschen gestellt wird, die sich sonst nie für Telefonie interessiert haben. Zum Beispiel von der Geschäftsführung.

Genau das ist der Migrationstreiber, den wir in Projekten am häufigsten sehen. Nicht ein Defekt. Nicht ein zündendes Feature. Sondern der Wunsch, die Telefonie auf eine Plattform zu stellen, deren Fahrplan man auch in fünf Jahren noch nachlesen kann. Und weil Microsoft 365 in denselben Häusern ohnehin schon läuft, heißt die naheliegende Antwort Microsoft Teams Phone.

Dieser Beitrag gehört zu unserer Serie Teams-Telefonie. Dort findest du das große Bild: Anbindungsvarianten, Lizenzen, Betriebsmodelle, Betrieb im Alltag. Hier geht es konkret um den Weg von OpenScape – und von dem, was davor da war – zu Teams Phone. Von der ersten Inventur bis zu dem Tag, an dem die alte Anlage stromlos im Technikraum steht und niemand sie vermisst. Wenn du für die Entscheidung eine zweite Meinung willst, die dir nichts verkaufen muss: Teams-Telefonie-Beratung.

FAKTEN Microsoft bietet vier Wege ans öffentliche Telefonnetz: Microsoft Teams Calling Plan, Operator Connect, Teams Phone Mobile und Direct Routing. Sie schließen sich nicht aus – du darfst mehrere davon parallel in einem Tenant betreiben, zum Beispiel Operator Connect für die Bürowelt und Direct Routing für Sonderanschlüsse. Direct Routing setzt einen von Microsoft zertifizierten Session Border Controller voraus. Microsoft behält sich vor, Supportfälle mit nicht zertifizierten Geräten abzulehnen. Gute Nachricht für OpenScape-Häuser: Der Unify OpenScape Session Border Controller ist selbst auf der Microsoft-Liste der zertifizierten SBC für Direct Routing zu finden. Du hast unter Umständen also bereits ein zertifiziertes Gerät im Haus – Version und Lizenzumfang aber bitte prüfen. Weniger gute Nachricht: In der Geräteliste des Teams SIP Gateway führt Microsoft Hersteller wie Cisco, Poly, Yealink, AudioCodes, Spectralink, Ascom, Gigaset, Snom, Alcatel-Lucent Enterprise und Avaya auf. Unify beziehungsweise OpenScape steht dort nicht. Deine Tischtelefone bringen dich also nicht automatisch mit.

 

1. Warum gerade jetzt: der Migrationstreiber heißt Unsicherheit

Fangen wir mit dem an, was in keinem Datenblatt steht: mit der Stimmung. In OpenScape-Häusern ist die Telefonie über Jahre unsichtbar geworden. Das ist ein Kompliment an die Plattform – und gleichzeitig das Kernproblem. Denn wenn ein System unsichtbar wird, verschwindet mit ihm auch das Wissen darüber. Der Kollege, der die Anlage aufgebaut hat, ist in Rente. Das Systemhaus wurde zweimal verkauft. Und die Dokumentation ist auf dem Stand von damals, als noch jemand Zeit hatte, Dokumentation zu schreiben.

Skizze 1: Zwanzig Jahre Eigentümerwechsel – und warum das eine Bilanzfrage geworden ist, keine technische.

Was tatsächlich passiert ist – und was daraus folgt

Der Reihe nach, ohne Drama: Aus dem Siemens-Enterprise-Geschäft wurde Unify. Unify ging 2016 an Atos. Im Januar 2023 kündigte Mitel die Übernahme der Unify-Sparte an, am 2. Oktober 2023 war der Kauf abgeschlossen. Am 10. März 2025 hat Mitel Networks in Texas ein Chapter-11-Verfahren eröffnet – betroffen waren die Gesellschaften in den USA und Kanada sowie Teile des britischen Geschäfts. Am 20. Juni 2025 kam das Unternehmen aus dem Verfahren, im Besitz seiner bisherigen Gläubiger statt des früheren Eigentümers Searchlight Capital.

Wichtig für die Einordnung: Ein Chapter-11-Verfahren in den USA ist kein Insolvenzverfahren im deutschen Sinne, sondern ein geordnetes Sanierungsverfahren unter Gläubigerschutz. Mitel hat während des Verfahrens den Geschäftsbetrieb weitergeführt. Und Mitel führt OpenScape ausdrücklich weiter im Portfolio – zur OpenScape 4000 gibt es aktuelle Produktdokumentation zur Version V11, die OpenScape Business wird ebenfalls weiterentwickelt. Wer also behauptet, OpenScape sei tot, verkauft dir gerade etwas.

Nur: Für eine Investitionsentscheidung, die zehn Jahre tragen soll, ist „nicht tot“ ein bemerkenswert schwaches Argument. Und genau an dieser Stelle kippt die Diskussion in der Praxis – weg von der Technik, hin zur Frage, wo das Haus in den nächsten zwei Investitionszyklen stehen will.

WICHTIG Migriere nicht, weil ein Hersteller Schlagzeilen macht. Migriere, weil du eine belastbare Antwort auf drei Fragen brauchst: Wer entwickelt die Plattform in fünf Jahren weiter? Wer kann sie in fünf Jahren noch betreuen? Und was kostet mich der Stillstand, wenn beide Antworten unklar bleiben? Der umgekehrte Fall gilt genauso: Wenn deine OpenScape Business im Mittelstand sauber läuft, der Wartungsvertrag stimmt und niemand nach Cloud-Telefonie ruft – dann ist Abwarten eine legitime Entscheidung. Sie sollte nur bewusst getroffen und mit einem Datum versehen werden, an dem du erneut hinschaust.

 

HiPath: der Altbestand, der nie ganz verschwunden ist

Und dann gibt es die Häuser, in denen gar keine OpenScape steht, sondern immer noch eine HiPath. Man findet sie überraschend häufig: in Produktionsstandorten, in Verwaltungen, in Zweigstellen, die bei der letzten großen Modernisierung vergessen wurden. Das Muster ist immer gleich – die Anlage tut ihren Dienst, also fasst sie niemand an, also steht sie in keinem Projektplan.

Für diese Systeme ist die Lage deutlich eindeutiger als für OpenScape. Die HiPath 3000 ist bereits Mitte der 2010er Jahre aus der Herstellerunterstützung gelaufen. Bei der HiPath 4000 lagen Bestellstopp, Ende der Entwicklungsunterstützung und Bestellstopp für Ersatzteile ebenfalls in der Vergangenheit; ab V7 heißt die Linie OpenScape 4000. Wenn du also noch HiPath fährst, betreibst du ein System, dessen Ersatzteilversorgung faktisch über den Gebrauchtmarkt läuft. Das ist kein Weltuntergang, solange nichts kaputtgeht. Es ist nur eben genau dann ein Problem, wenn es eines wird – und dann ohne Vorwarnzeit.

Plattform im Bestand	Typische Situation 2026	Was das für die Planung heißt
HiPath 3000	Herstellerunterstützung seit Jahren beendet, Ersatzteile über Drittmarkt	Migration nicht mehr aufschieben, Ausfallszenario schriftlich durchspielen
HiPath 4000 (V5/V6)	Nachfolgelinie ist OpenScape 4000; Bestell- und Supportfristen abgelaufen	Entweder Upgrade auf eine gestützte Version oder direkt der Wechsel nach Teams
OpenScape 4000	Aktive Produktlinie bei Mitel, Dokumentation bis V11 verfügbar	Zeitfenster für eine geordnete Migration vorhanden – nutzen statt sitzen
OpenScape Business	Weiterhin gepflegt, typischer Mittelstands-Bestand	Migration nach Nutzen entscheiden, nicht nach Panik; Termin zum Nachschauen setzen
OpenScape Voice / UC	Weiter im Mitel-Portfolio, teils mit veränderten Anwendungen darum herum	Anwendungslandschaft einzeln prüfen – hier hängt oft mehr dran als gedacht
Unify Circuit	Von Mitel eingestellt	Falls noch im Einsatz: Ersatz ist längst überfällig, Teams deckt den Fall ab

 

WARNUNG Der gefährlichste Satz in HiPath-Projekten lautet: „Das läuft doch.“ Er stimmt – bis zum Netzteil, zur Baugruppe oder zum Klimaausfall im Technikraum. Frag einmal konkret nach: Wie lange dauert die Wiederbeschaffung einer defekten Baugruppe? Wer im Haus kann sie tauschen? Und gibt es ein aktuelles, eingespieltes Backup der Anlagenkonfiguration – nicht nur eines, das theoretisch existiert? Wenn auf drei Fragen dreimal Schulterzucken kommt, hast du kein Telefonieprojekt, sondern ein Risiko in der Bilanz.

 

2. Bestandsaufnahme: Was wirklich an der OpenScape hängt

Jetzt zum unspektakulären Teil, der über Erfolg oder Chaos entscheidet. Eine TK-Migration scheitert praktisch nie am SIP-Protokoll. Sie scheitert an dem Anschluss, den niemand auf dem Zettel hatte. Plane für die Inventur mehr Zeit ein, als dir lieb ist – und rechne damit, dass du sie brauchst.

Der Rufnummernplan und die Wahrheit über die Excel-Tabelle

Es gibt immer eine Liste. Sie liegt auf einem Laufwerk, heißt „Rufnummern_final_v3_NEU.xlsx“ und wurde zuletzt geändert, als die letzte Erweiterung eingebaut wurde. Diese Liste ist nicht deine Datenbasis, sie ist bestenfalls ein Hinweis. Deine Datenbasis ist die Anlage selbst.

Zieh den Rufnummernbestand aus der Anlage, nicht aus der Tabelle. Vergleiche anschließend beide – die Differenz ist der interessante Teil.

Gleiche gegen das Verzeichnis ab: Welche Nummer gehört zu einem aktiven Konto in Entra ID? Welche gehört zu einer Person, die vor zwei Jahren gegangen ist?

Trenne Personenrufnummern von Funktionsrufnummern. Die Zentrale, die Poststelle, die Störungsannahme, die Rufnummer auf dem Briefpapier – das sind keine Personen, sondern Prozesse. In Teams werden daraus Anrufwarteschlangen und automatische Telefonzentralen, keine Benutzer.

Prüfe die Blöcke beim Carrier: Welche Nummernblöcke gehören wirklich dir, welche sind Teil eines Anlagenanschlusses, den du beim Wechsel nicht einfach mitnimmst?

Notiere Kurzwahlen und interne Nummernlängen. Dreistellige Durchwahlen in einer Welt mit E.164-Rufnummern sind lösbar, aber sie wollen bewusst geplant werden.

Sonderanschlüsse: die Liste, die niemand hat

Das hier ist der Abschnitt, den du ausdrucken und an die Wand hängen solltest. Jeder einzelne dieser Anschlüsse kann ein Projekt um Wochen verzögern, wenn er erst beim Umschalten auffällt. Und in Häusern mit OpenScape kommt oft noch etwas dazu, das bei anderen Herstellern seltener ist: gewachsene DECT-Landschaften. Kliniken, Pflegeeinrichtungen, Werkstätten und Lager haben über Jahre Funkabdeckung aufgebaut, die an der Anlage hängt – inklusive Alarmierung.

Anschluss / Funktion	Wo er sich versteckt	Zielbild in der Teams-Welt
Aufzugsnotruf	Analogport, oft ohne Beschriftung, im Aufzugsschacht endend	Analog belassen, über ATA oder Gateway am SBC – und danach wirklich testen
Brandmelde- und Alarmierungstechnik	Direkte Kopplung an die Anlage, teils mit eigener Verkabelung	Fachfirma einbinden, meist eigener Weg statt Teams; Abnahme dokumentieren
DECT-Abdeckung (Klinik, Lager, Werkstatt)	Eigene Basisstationen, an der OpenScape registriert	Teams-taugliches IP-DECT oder eigenständige Insel mit SIP-Kopplung
Türsprechstelle, Torsteuerung	Analogport oder proprietäres Modul, oft mit Türöffner-Relais	SIP-fähige Sprechstelle oder ATA; Relaislogik gesondert klären
Fax (Eingang und Ausgang)	Analogport, meist beim Empfang und in der Buchhaltung	Cloud-Faxdienst oder analoger Restanschluss; T.38 nicht blind voraussetzen
Frankiermaschine, Kaffeeautomat, Zeiterfassung	Analogport, Wählverbindung zum Dienstleister	Anbieter fragen, ob IP-Anbindung möglich ist – überraschend oft ja
Zentrale Ansagen und Warteschleifen	In der Anlage hinterlegt, oft mit rechtlich geprüften Texten	Texte und Rechte sichern; Neuvertonung einplanen, nicht improvisieren
Anwendungen mit CTI-Anbindung	ERP, CRM, Ticketsystem, Callcenter-Aufsatz	Schnittstelle einzeln prüfen; Teams-Integration oder Ersatz – früh klären

 

TIPP Der schnellste Weg zur vollständigen Liste ist unglamourös: Geh mit einer Person aus der Haustechnik und einer Person aus dem Einkauf einmal durch alle Technikräume und durch alle Rechnungen der letzten drei Jahre. Die Haustechnik kennt die Kabel, der Einkauf kennt die Verträge. Zusammen kennen sie mehr als jede Dokumentation. Zweiter Trick: Lass die Anlage eine Woche lang protokollieren, welche Anschlüsse tatsächlich Verkehr sehen. Was in einer normalen Arbeitswoche keinen einzigen Ruf hatte, ist ein Kandidat für die Abschaltung – nach Rückfrage, versteht sich, denn genau da versteckt sich auch der Aufzugsnotruf.

 

Vermittlungsplatz, Chefsekretariat und andere Anlagenklassiker

OpenScape-Kunden haben oft sehr ausgefeilte Vermittlungs- und Sekretariatsfunktionen im Einsatz. Das ist über Jahre gewachsen und funktioniert im Alltag hervorragend. Genau deshalb ist es der emotionalste Teil der Migration. Wer seit fünfzehn Jahren mit einem Vermittlungsplatz arbeitet, hat Abläufe im Muskelgedächtnis, nicht im Handbuch.

Der Fehler, den wir am häufigsten sehen: Man versucht, die alte Funktion eins zu eins nachzubauen. Das führt zu teuren Zusatzprodukten und trotzdem zu unzufriedenen Anwendern, weil das Gefühl nicht dasselbe ist. Der bessere Weg ist, den Zweck zu beschreiben statt die Funktion – und dann zu prüfen, wie Teams diesen Zweck erfüllt.

Funktion in der OpenScape-Welt	Der eigentliche Zweck	Umsetzung mit Teams Phone
Vermittlungsplatz	Externe Rufe schnell an die richtige Stelle bringen	Anrufwarteschlange plus Vermittlungskonsole; bei hohem Volumen Zusatzlösung prüfen
Chef-Sekretariat-Schaltung	Vorzimmer filtert und leitet gezielt weiter	Delegierung mit Anrufübernahme im Auftrag; Berechtigungen sauber setzen
Team- und Sammelanschluss	Mehrere Personen erreichen dieselbe Nummer	Anrufwarteschlange oder Anrufgruppe, je nach gewünschter Verteilung
Heranholen im Team	Klingelndes Telefon nebenan annehmen	Anrufparken oder Gruppen-Anrufübernahme – Abläufe vorher üben
Nachtschaltung, Feiertagsregel	Außerhalb der Zeiten anders routen	Automatische Telefonzentrale mit Zeit- und Feiertagsplänen
Zwangsweiterleitung, Vertretung	Abwesenheit darf keinen Ruf verschlucken	Rufumleitung und Delegierung; per Richtlinie zentral erlauben
Aufschalten und Mithören	Einarbeitung, Qualitätssicherung	Nur in Teil-Szenarien und nur mit Betriebsrat und Datenschutz – früh klären

 

WARNUNG Aufschalten, Mithören und Gesprächsaufzeichnung sind in Deutschland kein Konfigurationsthema, sondern ein Mitbestimmungs- und Datenschutzthema. Wer das erst beim Rollout anspricht, verliert planbar mehrere Wochen – und deutlich mehr Wohlwollen. Betriebsrat und Datenschutz gehören in die Inventurphase, nicht in die Abnahme.

 

3. Die Anbindungsentscheidung: Wer liefert dir künftig die Amtsleitung?

Sobald klar ist, was alles an der Anlage hängt, kommt die Entscheidung, die den Rest des Projekts prägt: Wie kommt Teams ans öffentliche Telefonnetz? Vier Wege stehen zur Wahl, und sie lassen sich kombinieren. Das ist keine Glaubensfrage, sondern eine Rechenaufgabe mit drei Variablen – Vertragslage, Sonderanschlüsse, eigene Betriebskompetenz.

Weg	Wer liefert die Rufnummern	Passt gut, wenn	Reibungspunkte
Microsoft Teams Calling Plan	Microsoft direkt	kleine Standorte, wenig Sonderfälle, schnelle Ergebnisse zählen	Verfügbarkeit und Konditionen je Land prüfen; wenig Gestaltungsspielraum
Operator Connect	ein Carrier aus dem Microsoft-Verzeichnis	du willst keinen SBC betreiben, aber einen echten Carriervertrag	Anbieterauswahl je Land; Sonderanschlüsse brauchen trotzdem eine Lösung
Teams Phone Mobile	Mobilfunkanbieter, SIM ist die Nummer	Außendienst, Werk, Baustelle – Menschen mit Telefon statt Schreibtisch	nur mit passendem Anbieter; als alleiniger Weg selten sinnvoll
Direct Routing	dein bestehender oder neuer SIP-Trunk	Sonderanschlüsse, Koexistenz, laufender Trunk-Vertrag, eigene Kompetenz	zertifizierter SBC nötig, inklusive Betrieb, Zertifikaten und Monitoring

 

Skizze 2: Das Zielbild mit Direct Routing – der SBC ist die Weiche, nicht der Ersatz für die alte Anlage.

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

Diese Situation begegnet uns in fast jedem zweiten Projekt. Der Anlagenanschluss wurde erst kürzlich verlängert, weil ja „erstmal nichts passiert“. Jetzt soll migriert werden, und der Vertrag läuft weiter. Das ist kein Ausschlusskriterium – es ist schlicht ein starkes Argument für Direct Routing, weil du den vorhandenen Trunk weiter nutzen und die Migration entkoppeln kannst.

Was du stattdessen tun solltest: Hol dir die Vertragsunterlagen tatsächlich auf den Tisch, bevor irgendjemand eine Architektur zeichnet. Kündigungsfristen, Mindestlaufzeit, Portierbarkeit der Rufnummernblöcke, Kanalzahl, technische Vorgaben. In mehr als einem Projekt hat sich dabei herausgestellt, dass die vermeintliche Blockade eine Frist war, die längst abgelaufen war – und in mindestens einem, dass der „SIP-Trunk“ tatsächlich noch ein Primärmultiplexanschluss war.

WARNUNG Rufnummernportierung ist der Termin, der deinen Projektplan bestimmt – nicht umgekehrt. Frag den abgebenden und den aufnehmenden Anbieter früh und schriftlich nach realistischen Vorlaufzeiten und plane Puffer ein. Und lege vorher fest, was passiert, wenn die Portierung am geplanten Tag nicht funktioniert. Ein Rückfallweg, den man erst am Freitagabend erfindet, ist kein Rückfallweg.

 

Wenn Direct Routing: den SBC auswählen und ihn auch betreiben

Ein SBC ist kein Kasten, den man einmal einrichtet und dann vergisst. Er hat Zertifikate, die ablaufen. Er hat Firmware, die gepflegt werden will. Und er ist genau der Punkt, an dem im Störungsfall alle gleichzeitig hinschauen. Wer Direct Routing wählt, entscheidet sich bewusst für ein Stück eigene Betriebsverantwortung – und bekommt dafür Kontrolle und Flexibilität, die kein anderer Weg bietet.

FAKTEN Microsoft betreibt für Direct Routing die Anschaltpunkte sip.pstnhub.microsoft.com, sip2.pstnhub.microsoft.com und sip3.pstnhub.microsoft.com. SIP-Signalisierung läuft über TLS auf Port 5061, Medien über SRTP. Der vollqualifizierte Name des SBC muss zu einer in deinem Microsoft-365-Tenant verifizierten Domäne gehören. Eine *.onmicrosoft.com-Domäne funktioniert nicht. Das Zertifikat muss von einer öffentlich vertrauenswürdigen Stelle stammen, den SBC-Namen als Common Name oder als alternativen Antragstellernamen führen und die erweiterte Schlüsselverwendung für Serverauthentifizierung enthalten. Microsoft empfiehlt, auf dem SBC mindestens zwei Medienports je gleichzeitigem Gespräch vorzusehen. Wer die Kanalzahl auf Kante plant, merkt das am ersten wirklich vollen Montagmorgen. Direct Routing wird im Koexistenzmodus „Islands“ nicht unterstützt. Wer noch Skype-for-Business-Reste im Tenant hat, klärt den Modus vorher.

 

Zur Auswahl selbst: Wir betreiben im eigenen Haus einen anynode-SBC von TE-SYSTEMS mit Direct Routing und SIP-Trunks von easybell – nicht als Laborsystem, sondern als Produktivtelefonie, an der auch dann etwas hängt, wenn der Beratungstag lang war. Das ist kein Werbeblock, sondern der Grund, warum wir bei Fragen zu Rufnummernnormalisierung, Zertifikatswechseln oder Trace-Analysen nicht aus dem Handbuch vorlesen müssen. anynode steht auf der Microsoft-Liste zertifizierter SBC, unterstützt Media Bypass und Local Media Optimization.

Für OpenScape-Häuser lohnt vor der Beschaffung ein Blick ins eigene Rack: Der Unify OpenScape Session Border Controller ist bei Microsoft ebenfalls als zertifiziert gelistet. Wenn ein solches Gerät bereits vorhanden ist, kann das die Anfangsinvestition deutlich senken. Prüfen musst du trotzdem: Versionsstand, Lizenzierung, Kapazität, Supportvertrag – und ob der Betrieb künftig noch zu deiner Strategie passt, wenn du gerade dabei bist, dich von der Plattform zu lösen.

TIPP Redundanz kostet Geld, ein Totalausfall der Telefonie kostet mehr. Entscheide das bewusst und schreib die Entscheidung auf. Wenn die Geschäftsführung erklärt, ein halber Tag ohne Telefon sei verkraftbar, ist das eine völlig legitime Antwort – aber sie sollte dokumentiert sein und nicht am Ausfalltag neu verhandelt werden. Und ja: Der Notruf gehört in den Test, und zwar von jedem Standort aus und mit Standortdaten. Nicht am Umschalttag, sondern in der Pilotphase.

 

4. Koexistenz und Endgeräte: die zwei Fragen, die weh tun

In kaum einem Haus lässt sich an einem Wochenende umschalten. Also gibt es eine Phase, in der OpenScape und Teams gleichzeitig laufen. Diese Phase ist beherrschbar – aber sie ist teuer, und sie hat die unangenehme Eigenschaft, sich von selbst zu verlängern, wenn niemand ein Enddatum verteidigt.

Wer ist der Ankerpunkt für eingehende Rufe?

Das ist die zentrale Architekturfrage der Übergangsphase. Es gibt drei Muster, und jedes hat seinen Preis.

Skizze 3: Drei Muster für die Koexistenz – und der Grund, warum das mittlere in der Praxis meist gewinnt.

Muster	So läuft der eingehende Ruf	Vorteil	Preis
OpenScape bleibt Anker	Carrier auf die Anlage, von dort per SIP-Kopplung zu Teams	keine Portierung zu Projektbeginn, geringe Anfangshürde	alte Anlage bleibt bis zum Schluss im kritischen Pfad
Teams wird Anker	Carrier auf den SBC, von dort zur Rest-OpenScape	Zielarchitektur ab Tag eins, alte Anlage schrumpft sichtbar	Portierung liegt früh im Projekt und ist sofort sichtbar
Trunk gespalten	zwei Trunks oder zwei Nummernblöcke, Querverbindung intern	saubere Trennung, klare Verantwortlichkeiten	doppelte Kosten, doppelte Fehlerquellen, Nummernpflege

 

Unsere Empfehlung in den meisten Fällen: Teams wird Anker, sobald die Vertragslage das zulässt. Der Grund ist weniger technisch als psychologisch. Solange die alte Anlage im Hauptpfad steht, bleibt sie gefühlt unverzichtbar – und jede Diskussion über ihre Abschaltung wird vertagt. Sobald sie nur noch an einem Nebenstrang hängt, wird die Restliste plötzlich sehr überschaubar.

Interne Rufe zwischen beiden Welten

Während der Koexistenz muss jede Person jede andere erreichen können – über die gewohnte interne Nummer, nicht über eine Ersatznummer, die man sich merken soll. Konkret heißt das:

Einheitlicher Nummernraum: Interne Durchwahlen müssen auf beiden Seiten in dieselbe E.164-Rufnummer aufgelöst werden. Die Normalisierung gehört an eine Stelle – meist den SBC – und nicht verteilt auf drei Systeme.

Kein Nummernwechsel während der Migration: Wer die Nummer wechselt, verliert Erreichbarkeit und Vertrauen gleichzeitig. Nummern wandern mit.

Anrufbeantworter eindeutig: Es darf nur eine Mailbox pro Person geben. Zwei Mailboxen sind kein Komfort, sondern ein Beschwerdegrund.

Präsenz ehrlich halten: Zwischen den Welten wird der Anwesenheitsstatus in aller Regel nicht sauber synchronisiert. Sag das vorher, statt es hinterher zu erklären.

Vertretungsregeln testen: Genau die Ketten, die im Alltag zählen – Sekretariat, Rufumleitung, Vertretung – gehören in den Testplan der Übergangsphase.

Endgeräte: der Punkt, an dem OpenScape-Kunden anders dastehen

Hier kommt der Unterschied zu manch anderer Herstellermigration, und er ist unangenehm. Microsoft pflegt für den Teams SIP Gateway einen Katalog kompatibler SIP-Geräte. Darin stehen Modelle von Cisco, Poly, Yealink, AudioCodes, Spectralink, Ascom, Gigaset, Algo, Snom, 2N, Axis – und auch Geräte von Alcatel-Lucent Enterprise sowie die J100-Serie von Avaya. Unify beziehungsweise OpenScape steht dort nicht.

Das heißt nicht, dass gar nichts geht: Die OpenScape Desk Phone CP-Familie ist grundsätzlich SIP-fähig. Es heißt aber, dass du dich nicht auf eine Microsoft-Unterstützung berufen kannst und im Störungsfall allein dastehst. Für einen Pilotversuch im Labor mag das reizvoll sein. Für eine Flotte von vierhundert Apparaten in einem Haus, das gerade Planungssicherheit sucht, ist es die falsche Wette.

Skizze 4: Endgeräte-Entscheidung – vier Kategorien, vier Antworten, ein Budgetgespräch.

WICHTIG Rechne die Endgeräte ehrlich in den Business Case ein, und zwar in der ersten Version der Rechnung. Nichts beschädigt die Glaubwürdigkeit eines Migrationsprojekts so zuverlässig wie eine Hardwareposition, die im Monat sieben plötzlich auftaucht. Die gute Nachricht dabei: Ein großer Teil der Belegschaft braucht überhaupt kein Tischtelefon mehr, sondern ein ordentliches Headset. Das ist meist günstiger als das Telefon – aber es ist eine Veränderung, die man begleiten muss und nicht per E-Mail verkündet. Für Bereiche ohne Arbeitsplatzrechner – Werkstatt, Lager, Pforte, Empfang – bleiben Tischtelefone und DECT natürlich richtig. Plane sie gezielt, statt sie pauschal zu ersetzen oder pauschal zu streichen.

 

5. Der Wellenplan – und was am Abschalttag zählt

Eine Migration in einem Rutsch ist in Häusern ab etwa hundert Nebenstellen keine gute Idee. Nicht weil es technisch nicht ginge, sondern weil du an einem einzigen Tag alle Fehler gleichzeitig bekommst. Wellen geben dir die Möglichkeit, aus Welle eins zu lernen, bevor Welle zwei anfängt.

Skizze 5: Ein realistischer Wellenplan – samt der Zeitfresser, die in den ersten Projektplänen regelmäßig fehlen.

Pilot: klein, laut und repräsentativ

Der Pilot ist keine Machbarkeitsstudie. Dass Teams telefonieren kann, ist bekannt. Der Pilot beantwortet eine andere Frage: Funktioniert es in deinem Haus, mit deinen Abläufen, deinem Netz und deinen Leuten? Nimm deshalb keine Freiwilligen aus der IT, sondern Menschen, die viel telefonieren und sich trauen, sich zu beschweren. Ein Sekretariat, ein Vertriebsteam, die Zentrale, ein Bereich mit DECT. Zwanzig bis vierzig Personen reichen – sie müssen nur die richtigen sein.

Wellenschnitt: nach Organisation, nicht nach Etage

Der häufigste Planungsfehler ist der Schnitt nach Gebäudeteilen. Er ist bequem für die IT und schmerzhaft für alle anderen, weil er Teams auseinanderreißt, die den ganzen Tag miteinander telefonieren. Schneide nach organisatorischen Einheiten – und nimm Vertretungsketten und Sekretariate immer komplett mit.

Welle	Wer	Warum in dieser Reihenfolge
Pilot	IT-nahe Bereiche plus ein lautes Fachteam	Fehler früh finden, solange Nachsicht noch vorhanden ist
Welle 1	eine vollständige Organisationseinheit mit Sekretariat	erster echter Realitätstest inklusive Vertretungsketten
Welle 2–n	Bereich für Bereich, ähnliche Profile bündeln	Routine entsteht, der Aufwand pro Person sinkt spürbar
Sonderfälle	Zentrale, Empfang, Werkstatt, DECT-Bereiche, Callcenter	brauchen eigene Vorbereitung – nicht nebenbei mitschieben
Restanschlüsse	Aufzug, Fax, Tür, Alarmierung, Maschinen	zuletzt, dafür mit dokumentierter Einzelabnahme

 

Was in der Praxis regelmäßig schiefgeht

Das Netz war nicht Teil des Projekts. Sprache reagiert empfindlich auf alles, was Daten verzeihen. WLAN-Ausleuchtung, QoS und Uplinks gehören vor den Rollout, nicht in die Fehlersuche danach.

Standortdaten für Notrufe fehlen. Wer mobil arbeitet, ist nicht mehr an einer Dose. Das ist ein Punkt für die Planung und nicht für den Zufall.

Die Zentrale wurde nebenbei migriert. Sie ist das Aushängeschild. Wenn sie stottert, weiß es innerhalb eines Tages die halbe Kundschaft.

Niemand hat die alten Ansagen gesichert. Texte, Vertonung, rechtlich geprüfte Formulierungen – alles davon lebt in der alten Anlage und stirbt mit ihr.

Der Parallelbetrieb hat kein Enddatum. Dann zahlst du zwei Anlagen, bis jemand die Rechnung sieht. Das Enddatum gehört in den Projektplan, mit Namen daneben.

Die Schulung war eine E-Mail. Telefonieren ist Muskelgedächtnis. Fünfzehn Minuten in kleiner Runde am Tag der Umstellung sparen wochenlange Tickets.

Der Abschalttag – und was danach kommt

Irgendwann klingelt an der alten Anlage nichts mehr. Genau da beginnt die Phase, in der Projekte gerne einschlafen. Widerstehe der Versuchung, die OpenScape „sicherheitshalber noch ein Jahr“ stehen zu lassen. Ein System ohne Verkehr, ohne Pflege und ohne verantwortliche Person ist kein Sicherheitsnetz, sondern ein Altrisiko mit Netzwerkanschluss.

Stillstandsphase mit Protokoll: Zwei bis vier Wochen mitschneiden, ob wirklich kein Verkehr mehr läuft. Was auffällt, wird einzeln geklärt.

Kaltstart-Test der neuen Welt: Einmal ohne Netz der alten Anlage gegenprüfen, bevor sie abgeschaltet wird – nicht danach.

Konfiguration archivieren: Anlagendaten, Wählpläne, Ansagen und Berechtigungen sichern, bevor der Strom weg ist. Danach ist es Archäologie.

Verträge kündigen: Wartung, Softwarepflege, Anlagenanschluss, ungenutzte Amtskanäle. Das ist der Teil, mit dem sich das Projekt refinanziert.

Ordentlich entsorgen: Datenträger und Baugruppen mit Konfigurationsdaten gehören nicht auf den Sperrmüll und auch nicht ungeprüft in den Gebrauchtmarkt.

Andere Hersteller, dasselbe Muster

Der Ablauf, den du hier liest, ist nicht Unify-spezifisch – die Reihenfolge Inventur, Anbindung, Koexistenz, Wellen, Abschaltung gilt herstellerübergreifend. Unterschiedlich sind die Details: Bei Alcatel-Lucent OmniPCX ist die Endgerätefrage entspannter, weil Microsoft mehrere ALE-Modelle im SIP-Gateway-Katalog führt. Bei Avaya dominiert die Frage nach den Anwendungen rund um die Anlage. Und bei Unify OpenScape ist es genau diese Mischung aus Plattformunsicherheit, HiPath-Altbestand und Endgeräteflotte. Das Gesamtbild und die Lizenzlogik findest du auf der Seite zur Teams-Telefonie.

Thema	Unify OpenScape / HiPath	Alcatel-Lucent OmniPCX	Avaya
Hauptantrieb zur Migration	Unsicherheit über die Plattformzukunft nach mehreren Eigentümerwechseln	auslaufende Wartung, Modernisierungsdruck	Strategiewechsel des Herstellers hin zu großen Kunden
Endgeräte im SIP-Gateway-Katalog	nicht gelistet	mehrere Modelle gelistet	J100-Serie gelistet
Typischer Altbestand	HiPath 3000 und 4000 in Zweigstellen und Werken	ältere OmniPCX-Generationen	gewachsene Anwendungslandschaft rund um die Anlage
Eigener SBC vorhanden	möglich – OpenScape SBC ist bei Microsoft zertifiziert gelistet	je nach Aufbau, meist Fremdgerät	möglich – Avaya SBCE ist zertifiziert gelistet
Besonders arbeitsintensiv	DECT-Landschaften und Sekretariatsfunktionen	Sonderanschlüsse und Rufnummernpläne	Kontaktcenter- und Anwendungsanbindung

 

Häufige Fragen

Ist OpenScape jetzt eigentlich abgekündigt?

Nein. Mitel führt OpenScape weiter im Portfolio, zur OpenScape 4000 gibt es aktuelle Produktdokumentation zur Version V11, und die OpenScape Business wird ebenfalls weiterentwickelt. Einzelne Unify-Produkte wurden allerdings eingestellt oder in andere Mitel-Angebote überführt – Circuit zum Beispiel. Die richtige Frage für dich lautet deshalb nicht „ist es abgekündigt?“, sondern „gilt die Roadmap für genau die Komponenten, auf denen mein Betrieb steht?“ Diese Frage gehört schriftlich an den Hersteller oder dein Systemhaus.

Wir haben noch eine HiPath im Nebenstandort. Wie dringend ist das?

Dringender als es sich anfühlt. Die HiPath 3000 ist bereits seit Jahren aus der Herstellerunterstützung, bei der HiPath 4000 liegen Bestellstopp, Ende der Entwicklungsunterstützung und Ersatzteilfristen ebenfalls in der Vergangenheit. Solange nichts ausfällt, merkst du davon nichts. Fällt etwas aus, hast du keine Vorwarnzeit und bist auf den Gebrauchtmarkt angewiesen. Behandle solche Standorte als erste Wellen, nicht als letzte.

Können wir unsere OpenScape-Telefone an Teams weiterbetreiben?

Nicht mit Microsoft-Unterstützung. Der Gerätekatalog des Teams SIP Gateway listet unter anderem Cisco, Poly, Yealink, AudioCodes, Spectralink, Ascom, Gigaset, Snom, Alcatel-Lucent Enterprise und die Avaya J100-Serie – Unify-Geräte stehen dort nicht. Die CP-Familie ist zwar SIP-fähig, aber ein Betrieb außerhalb des Katalogs ist eine Eigenkonstruktion ohne Rückendeckung. Für eine Flotte ist das die falsche Wette; plane den Austausch ein oder setze auf Headsets, wo kein Tischtelefon nötig ist.

Wir haben einen OpenScape SBC im Rack. Können wir den für Direct Routing nutzen?

Grundsätzlich ja – der Unify OpenScape Session Border Controller steht auf der Microsoft-Liste zertifizierter SBC für Direct Routing, ab einem definierten Mindestversionsstand. Prüfen musst du Versionsstand, Lizenzumfang, Kapazität und Supportvertrag. Und die strategische Frage stellt sich trotzdem: Willst du dich von der Plattform lösen und dabei ausgerechnet ihre Komponente in den kritischen Pfad stellen? Beide Antworten sind vertretbar, sie sollten nur bewusst fallen.

Was ist mit unserer DECT-Abdeckung in Klinik und Lager?

Das ist bei OpenScape-Kunden der teuerste Einzelposten und gehört ganz nach vorn in die Planung. Microsoft listet für den Teams SIP Gateway IP-DECT-Systeme mehrerer Hersteller, darunter Spectralink, Ascom und Gigaset. Unify-DECT ist nicht dabei. Realistisch sind daher zwei Wege: Austausch gegen ein Teams-taugliches IP-DECT-System oder Weiterbetrieb als eigenständige Insel mit SIP-Kopplung. Bei Alarmierung und Personennotsignalanlagen ist die Insel oft die vernünftigere Wahl – dann aber bitte mit klarer Verantwortungsabgrenzung.

Brauchen wir überhaupt einen SBC?

Nur bei Direct Routing. Mit Operator Connect oder Calling Plan liefert der Carrier beziehungsweise Microsoft die Anbindung, ohne dass du eigene Hardware betreibst. Für Direct Routing spricht, wenn du Sonderanschlüsse, eine längere Koexistenzphase, einen laufenden Trunk-Vertrag oder besondere Routing-Anforderungen hast. In der Praxis kombinieren viele Häuser: Operator Connect für die Bürowelt, Direct Routing für die Sonderfälle. Das ist ausdrücklich erlaubt und oft die günstigste Gesamtrechnung.

Wie lange dauert so eine Migration realistisch?

Für ein mittelgroßes Haus mit mehreren hundert Nebenstellen liegen Inventur, Entscheidung, Aufbau, Pilot und Wellen erfahrungsgemäß im Bereich von sechs bis achtzehn Monaten. Die Spanne ist so groß, weil sie fast nichts mit der Technik zu tun hat: Entscheidungswege, Vertragsfristen, Portierungsvorlauf, Betriebsrat, Netzwerkertüchtigung und die Frage, wie viele Sonderanschlüsse sich noch finden. Die reine Umstellung der Benutzerkonten ist der schnellste Teil des Projekts.

Was passiert mit den Notrufen?

Notrufe müssen von jedem Standort funktionieren und mit einer brauchbaren Standortangabe herausgehen. Bei Operator Connect wird jeder Benutzer für Notrufe aktiviert und der Ruf an den Netzbetreiber übergeben; bei Direct Routing gestaltest du das über Routing und Standortzuordnung selbst. Wichtig ist in beiden Fällen: Der Notruf gehört in die Pilotphase und in jede Welle in den Testplan – pro Standort, nicht pro Projekt.

Der Betriebsrat blockiert. Was jetzt?

Meist blockiert nicht der Betriebsrat, sondern eine Informationslücke. Die Sorgen sind in aller Regel dieselben: Wer sieht welche Daten? Werden Gespräche aufgezeichnet? Werden Anwesenheitszeiten ausgewertet? Wer diese Fragen früh, offen und schriftlich beantwortet, bekommt eine Vereinbarung. Wer sie beim Rollout zum ersten Mal hört, bekommt eine Verzögerung. Aufschalten, Mithören und Aufzeichnung sind dabei die Punkte, die immer eine Regelung brauchen.

Lohnt sich externe Unterstützung?

Für die Inventur und die Anbindungsentscheidung fast immer – das sind die zwei Phasen, in denen Fehler am teuersten sind und Erfahrung am meisten spart. Den Rollout können viele Häuser selbst fahren, wenn Konzept und Vorlagen stehen. Wenn du eine unabhängige Einschätzung willst: Teams-Telefonie-Beratung. Wir betreiben Teams-Telefonie mit Direct Routing selbst – inklusive der Abende, an denen ein Zertifikat abläuft.

Fazit

Die Ablösung einer OpenScape durch Microsoft Teams Phone ist kein Wagnis und kein Forschungsprojekt. Der Weg ist erprobt, die Schnittstellen sind offen, und in vielen Häusern steht die Zielplattform ohnehin schon lizenziert im Tenant. Was diese Migration von anderen unterscheidet, sind drei Dinge: der Antrieb, der weniger aus der Technik als aus der Frage nach Planbarkeit kommt; die HiPath-Altbestände, die unbemerkt aus der Herstellerunterstützung gelaufen sind; und die Endgeräteflotte, die dich anders als bei manchem Wettbewerber nicht kostenlos mitkommt.

Der Erfolg entscheidet sich früh. Nicht am SBC, nicht am Wählplan, sondern in der Inventur und in der Anbindungsentscheidung. Wer weiß, was alles an der Anlage hängt, wer den Trunk-Vertrag gelesen hat und wer der Koexistenz ein Enddatum gibt, migriert am Ende ruhig. Wer mit einer Excel-Tabelle startet, die zuletzt vor sechs Jahren gepflegt wurde, lernt seine Sonderanschlüsse einzeln kennen – immer freitags, immer um sechzehn Uhr.

Und der wichtigste Rat zum Schluss: Migriere nicht aus Angst vor Schlagzeilen. Migriere, weil du deiner Geschäftsführung in fünf Jahren noch erklären kannst, warum die Telefonie dort steht, wo sie steht. Das große Bild dazu findest du in unserer Serie Teams-Telefonie. Wenn du eine zweite Meinung zu deinem konkreten Fall willst – mit Blick auf Bestand, Verträge und Zeitplan statt auf Produktfolien: Teams-Telefonie-Beratung.

Quellen

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 SIP Gateway (Liste kompatibler Geräte) – https://learn.microsoft.com/en-us/microsoftteams/devices/sip-gateway-plan

Microsoft Learn: Plan für Telefonieanbieter (Operator Connect) – https://learn.microsoft.com/de-de/microsoftteams/operator-connect-plan

Microsoft Learn: Planen und Verwalten von Notrufen – https://learn.microsoft.com/de-de/microsoftteams/what-are-emergency-locations-addresses-and-call-routing

Mitel: Unify is now part of Mitel – Hinweise für Bestandskunden – https://www.mitel.com/unify-now-part-mitel

Mitel: Financial Restructuring 2025 – https://www.mitel.com/about/financial-restructuring

Mitel: OpenScape 4000 – Produktseite – https://www.mitel.com/products/openscape-4000

Mitel: OpenScape Business – Produktseite – https://www.mitel.com/products/openscape-business

Mitel: Unify OpenScape Session Border Controller – https://www.mitel.com/products/openscape-session-border-controller

Mitel Document Center: OpenScape 4000 V11 Installation, Configuration and Migration – https://www.mitel.com/document-center/business-phone-systems/openscape-4000-ecosystem/openscape-4000/110/en/openscape-4000-v11-installation-configuration-and-migration-installation-guide

SiliconANGLE: Mitel closes deal to acquire Unify from Atos (Oktober 2023) – https://siliconangle.com/2023/10/02/mitel-closes-deal-acquire-unify-atos/

SiliconANGLE: Mitel restructures under Chapter 11 (März 2025) – https://siliconangle.com/2025/03/10/mitel-restructures-chapter-11-bankruptcy-pursue-hybrid-opportunity/

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

Alle Angaben zu Produktlebenszyklen, Versionsständen und Anbieterportfolios wurden zum Redaktionsstand am 2. September 2026 recherchiert. Lebenszyklusdaten und Gerätelisten ändern sich – prüfe die verlinkten Primärquellen, bevor du eine Beschaffungsentscheidung darauf stützt. Preise, Konditionen und Vertragsdetails nennt dieser Beitrag bewusst nicht; sie hängen vom Einzelfall ab.