Cisco CUCM zu Microsoft Teams Phone wechseln

Eine Cisco-Telefonanlage stirbt nicht. Sie läuft. Und läuft. Und läuft. Genau das ist das Problem. Während ein in die Jahre gekommenes System aus anderen Häusern irgendwann durch schlichte Unzuverlässigkeit die Entscheidung selbst trifft, macht ein gepflegter Unified-CM-Cluster gar nichts falsch. Er tut unbeirrt seinen Dienst, während um ihn herum die Welt drei Mal umgezogen ist, die Belegschaft den ganzen Tag in Teams sitzt und niemand mehr das Tischtelefon anfasst, außer um den Staub wegzuwischen.

Deshalb ist dieser Artikel anders als seine Schwesterartikel zu Avaya, Unify oder Alcatel-Lucent. Dort lautet die Frage: Wie kommen wir hier raus? Bei Cisco lautet sie: Wollen wir überhaupt raus — und wenn ja, wohin? Denn Cisco ist der einzige der klassischen TK-Hersteller, der ein wirklich konkurrenzfähiges eigenes Cloud-Angebot hat. Wer über die Ablösung des Call Managers nachdenkt, landet fast automatisch in einem Zweikampf zwischen Webex Calling und Microsoft Teams Phone. Und dieser Zweikampf wird in vielen Häusern erstaunlich unehrlich geführt — mal von der Cisco-Seite, mal von der Microsoft-Seite, gelegentlich von beiden gleichzeitig.

Wir machen das hier anders. Erst die Entscheidungslogik, dann die Technik, dann der Fahrplan. Und an den Stellen, an denen Webex Calling die bessere Wahl ist, steht das auch so drin. Wir bauen und betreiben Teams-Telefonie selbst — eigener anynode-SBC, Direct Routing, easybell-Trunks, täglich im Einsatz. Das heißt nicht, dass Teams Phone für jeden die Antwort ist. Es heißt nur, dass wir wissen, wovon wir reden, wenn wir sagen, wo es weh tut.

FAKTEN Worum es bei dieser Entscheidung wirklich geht: · Cisco Unified CM ist eine erwachsene, funktional sehr vollständige Anlage. Der Wechsel ist selten eine Rettungsaktion, sondern fast immer eine strategische Entscheidung. · Cisco hat die Lizenzierung seiner On-Premises-Telefonie in Richtung Abonnement verschoben (Collaboration Flex Plan). Wer bislang mit Perpetual-Lizenzen kalkuliert hat, rechnet bei der Verlängerung eine andere Rechnung. · Zwei Cisco-Bausteine dürfen im Teams-Zielbild bleiben: der Cisco Unified Border Element (CUBE) ist ein für Direct Routing zertifizierter SBC, und viele Cisco-Tischtelefone lassen sich mit Multiplatform-Firmware am Teams SIP Gateway betreiben. · Alle Lifecycle-, Lizenz- und Zertifizierungsangaben in diesem Artikel: Stand 2. September 2026. Prüfe sie vor jeder Beschaffung an der Primärquelle nach.

 

Dieser Beitrag gehört zur Serie rund um die Teams-Telefonie. Wenn du zuerst wissen willst, wie sich die Plattformen grundsätzlich unterscheiden, lies den Vergleich von Teams, Zoom und Webex. Wenn ihr die Entscheidung nicht allein treffen wollt, hilft unsere Beratung zur Teams-Telefonie genau an dieser Stelle weiter.

Die Doppelentscheidung: erst bleiben oder gehen, dann Cisco oder Microsoft

In fast jedem Cisco-Projekt, das auf unserem Tisch landet, sind die beiden Fragen munter vermischt. Die Netzwerkabteilung verteidigt den Call Manager, die Modern-Work-Abteilung will Teams, der Einkauf will wissen, was billiger ist, und irgendjemand wirft „aber wir haben doch gerade erst Room-Systeme gekauft“ in den Raum. Danach redet man achtzehn Monate lang und entscheidet nichts.

Der Ausweg ist banal: Die Fragen sind nacheinander zu beantworten, nicht gleichzeitig.

Skizze 1: Zwei Fragen, zwei Zeitpunkte. Wer sie vermischt, entscheidet gar nicht.

Frage 1: Trägt die vorhandene Plattform noch drei bis fünf Jahre?

Das ist eine nüchterne Frage mit vier Antwortteilen — und du kannst sie in zwei Wochen beantworten, wenn du willst.

Lifecycle: Welche Version läuft, und wie lange gibt es dafür noch Software und Support? Cisco veröffentlicht diese Daten sauber. Für Version 12.5 lag das Ende des Supports im August 2025, für die perpetuelle Variante von Version 14 liegt das Ende der Software-Wartung im April 2026 und das letzte Support-Datum im April 2027. Version 15 ist der aktuelle Zielstand.

Lizenz: Steht ihr noch auf Perpetual mit Wartungsvertrag oder schon auf Abonnement? Diese Umstellung ist der eigentliche Auslöser vieler Projekte — nicht weil das Abonnement grundsätzlich schlecht wäre, sondern weil eine laufende Zahlungsverpflichtung plötzlich sichtbar macht, was die Anlage jedes Jahr kostet.

Hardware: Auf welchen Servern läuft der Cluster, und wie alt sind sie? Virtualisiert auf aktueller Hardware ist entspannt. Auf Blades, die seit acht Jahren im Rack stehen, ist es eine Wette.

Personal: Wer im Haus kann diese Anlage wirklich? Wenn die ehrliche Antwort „eine Person, und die geht in drei Jahren“ lautet, ist Frage 1 bereits beantwortet — unabhängig von jeder Technik.

Wenn alle vier Antworten gut sind, dann renoviert. Aktualisiert die Version, dreht die Lizenzen, kauft ein paar neue Endgeräte, und redet in drei Jahren wieder darüber. Das ist keine Niederlage, das ist eine legitime Entscheidung. Nur trefft sie bitte bewusst und mit Datum, statt sie durch Nichtstun herbeizuführen.

WARNUNG Der teuerste Weg ist keiner der beiden. Der teuerste Weg ist der, bei dem ihr weder renoviert noch migriert, weil die Entscheidung immer wieder vertagt wird. Am Ende steht dann ein Cluster ohne Support, ein Wartungsvertrag zu Nachverhandlungskonditionen und eine Migration unter Zeitdruck. Migrationen unter Zeitdruck kosten in unserer Erfahrung deutlich mehr als geplante — nicht weil die Technik teurer wird, sondern weil dann alles parallel und mit externen Kräften laufen muss.

 

Frage 2: Webex Calling oder Teams Phone?

Jetzt erst wird es interessant. Und hier ist der Punkt, an dem viele Beratungshäuser unehrlich werden, weil sie eine Seite verkaufen. Wir formulieren es so klar wie möglich: Webex Calling ist ein sehr gutes Produkt. Für bestimmte Häuser ist es die richtige Antwort. Für die Mehrheit unserer Kundschaft ist es das nicht — aber die Gründe dafür sind selten technisch.

Die entscheidende Frage lautet nämlich nicht „welche Telefonanlage ist besser“, sondern „wie viele Kollaborationsplattformen wollt ihr betreiben, lizenzieren, schulen und absichern“. Wer Microsoft 365 im Haus hat und Teams ohnehin für Chat und Besprechungen nutzt, hat mit Webex Calling zwei Plattformen, zwei Verzeichnisanbindungen, zwei Admin-Konsolen, zwei Support-Wege und zwei Rechnungen. Das kann man wollen. Man sollte nur wissen, dass man es tut.

Kriterium	Unified CM behalten	Webex Calling	Teams Phone
Betriebsmodell	eigene Server, eigenes Patchen, eigene Redundanz	Cloud beim Hersteller, Dedicated Instance als Zwischenschritt	Cloud im vorhandenen Microsoft-365-Tenant
Funktionale Nähe zum Bestand	vollständig	sehr hoch, Migrationswerkzeuge vom Hersteller	hoch bei Standardtelefonie, Lücken bei Cisco-Spezialitäten
Cisco-Tischtelefone	unverändert	unverändert	nur mit MPP-Firmware über SIP Gateway, Funktionsumfang reduziert
Cisco-Room-Systeme	unverändert	unverändert	ausgewählte Modelle sind als Teams Rooms zertifiziert
Client für die Belegschaft	Jabber neben Teams	Webex App neben Teams	Teams — ein Client für alles
Zahl der Plattformen	zwei (UC und Microsoft 365)	zwei (Webex und Microsoft 365)	eine
Anbindung ans Telefonnetz	SIP-Trunk am CUBE	Cloud Connected PSTN, Local Gateway oder Anbieter von Cisco	Calling Plan, Operator Connect oder Direct Routing
Wo es typischerweise klemmt	Personal und Lifecycle	Lizenzkosten neben M365, doppelte Administration	Endgeräte, Sonderdienste, Contact Center

 

Wo Webex Calling ehrlicherweise die bessere Wahl ist

Es gibt Konstellationen, in denen wir selbst von Teams Phone abraten beziehungsweise zumindest zu einer sehr genauen Prüfung raten. Vier davon sehen wir regelmäßig:

Sehr großes, sehr aktuelles Cisco-Geräteportfolio. Wenn ihr im vergangenen Jahr dreistellig viele Tischtelefone und ein Dutzend Räume beschafft habt, ist die Abschreibungsfrage härter als jedes Plattformargument. Rechnet den Restbuchwert aus, bevor ihr philosophiert.

Tief integriertes Contact Center auf Cisco-Basis. Ein gewachsenes UCCE mit eigener Skript-Logik, Wallboards und angebundenen Fachverfahren ist kein Nebenschauplatz, sondern ein eigenes Projekt. Der Wechsel auf ein anderes Contact Center ist möglich und wird oft gemacht — aber er gehört als eigener Posten in den Business Case, nicht als Fußnote.

Harte Anforderungen an Verfügbarkeit im Werk oder im Krankenhaus. Wenn Telefonie auch dann funktionieren muss, wenn die Internetanbindung wegbricht, ist die Frage nach lokaler Überlebensfähigkeit zentral. Beide Plattformen haben dafür Antworten, aber die Antworten unterscheiden sich, und diese Diskussion muss vor der Entscheidung geführt werden, nicht danach.

Politische Bindung an Cisco. Manchmal ist die Netzwerkinfrastruktur komplett Cisco, der Rahmenvertrag läuft über Cisco, und die Beziehung ist gut. Das ist kein technisches Argument, aber ein reales. Ignoriere es nicht, sondern benenne es — dann kann man darüber sprechen.

TIPP Mach die Entscheidung an einer Zahl fest, nicht an einer Meinung. Wir lassen Kunden gern eine simple Rechnung aufstellen: Was kosten fünf Jahre Webex Calling zusätzlich zu den Microsoft-365-Lizenzen, die ihr ohnehin bezahlt? Und was kostet Teams Phone zusätzlich zu denselben Lizenzen, plus die einmaligen Kosten für Endgeräte, SBC und Migration? Diese zwei Zahlen nebeneinander beenden die meisten Grundsatzdebatten innerhalb einer Sitzung. Achtung: In vielen Enterprise-Verträgen ist Teams Phone bereits enthalten oder sehr günstig zubuchbar — prüft euren konkreten Vertrag, statt Listenpreise zu vergleichen.

 

Bestandsaufnahme: was alles am Call Manager hängt

Angenommen, die Entscheidung ist gefallen und heißt Teams Phone. Dann beginnt der Teil, den fast alle unterschätzen. Der Unified CM ist nämlich nie allein im Rack. Um ihn herum hat sich über zehn oder fünfzehn Jahre ein Ökosystem gebildet, das im Betrieb unsichtbar ist und in der Migration plötzlich sehr sichtbar wird.

Skizze 2: Zwölf Kacheln, zwölf Teilprojekte. Die erste ist die einfachste.

Die Anlage ist nur die Spitze

Ein Unified-CM-Cluster besteht aus Publisher und Subscribern, dazu kommt in aller Regel Unity Connection für Voicemail und Ansagen, oft IM & Presence für Jabber, häufig Expressway-C und Expressway-E für den Zugriff von außen, und praktisch immer ein CUBE als Übergang zum Carrier. Jede dieser Komponenten hat im Zielbild eine Entsprechung, keine Entsprechung oder eine Entsprechung mit Sternchen.

Cisco-Komponente	Entsprechung in Teams Phone	Aufwand	Was zu prüfen ist
Unified CM (Anrufsteuerung)	Teams Phone im Tenant	mittel	Rufnummernplan, Wahlregeln, Berechtigungsklassen neu modellieren
Unity Connection (Voicemail)	Cloud Voicemail mit Transkription	gering	alte Nachrichten werden nicht migriert, Ansagen neu einsprechen
Auto Attendant / Vermittlung	Automatische Telefonzentrale, Anrufwarteschlangen	mittel	Öffnungszeiten, Feiertagslogik, Sprachauswahl nachbauen
IM & Presence / Jabber	Teams-Client	gering	läuft in vielen Häusern ohnehin doppelt, Abschaltdatum setzen
Expressway C/E	entfällt	gering	B2B-Video und Fremdsysteme prüfen, bevor die Kiste ausgeht
CUBE	kann als SBC für Direct Routing bleiben	gering bis mittel	IOS-XE-Version, Lizenz, Zertifikate, Leistungsreserven
UCCX / UCCE	Warteschlangen für einfache Fälle, sonst Drittanbieter	hoch	eigenes Teilprojekt, nicht nebenbei, Aufzeichnung mitdenken
CTI / TAPI-Kopplungen	Teams-Kopplung des Fachverfahrens	hoch	Herstellerfreigabe einholen, Testinstanz vor dem Rollout
Analog, DECT, Türsprechstelle	Gateway am SBC oder SIP-Gerät am SIP Gateway	mittel	jedes Gerät einzeln erfassen, keine Sammelposition
Paging / Durchsage	Drittanbieter oder Beibehaltung als Insel	mittel	Sicherheitsrelevanz klären, Betriebsrat und Arbeitsschutz einbeziehen
CDR / Abrechnung	Call Analytics, Call Quality Dashboard, Drittanbieter	gering bis mittel	Aufbewahrungsfristen und Mitbestimmung früh klären

 

Contact Center, Jabber und die Ränder

Drei Punkte verdienen besondere Aufmerksamkeit, weil sie in Cisco-Häusern regelmäßig zu spät auf den Tisch kommen.

Erstens das Contact Center. Ein UCCX mit ein paar Warteschlangen und einer Handvoll Agenten lässt sich in Teams mit Anrufwarteschlangen und Anrufberechtigungen abbilden. Ein UCCE mit Skript-Logik, Bildschirmintegration und Sprachdialogsystem lässt sich das nicht. Für den zweiten Fall gibt es Contact-Center-Lösungen, die sich an Teams anbinden — über die von Microsoft dokumentierten Integrationsmodelle. Nur ist das ein eigenes Beschaffungs- und Einführungsprojekt mit eigenem Budget und eigener Laufzeit. Wer es als Zeile im Migrationsplan führt, wird die Zeile später bereuen.

Zweitens Jabber. Der gute Teil: In den meisten Häusern nutzt kaum noch jemand Jabber für Chat, weil Teams das längst übernommen hat. Jabber lebt dort nur noch als Softphone weiter. Damit ist die Abschaltung eine reine Kommunikationsaufgabe, keine Migrationsaufgabe. Der weniger gute Teil: Genau diese Doppelnutzung hat oft Kurzwahlen, Rufumleitungen und Gewohnheiten erzeugt, die niemand dokumentiert hat.

Drittens die Ränder. Aufzugtelefon, Türsprechstelle, Fax im Sekretariat, das analoge Gerät in der Werkstatt, der Pförtnerplatz mit besonderer Beschaltung, die Alarmierungsanlage in der Produktion. Diese Geräte sind einzeln banal und in Summe ein Projekt. Bei einem Kunden mit mehreren Standorten haben wir bei der Inventur rund zwei Dutzend solcher Sonderfälle gefunden, von denen exakt drei in der ursprünglichen Projektplanung standen.

WICHTIG Notruf und Standort sind kein Detail, sondern eine Freigabevoraussetzung. In der alten Welt wusste die Anlage, an welchem Switchport welches Telefon hängt und welche Adresse dazugehört. In der neuen Welt sitzt der Client auf einem Notebook, das heute im Büro und morgen zu Hause steht. Teams kennt dafür Notfallstandorte und dynamische Standortermittlung über Netzwerkinformationen — aber das muss konfiguriert und getestet werden. Und es muss dokumentiert werden, bevor die erste Abteilung produktiv geht, nicht danach.

 

Endgeräte: die Frage, die Cisco-Projekte teuer macht

Hier liegt der größte Unterschied zu den anderen Ablöseprojekten unserer Serie. Bei einer alten Alcatel- oder Unify-Anlage ist die Endgerätefrage schnell beantwortet: Die Telefone sind proprietär, sie können kein SIP, sie kommen weg. Fertig. Bei Cisco ist die Antwort komplizierter — und erfreulicherweise oft günstiger.

Skizze 3: Der Entscheidungsweg für jedes einzelne Tischtelefon im Bestand.

MPP-Firmware, SIP Gateway und die Grenzen

Microsoft betreibt mit dem SIP Gateway einen Dienst, der kompatible SIP-Telefone direkt an Teams Phone anmeldet. Auf der offiziellen Kompatibilitätsliste stehen zahlreiche Cisco-Modelle: die 6800er-Serie, die 7800er-Serie, die 8800er-Serie einschließlich des Konferenztelefons 8832, die neueren 9800er-Modelle sowie die analogen Adapter ATA 191 und ATA 192. Für die Nutzung braucht das Gerät Multiplatform-Firmware (MPP), und der Anwender braucht eine Teams-Phone-Lizenz mit Rufnummer.

Das ist die gute Nachricht: Ein erheblicher Teil eures Gerätebestands kann technisch weiterlaufen. Die schlechte Nachricht steht im Kleingedruckten. Microsoft schreibt dazu wörtlich, dass Geräte mit Enterprise-Firmware auf Multiplatform-Firmware umgestellt werden müssen. Diese Konvertierung ist modellabhängig, teils lizenzpflichtig und in jedem Fall eine Handlung pro Gerät. Bei fünfzig Telefonen ist das ein Nachmittag. Bei zweitausend ist es ein Rollout-Projekt mit eigener Logistik.

Am SIP Gateway funktioniert	Am SIP Gateway funktioniert nicht
Anmeldung mit dem Firmenkonto, Ab- und Anmeldung am Gerät	das Teams-Bedienerlebnis mit Kanälen, Chats, Kalender
Anrufe ins Telefonnetz und zu Teams-Anwendern mit Rufnummer	Anrufe zu Anwendern ohne Rufnummer
Halten und Wiederaufnehmen, Stummschaltung, mehrere Gespräche	Präsenzveröffentlichung des Geräts und damit präsenzbasiertes Routing
blinde und begleitete Weiterleitung	Bildschirmfreigabe, Video, Besprechungssteuerung
Voicemail mit Signalisierung neuer Nachrichten	die volle Warteschlangenfunktion für anspruchsvolle Szenarien
Rufumleitung über Funktionscodes, Nicht-stören per Code	eine Bedienlogik, die zum Teams-Client passt
DTMF-Eingaben und Einwahl in Teams-Besprechungen	eine Zukunftsperspektive über die Lebensdauer des Geräts hinaus

 

Unsere Empfehlung nach mehreren solchen Projekten: Nutzt das SIP Gateway bewusst als Brücke, nicht als Ziel. Es rettet euch das Budget im Migrationsjahr und nimmt dem Rollout den Druck. Aber plant die Ablösung dieser Geräte über die folgenden drei bis vier Jahre ein, statt so zu tun, als sei die Endgerätefrage damit erledigt. Und rechnet ehrlich nach: In vielen Büros braucht heute niemand mehr ein Tischtelefon. Ein gutes Headset ist billiger, wird lieber benutzt und macht in der Videobesprechung eine bessere Figur.

TIPP Zählt die Telefone, die wirklich genutzt werden — nicht die, die dastehen. Der Unified CM weiß, wie viele Gespräche über welches Gerät gelaufen sind. Zieht euch die Auswertung der letzten sechs Monate und sortiert nach Nutzung. In unseren Projekten liegt der Anteil der Tischtelefone, über die praktisch kein Gespräch mehr läuft, regelmäßig im zweistelligen Prozentbereich. Diese Geräte brauchen keinen Nachfolger, sondern einen Karton.

 

Room-Systeme und die angenehme Überraschung

Wer in den vergangenen Jahren Besprechungsräume mit Cisco-Technik ausgestattet hat, geht meist davon aus, dass diese Investition mit dem Wechsel zu Teams verloren ist. Das stimmt in vielen Fällen nicht. Cisco bietet für ausgewählte Desk-, Board- und Room-Geräte einen Betriebsmodus als Microsoft Teams Rooms an; diese Geräte sind entsprechend zertifiziert und liefern die gewohnte Teams-Oberfläche mit Ein-Klick-Beitritt.

Zwei Einschränkungen gehören dazu. Erstens gilt das für bestimmte Modelle, nicht für den gesamten Bestand — die Liste ist bei Cisco und Microsoft einsehbar und ändert sich. Zweitens ist das eine Umstellung mit eigener Lizenz- und Verwaltungslogik, keine reine Konfigurationsänderung. Trotzdem: Es lohnt sich, die Raumliste durchzugehen, bevor jemand pauschal Ersatzbeschaffung ins Budget schreibt. Wir haben Projekte gesehen, in denen dieser Punkt allein einen sechsstelligen Betrag gerettet hat.

Die SBC-Frage: CUBE behalten oder neu bauen?

Teams Phone braucht einen Weg ins öffentliche Telefonnetz. Microsoft bietet dafür vier Modelle an, und für Enterprise-Kunden mit vorhandener Cisco-Infrastruktur ist die Auswahl praktisch eine Entscheidung zwischen zwei davon.

Skizze 4: Das Zielbild — drei Wege ans Telefonnetz, einer davon über eigene Hardware.

Direct Routing, Operator Connect, Calling Plan

Modell	Wer liefert was	Passt gut, wenn	Passt schlecht, wenn
Microsoft Calling Plan	Microsoft liefert Zugang, Rufnummern und Minuten	wenige Standorte, einfache Anforderungen, wenig eigenes Personal	ihr bestehende Rufnummernblöcke, Sonderdienste oder eigene Regeln braucht
Operator Connect	ein zertifizierter Carrier bindet sich per Verwaltungsoberfläche an	ihr einen Anbieter aus der Liste wollt und keinen SBC betreiben mögt	ihr Analoggeräte, DECT-Anlagen oder komplexes Routing anschließen müsst
Teams Phone Mobile	ein Mobilfunkanbieter macht die SIM-Nummer zur Teams-Nummer	sehr mobile Belegschaft, eine Nummer für alles	ihr Rufnummern für Warteschlangen und Einwahl braucht — das kann dieses Modell nicht
Direct Routing	ihr betreibt einen zertifizierten SBC, der Carrier liefert den Trunk	Bestandsnummern, Analog- und DECT-Ränder, eigene Wahlregeln, mehrere Standorte	niemand im Haus einen SBC betreiben will und es auch keinen Dienstleister dafür gibt

 

In Enterprise-Umgebungen mit Cisco-Vergangenheit endet diese Tabelle fast immer bei Direct Routing. Nicht aus Prinzip, sondern weil die Ränder es erzwingen: Aufzugtelefone, DECT auf der Fläche, Türsprechstellen, gewachsene Rufnummernblöcke bei einem Carrier, mit dem man zufrieden ist. Diese Dinge wollen an einen SBC, und ein SBC will betrieben werden.

CUBE weiterverwenden — was dafür und was dagegen spricht

Und jetzt kommt der Punkt, den Cisco-Kunden gern übersehen: Der Cisco Unified Border Element steht auf Microsofts Liste der für Direct Routing zertifizierten Session Border Controller. Aufgeführt sind CUBE-Varianten auf den Integrated Services Routern der 1000er- und 4000er-Serie, auf dem Cloud Services Router 1000V, auf den Aggregation Services Routern der 1000er-Serie und auf den Catalyst-8000-Edge-Plattformen, jeweils ab bestimmten IOS-XE-Versionen. Media Bypass wird unterstützt.

Das heißt im Klartext: Ihr könnt euren vorhandenen SIP-Übergang unter Umständen weiterverwenden, statt neue Hardware zu beschaffen. Ob ihr das solltet, ist eine andere Frage.

Dafür spricht	Dagegen spricht
Die Hardware ist da und abgeschrieben, der Trunk hängt bereits dran	Das Wissen im Haus ist auf CUCM-Betrieb ausgerichtet, nicht auf Teams-Direct-Routing
Das Netzwerkteam kennt die Plattform und die Kommandozeile	IOS-XE-Version, Lizenzstand und Leistungsreserven müssen zur Zertifizierung passen — das ist zu prüfen, nicht anzunehmen
Ein Parallelbetrieb von CUCM und Teams über denselben Übergang ist elegant lösbar	In der Liste der SBC mit ELIN-Fähigkeit für Notrufe ist CUBE nicht vermerkt — für Szenarien mit dieser Anforderung ist das relevant
Kein neuer Beschaffungsvorgang, kein neuer Hersteller im Haus	Wer den CUCM abschalten will, schleppt ein Stück Altwelt weiter — inklusive Wartungsvertrag

 

FAKTEN Aus dem eigenen Betrieb, damit du weißt, woher diese Einschätzung kommt: Wir betreiben unsere eigene Teams-Telefonie über Direct Routing mit einem anynode-SBC von TE-SYSTEMS und SIP-Trunks von easybell. anynode steht ebenfalls auf Microsofts Zertifizierungsliste, unterstützt Media Bypass und Local Media Optimization. Das ist kein Werbeblock, sondern der Grund, warum wir bei Fehlersuche, Zertifikatswechseln und den Eigenheiten der SIP-Signalisierung nicht aus dem Datenblatt zitieren müssen. Für die Entscheidung heißt das: Wenn euer Netzwerkteam den CUBE ohnehin betreut und die Voraussetzungen erfüllt sind, ist CUBE ein guter Weg. Wenn ihr eine saubere Trennung zur Altwelt wollt und niemand Lust auf IOS-XE hat, ist ein eigenständiger SBC oft der ruhigere Betrieb. Beides ist vertretbar. Nur bitte nicht beides gleichzeitig, für unterschiedliche Standorte, ohne dass es jemand aufgeschrieben hat.

 

WARNUNG Nicht zertifiziert bedeutet: kein Microsoft-Support. Microsoft unterstützt Direct Routing ausdrücklich nur mit zertifizierten Geräten und behält sich vor, Supportfälle mit nicht zertifizierter Hardware abzulehnen. Wer bei einer Störung eskalieren will, muss zudem einen Untersuchungsbericht des SBC-Herstellers vorlegen. Prüft deshalb Modell und Firmware-Stand gegen die aktuelle Liste, bevor ihr baut — nicht, wenn der erste Ausfall da ist.

 

Der Fahrplan: von der Entscheidung bis zum Abschalttag

Wenn beide Fragen beantwortet sind und das Zielbild steht, wird aus der Strategiedebatte ein ganz normales Projekt. Ein großes, aber ein planbares.

Skizze 5: Sechs Phasen. Die Angaben sind Erfahrungswerte aus Projekten vergleichbarer Größe.

Phasen und realistische Dauer

Die Zeitangaben in der Skizze gelten für ein Unternehmen mit mehreren hundert bis wenigen tausend Anwendern und mehreren Standorten. Kleinere Häuser sind schneller, Konzerne mit Betriebsvereinbarungen in jedem Land sind langsamer. Drei Erfahrungswerte, die sich in fast jedem Projekt bestätigen:

Der Pilot ist keine Formsache. Nehmt dreißig bis fünfzig Leute aus mindestens drei verschiedenen Bereichen — Zentrale, Außendienst, Produktion oder Fläche. Wer nur die IT-Abteilung pilotiert, pilotiert die einzige Gruppe, die ohnehin keine Probleme hat.

Der Rollout skaliert über Wellen, nicht über Wochenenden. Standort für Standort, Abteilung für Abteilung, mit Rückfallmöglichkeit. Die Versuchung, alles an einem Wochenende umzuschalten, ist bei Telefonie besonders groß und besonders falsch.

Die Schulung entscheidet über die Akzeptanz. Nicht die Technik. Wer der Belegschaft ein neues Telefon hinstellt und eine PDF-Anleitung schickt, erntet Beschwerden über die Plattform, die in Wahrheit Beschwerden über die Einführung sind. Zwanzig Minuten live pro Team wirken mehr als jedes Handbuch.

Koexistenz ohne Dauerprovisorium

Zwischen Phase 2 und Phase 5 laufen zwei Anlagen parallel. Das ist normal und technisch gut lösbar: Ein SIP-Trunk zwischen CUCM und Teams — über den CUBE — sorgt dafür, dass die interne Erreichbarkeit in beide Richtungen funktioniert, während die Belegschaft schrittweise wechselt. Cisco und Microsoft dokumentieren dieses Zusammenspiel jeweils auf ihrer Seite.

Was in diesem Zustand schiefgeht, ist selten technisch. Es sind drei Dinge:

Der Rufnummernplan hat plötzlich zwei Quellen der Wahrheit. Legt vorher fest, welches System führt — und haltet euch daran.

Kurzwahlen und Sonderrufnummern funktionieren nur in einer der beiden Welten. Wenn die Zentrale nicht mehr per Kurzwahl erreichbar ist, ist der Projektfrieden innerhalb eines Vormittags aufgebraucht.

Der Parallelbetrieb bekommt kein Enddatum. Aus geplanten vier Monaten werden zwei Jahre mit zwei Wartungsverträgen, zwei Störungswegen und einer Belegschaft, die nicht mehr weiß, wo sie anrufen soll.

Kostenblöcke, die im Business Case gern fehlen

Block	Wird oft vergessen, weil	Größenordnung
Firmware-Konvertierung der Telefone	„die Geräte laufen doch weiter“ — technisch ja, aber pro Gerät	Arbeitszeit je Gerät plus Logistik, bei großen Beständen erheblich
Contact Center	wird als Teil der Telefonie gesehen, ist aber ein eigenes Produkt	eigenes Projekt mit eigenem Budget
CTI-Kopplungen an Fachverfahren	der Hersteller der Branchensoftware sitzt nicht mit am Tisch	Lizenz- oder Modulkosten plus Test
Analoge und DECT-Ränder	sie stehen in keiner Lizenzliste	Gateways, Montage, teils Kabelarbeiten
Parallelbetrieb	im Plan stehen vier Monate, in der Realität werden es mehr	doppelte Betriebskosten je Monat Verzug
Schulung und Begleitung	„Teams kennen doch alle“ — den Chat ja, die Telefonie nein	meist unterschätzt, zahlt sich am stärksten aus
Notruf- und Standortkonzept	in der Altwelt hat es sich von selbst ergeben	Konzept, Konfiguration, Test, Dokumentation

 

WICHTIG Setzt den Abschalttag, bevor der Rollout beginnt. Ein Datum im Protokoll, an dem der Unified CM aus geht, ist das wirksamste Steuerungsinstrument des gesamten Projekts. Es zwingt jede Sonderlocke, sich rechtzeitig zu melden. Ohne dieses Datum meldet sie sich erst, wenn ihr die Anlage abschalten wollt — und dann verschiebt sich alles um ein Quartal.

 

Häufige Fragen

Können wir unsere Cisco-Telefone an Teams Phone weiterbetreiben?

Viele davon ja, über das Teams SIP Gateway. Auf Microsofts Kompatibilitätsliste stehen unter anderem die Cisco-Serien 6800, 7800 und 8800 sowie neuere Modelle und die analogen Adapter ATA 191 und 192. Voraussetzung ist Multiplatform-Firmware auf dem Gerät und eine Teams-Phone-Lizenz mit Rufnummer für den Anwender. Geräte mit Enterprise-Firmware müssen dafür konvertiert werden. Der Funktionsumfang ist auf Kerntelefonie beschränkt: Anrufe, Halten, Weiterleiten, Voicemail, Rufumleitung, DTMF, Einwahl in Besprechungen. Kein Teams-Bedienerlebnis, keine Präsenzveröffentlichung.

Sollten wir stattdessen einfach zu Webex Calling wechseln?

Das kann die richtige Antwort sein — und niemand sollte dir etwas anderes erzählen. Webex Calling ist für Cisco-Bestandskunden der kürzere Weg: Geräteinvestitionen bleiben erhalten, die funktionale Nähe zum Unified CM ist am größten, und Cisco bietet Migrationswege bis hin zur Dedicated Instance, die eine UCM-basierte Umgebung als Cloud-Dienst bereitstellt. Die Gegenrechnung lautet: zwei Kollaborationsplattformen im Haus, zwei Lizenzstämme, zwei Administrationswelten. Rechnet beides über fünf Jahre durch, dann entscheidet eine Zahl und keine Meinung. Der ausführliche Plattformvergleich steht im Beitrag zu Teams, Zoom und Webex.

Können wir unseren CUBE als SBC für Teams weiterverwenden?

Ja, sofern Plattform und Softwarestand passen. Der Cisco Unified Border Element steht auf Microsofts Liste der zertifizierten Session Border Controller für Direct Routing, unter anderem für die Integrated Services Router der 1000er- und 4000er-Serie, den Cloud Services Router 1000V, die Aggregation Services Router der 1000er-Serie und die Catalyst-8000-Edge-Plattformen — jeweils ab definierten IOS-XE-Versionen. Media Bypass wird unterstützt. Prüft Modell, Version, Lizenz und Leistungsreserven gegen die aktuelle Liste, bevor ihr plant.

Was passiert mit Voicemail und den gespeicherten Nachrichten?

Teams bringt eine eigene Voicemail mit Transkription mit; funktional ist das für die meisten Anwender ein Fortschritt. Die in Unity Connection gespeicherten Nachrichten wandern jedoch nicht mit. Plant eine Übergangsfrist, in der beide Systeme erreichbar sind, informiert die Belegschaft rechtzeitig, und klärt vorher, ob es Bereiche gibt, in denen Sprachnachrichten aufbewahrungspflichtig sind. Ansagen und Auto-Attendant-Texte müsst ihr neu aufnehmen oder neu erzeugen — das ist Fleißarbeit, aber eine gute Gelegenheit, veraltete Menüs auszumisten.

Wie lange dauert so eine Migration realistisch?

Für ein Unternehmen mit mehreren hundert bis wenigen tausend Anwendern und mehreren Standorten rechnen wir von der getroffenen Entscheidung bis zum Abschalten des Clusters mit etwa neun bis achtzehn Monaten. Der größte Einzelposten ist nicht die Technik, sondern der Rollout in Wellen samt Schulung. Wer schneller sein will, muss die Sonderfälle früher angehen — die Ränder bestimmen den Endtermin, nicht der Hauptstrom.

Behalten wir unsere Rufnummern?

Ja. Mit Direct Routing bleiben eure Rufnummernblöcke beim vorhandenen Carrier, und ihr müsst nicht einmal portieren — der Trunk zeigt künftig auf den SBC statt auf die alte Anlage. Bei Operator Connect wechselt ihr zu einem Anbieter aus Microsofts Programm, bei Calling Plan zu Microsoft selbst; in beiden Fällen ist eine Portierung erforderlich. Genau deshalb entscheiden sich Häuser mit gewachsenen Nummernbeständen so häufig für Direct Routing.

Was ist mit unserem Contact Center auf UCCX oder UCCE?

Das ist ein eigenes Projekt, kein Nebenschauplatz. Einfache Szenarien mit Warteschlangen und wenigen Agenten lassen sich in Teams selbst abbilden. Alles mit Skript-Logik, Bildschirmintegration, Sprachdialog oder anspruchsvoller Auswertung braucht eine dedizierte Contact-Center-Lösung, die an Teams angebunden wird. Plant dafür eigenes Budget, eigene Laufzeit und eigene Beteiligte aus dem Fachbereich ein.

Läuft Telefonie noch, wenn die Internetanbindung ausfällt?

Bei einer Cloud-Telefonie hängt die Anrufsteuerung im Rechenzentrum des Anbieters — fällt die Anbindung aus, fällt die Telefonie aus. Für Standorte, an denen das nicht hinnehmbar ist, gehört das in die Anforderungsliste: redundante Anbindung über getrennte Wege, Mobilfunk als Rückfallebene, Weiterleitung eingehender Rufnummern auf Mobilnummern im Störungsfall, gegebenenfalls ein lokales Notfallszenario am SBC. Das ist lösbar, aber es kostet Geld und muss vor der Entscheidung besprochen werden, nicht nach dem ersten Ausfall.

Brauchen wir für den Wechsel externe Unterstützung?

Nicht zwingend. Wer ein eingespieltes Team mit SIP-Erfahrung hat, schafft das selbst. Erfahrungsgemäß lohnt externe Hilfe an drei Stellen besonders: bei der Entscheidungsvorbereitung, weil ein neutraler Blick auf Frage 1 und Frage 2 Monate spart; beim Fundament aus SBC, Trunk und Notrufkonzept, weil Fehler dort später teuer werden; und bei der Inventur der Ränder, weil erfahrene Leute wissen, wonach sie suchen müssen. Genau dafür gibt es unsere Beratung zur Teams-Telefonie.

Fazit

Der Wechsel von Cisco Unified CM zu Microsoft Teams Phone ist technisch gut machbar und in vielen Häusern wirtschaftlich sinnvoll. Er unterscheidet sich aber von jeder anderen TK-Ablösung durch eine Besonderheit: Cisco hat mit Webex Calling eine echte Alternative im Angebot. Wer diese Doppelentscheidung nicht sauber trennt, diskutiert lange und entscheidet spät.

Also der Reihe nach. Erst prüfen, ob die vorhandene Plattform noch drei bis fünf Jahre trägt — Lifecycle, Lizenz, Hardware, Personal. Falls ja: renovieren und in drei Jahren erneut prüfen. Falls nein: die zweite Frage anhand einer Fünfjahresrechnung entscheiden, nicht anhand von Präferenzen. Und wenn die Antwort Teams Phone lautet, dann wisst ihr aus diesem Artikel, wo die Arbeit wirklich liegt: nicht im Umzug der Anrufsteuerung, sondern in den Endgeräten, im Contact Center, in den Rändern und in einem Notrufkonzept, das jemand aufschreiben muss.

Die gute Nachricht für Cisco-Kunden: Ihr startet nicht bei null. Der CUBE darf als zertifizierter SBC bleiben, ein großer Teil der Tischtelefone läuft über das SIP Gateway weiter, und ausgewählte Room-Systeme sind als Teams Rooms zertifiziert. Von allen Altanlagen, die wir in dieser Serie behandeln, ist Cisco diejenige, bei der am meisten stehen bleiben darf.

Der eine Satz zum Mitnehmen: Beantwortet Frage 1 und Frage 2 nacheinander und mit Datum — dann ist der Rest Projektarbeit. Den Überblick über die Plattform findest du im Beitrag zur Teams-Telefonie, den direkten Plattformvergleich im Artikel zu Teams, Zoom und Webex, und wenn ihr die Entscheidung und den Fahrplan gemeinsam erarbeiten wollt, hilft unsere Beratung zur Teams-Telefonie. Für andere Anlagen im Haus gibt es die Schwesterartikel zu Avaya, Unify OpenScape und Mitel.

Quellen

Alle Angaben mit Stand 2. September 2026. Lifecycle-, Lizenz- und Zertifizierungsangaben ändern sich laufend; prüfe sie vor jeder Beschaffung und vor jeder Entscheidung an der Primärquelle nach.

Microsoft Learn: PSTN connectivity options for Teams Phone — https://learn.microsoft.com/en-us/microsoftteams/pstn-connectivity

Microsoft Learn: Plan SIP Gateway — kompatible Geräte und Funktionsumfang — https://learn.microsoft.com/en-us/microsoftteams/devices/sip-gateway-plan

Microsoft Learn: Configure SIP Gateway — https://learn.microsoft.com/en-us/microsoftteams/devices/sip-gateway-configure

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

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

Cisco: Umstellung von Enterprise- auf Multiplatform-Firmware (Conversion Guide) — https://www.cisco.com/c/en/us/products/collateral/collaboration-endpoints/unified-ip-phone-7800-series/guide-c07-742786.html

Cisco: End-of-Life- und End-of-Sale-Bekanntmachungen für Unified CM — https://www.cisco.com/c/en/us/products/unified-communications/unified-communications-manager-callmanager/eos-eol-notice-listing.html

Cisco: End-of-Sale und End-of-Life für Version 14 der On-Premises-Calling-Anwendungen — https://www.cisco.com/c/en/us/products/collateral/unified-communications/unified-communications-manager-callmanager/v-14-premises-calling-applications-eol.html

Cisco: End-of-Sale und End-of-Life für Version 12.5 der On-Premises-Calling-Anwendungen — https://www.cisco.com/c/en/us/products/collateral/unified-communications/unified-communications-manager-callmanager/v-12-5-on-premises-calling-applications-eol.html

Cisco: Direct Routing für Microsoft Phone System mit CUBE (Interoperabilitätsleitfaden) — https://www.cisco.com/c/dam/en/us/solutions/collateral/enterprise/interoperability-portal/direct-routing-with-cube.pdf

Cisco: Direct Routing für Unified Communications Manager über CUBE — https://www.cisco.com/c/dam/en/us/solutions/collateral/enterprise/interoperability-portal/direct-routing-for-communications-manager-via-cube.pdf

Webex Help Center: Einführung in Dedicated Instance — https://help.webex.com/en-us/article/dk3o5r/Introduction-to-Dedicated-Instance

Webex Help Center: Migration von Unified CM zu Webex Calling — https://help.webex.com/en-us/article/x974bd/Migrate-Unified-CM-to-Webex

Cisco: Geräte für Microsoft Teams Rooms — https://www.webex.com/us/en/solutions/microsoft-teams-rooms-cisco-devices.html

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

easybell: SIP-Trunks mit Microsoft Teams nutzen — https://www.easybell.de/microsoft-teams-connector/easybell-sip-trunks-mit-microsoft-teams-nutzen/