Von Skype for Business Server zu Teams-Telefonie

Du gehörst zu einer aussterbenden Art. Nicht im dramatischen Sinne — dein Laden läuft, die Telefonie funktioniert, und wahrscheinlich funktioniert sie sogar besser als das, was manche Häuser mit einer nagelneuen Cloud-Lösung hinbekommen haben. Aber die Zahl der Organisationen, die im Jahr 2026 noch einen Skype for Business Server mit Enterprise Voice betreiben, ist überschaubar geworden. Und sie schrumpft weiter, Quartal für Quartal, ob du willst oder nicht.

Das Bemerkenswerte daran: Ihr seid nicht die Nachzügler, für die euch der Vertrieb hält. Ihr seid die Leute, die vor zehn Jahren etwas gebaut haben, das damals kaum jemand verstanden hat — SIP-Trunks statt ISDN, Software statt Kartenschrank, Präsenz statt Blinklicht. Ihr habt die Konzepte verinnerlicht, über die andere heute in Workshops stolpern. Genau deshalb ist eure Migration nach Teams technisch die einfachste, die es gibt. Und genau deshalb ist sie organisatorisch trotzdem eine, die schiefgehen kann.

Denn eure Ausgangslage hat einen Haken: Ihr habt in den vergangenen Jahren gelernt, dass sich Entscheidungen vertagen lassen. Der Server lief ja. Das In-Place-Upgrade auf die Subscription Edition hat noch einmal Luft verschafft. Nur ändert das nichts daran, dass ihr am Ende dieselbe Frage beantworten müsst wie alle anderen auch — nur mit deutlich besseren Karten.

Dieser Artikel ist der Fahrplan dafür: Welche Voice-Workloads du wie migrierst, was mit den Rufnummern passiert, und warum dein bestehender Session Border Controller wahrscheinlich der Grund ist, weshalb du die sanfteste Migration aller TK-Ablösungen fahren kannst. Wenn du zuerst den Überblick über alle Anbindungsarten und Bausteine der Teams-Telefonie brauchst, findest du ihn im

Pillar-Beitrag zur Teams-Telefonie — dieser Artikel setzt darauf auf und geht in die Tiefe.

FAKTEN Skype for Business Server 2015 und 2019: Support endete am 14. Oktober 2025. Kein Support, keine Fehlerbehebung, keine Sicherheitsupdates mehr. Skype for Business Server Subscription Edition (SE) ist seit dem dritten Quartal 2025 verfügbar und die einzige weiterhin unterstützte On-Premises-Version. Der Wechsel von 2019 erfolgt als In-Place-Upgrade und fühlt sich an wie ein Cumulative Update; von 2015 ist das In-Place-Upgrade verpflichtend. Skype for Business Online wurde am 31. Juli 2021 abgeschaltet. Das ändert nichts daran, dass Hybrid-Konnektivität weiterhin die Voraussetzung ist, um Anwender aus der On-Premises-Welt nach TeamsOnly zu bewegen. Lizenzmodell von SE: Subscription-Lizenzen oder Lizenzen mit aktiver Software Assurance — für Server und Anwender. Konkrete Konditionen bitte im eigenen Vertrag prüfen.

 

Standortbestimmung: Wo genau steht dein Server?

Bevor irgendjemand über Migrationspfade redet, gehört eine Frage beantwortet, die erstaunlich oft im Ungefähren bleibt: In welchem Zustand ist die Plattform eigentlich, die abgelöst werden soll? Die Antwort entscheidet nämlich nicht darüber, wohin ihr geht — sondern darüber, wie viel Ruhe ihr dabei habt.

Drei typische Ausgangslagen. Der Unterschied liegt nicht im Ziel, sondern im Tempo, das euch aufgezwungen wird.

Die drei Zustände, in denen wir Häuser antreffen

Der erste Fall ist der unangenehme: Server 2015 oder 2019, außerhalb des Supports, weil das Upgrade auf SE nie priorisiert wurde. Fachlich läuft alles. Formal steht ihr im Regen — und zwar an genau der Stelle, an der euch die Cyberversicherung im Schadensfall die Frage stellt, warum ein PSTN-angebundenes, aus dem Internet erreichbares System ohne Sicherheitsupdates betrieben wurde. Diese Frage möchte niemand beantworten müssen.

Der zweite Fall ist der komfortable: Das In-Place-Upgrade auf SE ist gelaufen, die Lizenzierung stimmt, alles ist unterstützt. Ihr habt euch Luft verschafft — und das war eine völlig legitime Entscheidung. Nur solltet ihr diese Luft jetzt auch nutzen, statt sie zu verbrauchen. Eine Migration im eigenen Takt ist etwas grundlegend anderes als eine Migration unter Druck.

Der dritte Fall ist der häufigste und der teuerste: Hybrid steht seit Jahren, ein Teil der Belegschaft arbeitet längst in Teams, aber die Telefonie hängt weiter am Mediation Server On-Premises. Zwei Plattformen, zwei Rufnummernpläne, zwei Fehlerbilder — und in der Praxis niemand mehr, der aus dem Stand sagen kann, wo ein eingehender Anruf tatsächlich landet. Dieser Zwischenzustand ist als Projektphase völlig in Ordnung. Als Dauerzustand ist er ein Kostenfresser.

Ausgangslage	Was das praktisch bedeutet	Nächster Schritt	Zeitdruck
Server 2015 oder 2019, außer Support	Keine Sicherheitsupdates, kein Herstellersupport, dokumentierbares Risiko	Entweder sofort In-Place-Upgrade auf SE oder direkt Migrationsprojekt aufsetzen	Hoch
Server SE, aktuell gepatcht	Unterstützt, aber laufende Subscription- bzw. SA-Kosten	Migrationsprojekt planen und terminieren, solange ihr die Wahl habt	Mittel
Hybrid, Anwender teilweise in Teams, Voice On-Prem	Doppelter Betrieb, doppelte Fehlersuche, unklare Zuständigkeiten	Voice-Migration priorisieren und ein Enddatum festlegen	Hoch (wirtschaftlich)
Hybrid vollständig, alle Anwender online, Server läuft noch	Der Server hält nur noch Anwendungsendpunkte und DNS-Einträge am Leben	Decommissioning durchziehen — DNS, Endpunkte, Abbau	Mittel

 

Warum ihr besser dasteht als jeder TK-Anlagen-Betreiber

Wer heute von einer klassischen Telefonanlage nach Teams migriert, muss zuerst eine Sprache lernen. SIP, Rufnummernnormalisierung, Codecs, Medienpfade, TLS-Zertifikate am Session Border Controller — das ist bei Avaya, Unify oder Alcatel-Lucent oft ein monatelanger Erkenntnisprozess, bevor überhaupt ein Anwender umzieht. Ihr habt das alles bereits im Haus.

Euer Rufnummernplan ist dokumentiert. Er steht in Dial Plans, Normalisierungsregeln und LineURIs — maschinenlesbar, nicht auf einem Zettel im Technikraum.

Euer Voice Routing ist explizit. VoicePolicy, PSTN Usages und Voice Routes lassen sich fast eins zu eins in die Online-Welt spiegeln. Genau das ist der Plan.

Euer SIP-Trunk existiert schon. Und er terminiert wahrscheinlich auf einem Session Border Controller, der Direct Routing ohnehin beherrscht.

Euer Hybrid ist halb gebaut. Verzeichnissynchronisierung, Domänen, Zertifikate — das steht meist. Es fehlt der letzte Schritt, nicht der erste.

Eure Belegschaft kennt Software-Telefonie. Kein Mensch muss lernen, dass man über den Rechner telefonieren kann. Das war 2016 die eigentliche Hürde.

TIPP Bevor du irgendetwas migrierst: Exportiere den kompletten Ist-Zustand aus der On-Premises-Verwaltung. Alle Anwender mit LineURI und Voice Policy, alle Response Groups mit Agentenlisten, alle Common Area Phones, alle Anwendungsendpunkte, alle Dial Plans und Voice Routes. Diese Auswertung ist keine Fleißarbeit für später — sie ist die Grundlage für jede Aufwandsschätzung, jedes Angebot und jeden Testplan. Und sie ist der einzige Zeitpunkt im Projekt, an dem du sie noch bequem bekommst.

 

Die Frage vor allen anderen: SE behalten oder nach Teams?

Es gibt Häuser, für die Skype for Business Server SE die richtige Plattform bleibt — und das ist kein Trotz, sondern eine begründete Entscheidung. Harte Anforderungen an lokale Datenhaltung, aufsichtsrechtliche Vorgaben, Telefonie-Szenarien, die zwingend an lokale Leitungen gebunden sind, oder eine Infrastruktur, die aus guten Gründen nicht am Internet hängt. Wer solche Gründe hat, sollte sich von niemandem in die Cloud reden lassen.

Wer sie nicht hat, sollte sich umgekehrt nicht einreden, er hätte sie. Die ehrliche Gegenüberstellung beider Wege — mit Kriterien statt Bauchgefühl — steht in der Entscheidungsmatrix SE oder Teams. Wenn dabei herauskommt, dass ihr zunächst auf SE bleibt: Das In-Place-Upgrade-Playbook und die Hinweise zu Lizenzierung und Software Assurance führen euch dort sauber hin. Dieser Artikel geht ab hier den anderen Weg.

WICHTIG Die schlechteste aller Varianten ist keine der beiden. Sie heißt „wir schauen erst mal, wie sich das entwickelt“ — und sie kostet euch beides: die Sicherheit einer unterstützten Plattform und den Vorlauf für ein geordnetes Projekt. Beide Wege sind vertretbar. Der dritte ist es nicht.

 

Es gibt nicht „die Telefonie“ — es gibt ein Dutzend Workloads

Der teuerste Satz in jedem Migrationsprojekt lautet: „Wir stellen die Telefonie um.“ Er klingt nach einem Vorgang. Tatsächlich verbergen sich dahinter ein Dutzend völlig unterschiedlicher Dinge, die alle unterschiedlich migrieren — manche automatisch, manche gar nicht, und manche nur mit einem Bestellvorgang und einem Handwerker.

Die eigentliche Projektlandkarte. Wer nur die linke Spalte plant, unterschätzt das Projekt um den Faktor drei.

Was mit dem Anwender mitzieht

Die gute Nachricht zuerst. Wenn du einen Anwender mit den On-Premises-Werkzeugen in die Cloud verschiebst, kommt einiges automatisch mit. Der Umzug selbst ist inzwischen ein einziger Schritt, unabhängig davon, welche Serverversion ihr fahrt. Die Besprechungen des Anwenders werden dabei automatisch in Teams-Besprechungen umgewandelt — und zwar unabhängig davon, ob der frühere Schalter für den Wechsel nach TeamsOnly ausdrücklich mitgegeben wird oder nicht. Anwender landen beim Umzug automatisch in TeamsOnly.

Auch die Rufnummer geht nicht verloren: Was On-Premises als LineURI gepflegt war, wird zur Rufnummernzuweisung im Tenant. Und die Kontaktliste zieht ebenfalls um. Das ist der Teil des Projekts, der sich mit einem gut vorbereiteten Skript und einem Wartungsfenster erledigen lässt.

Was du von Hand neu bauen musst — und das ist der große Brocken

Und jetzt die andere Seite. Für Response Groups gibt es keinen Migrationsmechanismus. Es gibt in der Cloud schlicht keinen Response-Group-Dienst; die Entsprechung heißt Auto Attendant und Call Queue, und der Anruffluss muss dort neu modelliert werden. Bei einem Haus mit fünf Warteschlangen ist das ein Nachmittag. Bei einem Haus mit sechzig gewachsenen Response Groups, die seit 2014 niemand mehr angefasst hat, ist es ein Teilprojekt — und häufig der beste Anlass, endlich aufzuräumen.

Der zweite Brocken ist unspektakulärer und wird deshalb regelmäßig übersehen: Rufumleitungen, Teamanrufgruppen und Delegierungen aus der alten Welt werden nicht mitgenommen. Sie müssen in Teams neu eingerichtet werden. Das ist technisch trivial und organisatorisch heikel, weil es genau die Leute trifft, die am lautesten sind, wenn etwas nicht geht: Empfang, Sekretariate, Geschäftsführung.

WARNUNG Rufumleitungen, Teamanrufgruppen und Delegierungseinstellungen aus Skype for Business werden bei der Migration nicht übernommen. Sie müssen in Teams neu eingerichtet werden. Praktische Konsequenz: Erfasse diese Einstellungen VOR dem Umzug pro Anwender und richte sie unmittelbar danach wieder ein — im Idealfall automatisiert und in derselben Wartungsstunde. Wer das auf „melden Sie sich, wenn etwas fehlt“ verschiebt, produziert genau die Störungsmeldungen, an denen die Akzeptanz des gesamten Projekts hängt.

 

Dazu kommen die Dinge, die nie jemand als Migrationsobjekt auf dem Zettel hat: die Ansagen und Grußworte in der Voicemail, die Vertretungsregeln im Chefsekretariat, die Kurzwahlen am Empfangsplatz, die Normalisierungsregeln für die Standorte, die man vor Jahren einmal fein austariert hat. Nichts davon ist schwierig. Alles davon kostet Zeit, die im Plan stehen muss.

Workload On-Premises	Entsprechung in Teams	Zieht automatisch mit?	Realistischer Aufwand
Enterprise Voice des Anwenders	Teams Phone mit Direct Routing oder Calling Plan	Ja, beim Umzug des Kontos	Gering, skriptbar
LineURI / Rufnummer	Rufnummernzuweisung im Tenant	Ja, wird übernommen	Gering
Besprechungen	Teams-Besprechungen	Ja, werden automatisch konvertiert	Gering
Kontaktliste	Kontakte in Teams	Ja	Gering
Rufumleitung, Teamanrufgruppe, Delegierung	Gleichnamige Funktionen in Teams	Nein	Mittel — pro Anwender erfassen und nachziehen
Response Group	Auto Attendant und Call Queue	Nein, kein Migrationspfad	Hoch — Anrufflüsse komplett neu modellieren
Dial Plan, Normalisierungsregeln	Tenant Dial Plan	Nein, aber ableitbar	Mittel
VoicePolicy, PSTN Usage, Voice Route	OnlineVoiceRoutingPolicy, OnlinePSTNUsage, OnlineVoiceRoute	Nein, aber spiegelbar	Mittel — einmalig, dann stabil
Voicemail-Ansagen	Cloud Voicemail	Nein	Gering bis mittel
3PIP-Telefone (Lync/SfB-Firmware)	SIP Gateway oder Teams-zertifiziertes Gerät	Nein	Hoch — Prüfung, ggf. Beschaffung
Analoge Apparate, Fax, Türsprechstelle, Aufzug	Analog-Gateway am SBC	Nein	Hoch — Hardware und Vor-Ort-Arbeit
Gemeinschaftstelefone, Konferenzräume	Teams-Telefone, Teams Rooms	Nein	Mittel bis hoch, budgetrelevant

 

Die Ränder: Analog, DECT und die alten Tischtelefone

Hier liegt bei fast allen Projekten der größte Einzelposten — und er ist selten eine Frage der Software. Eure alten Tischtelefone mit Lync- oder Skype-for-Business-Firmware können nicht ohne Weiteres in die Teams-Welt wechseln. Der von Microsoft vorgesehene Weg für kompatible Geräte ist das SIP Gateway: Das Telefon meldet sich mit dem Firmenkonto an und kann telefonieren, halten, weiterleiten, Voicemail signalisieren und sich in Besprechungen einwählen. Was es nicht kann, ist ein Teams-Bedienerlebnis liefern — und Präsenz veröffentlicht es auch nicht.

TIPP Behandle das SIP Gateway als Brücke, nicht als Zielbild. Es rettet dir das Budget im ersten Jahr und nimmt Druck aus dem Rollout — aber es schreibt die Frage nach der Endgerätestrategie nur in die Zukunft. Prüfe für jedes Modell im Bestand konkret die Unterstützung und die benötigte Firmware, bevor du mit Stückzahlen rechnest. Herstellerlisten und Microsoft-Dokumentation ändern sich; verlasse dich hier nicht auf Erinnerungen aus einem früheren Projekt.

 

Und dann sind da die Geräte, die gar nicht nach Telefon aussehen. Der Aufzugsnotruf. Das Alarmwählgerät der Brandmeldeanlage. Die Türsprechstelle am Lieferanteneingang. Das Faxgerät in der Rechtsabteilung, das seit Jahren nur noch Werbung empfängt und trotzdem nicht abgeschafft werden darf. Diese Dinge hängen an analogen Ports, und sie brauchen ein Analog-Gateway — meist am selben Session Border Controller, der ohnehin schon im Haus steht.

Das ist übrigens genau die Stelle, an der ein Projekt aufhört, ein IT-Projekt zu sein, und anfängt, ein Gebäudeprojekt zu werden. Wer damit keine Erfahrung hat, plant hier regelmäßig zu knapp. Der Überblick über die Migration von der TK-Anlage zu Teams Phone geht auf diese Randbereiche ausführlicher ein.

Der Migrationspfad: Hybrid, Direct Routing, Umzug

Jetzt zur eigentlichen Mechanik. Sie ist erfreulich klar dokumentiert und erfreulich wenig überraschend — vorausgesetzt, man hält die Reihenfolge ein. Und genau daran scheitern die meisten Fehlversuche: nicht an einem falschen Befehl, sondern an einer falschen Reihenfolge.

Drei Zustände am selben SIP-Trunk. Der mittlere ist kein Unfall, sondern der geplante Normalbetrieb während der gesamten Migration.

Hybrid ist Pflicht — auch nach dem Ende von Skype for Business Online

Das ist der Punkt, an dem regelmäßig Verwirrung entsteht. Skype for Business Online ist seit Juli 2021 abgeschaltet. Trotzdem bleibt die Hybrid-Konnektivität zwischen eurem Server und Microsoft 365 die zwingende Voraussetzung, um Anwender überhaupt nach TeamsOnly bewegen zu können. Ohne Hybrid gibt es keinen Umzug — und ohne Umzug keinen TeamsOnly-Modus.

Damit hängen zwei weitere Punkte zusammen, die im Projekt früh geklärt gehören. Erstens: Eure Anwender müssen mit den korrekten Skype-for-Business-Attributen nach Microsoft Entra ID synchronisiert sein — den Attributen mit dem Präfix „msRTCSIP-“. Passiert das nicht sauber, könnt ihr diese Anwender aus den Teams-Werkzeugen heraus schlicht nicht verwalten und ihnen keine Richtlinien zuweisen. Zweitens: Solange noch Anwender On-Premises sitzen, muss ein neu angelegtes Konto zuerst On-Premises aktiviert und dann umgezogen werden — sonst können die verbliebenen Anwender der alten Welt es nicht erreichen.

Wie die Hybrid-Anbindung sauber aufgesetzt wird und worauf bei der dedizierten Hybrid-Anwendung zu achten ist, steht ausführlich im Beitrag zur Dedicated Hybrid Application für Skype for Business.

Die Online-Konfiguration ist ein Spiegel deiner On-Prem-Welt

Hier kommt der Teil, der euch das Leben leichter macht als allen anderen. Die Voice-Routing-Konfiguration für Direct Routing ist im Kern eine Spiegelung dessen, was ihr On-Premises bereits gebaut habt. Ihr müsst kein Konzept erfinden, ihr müsst ein bestehendes übersetzen.

On-Premises-Objekt	Entsprechung online	Hinweis für die Übersetzung
VoicePolicy	OnlineVoiceRoutingPolicy	Beim Weg aus der On-Premises-Welt ist die VoicePolicy die Vorlage, nicht die alte VoiceRoutingPolicy
PSTN Usage	OnlinePSTNUsage	Reihenfolge der Usages bestimmt die Routing-Priorität — hier lohnt sich Aufräumen
Voice Route	OnlineVoiceRoute	Reguläre Ausdrücke lassen sich meist übernehmen, sollten aber einmal überprüft werden
Dial Plan / Normalisierung	Tenant Dial Plan	Nur so viele Regeln wie nötig — viele historische Regeln sind schlicht überflüssig geworden
Mediation Server	Direct Routing SBC-Kopplung	Der SBC muss für Direct Routing zertifiziert sein und die passende Firmware fahren
EnterpriseVoiceEnabled (On-Prem)	EnterpriseVoiceEnabled (Cloud)	Eigenschaft, keine Richtlinie — der Wert in der Cloud ist der, der zählt

 

WICHTIG Die Eigenschaft EnterpriseVoiceEnabled ist der klassische Stolperstein. Sie muss in der Cloud auf „wahr“ stehen, damit der Anwender überhaupt telefonieren kann — egal ob Direct Routing oder Calling Plan. Ist der Anwender On-Premises für Enterprise Voice aktiviert UND besitzt er die Phone-System-Lizenz bereits VOR dem Umzug, wird er online korrekt mit EnterpriseVoiceEnabled = wahr bereitgestellt. Wird die Lizenz dagegen erst NACH dem Umzug zugewiesen, passiert das nicht automatisch. Dann muss die Eigenschaft ausdrücklich gesetzt werden — über Set-CsPhoneNumberAssignment mit -EnterpriseVoiceEnabled $True. Merksatz fürs Runbook: Lizenz vor Umzug spart einen Schritt und eine Störungsmeldung pro Anwender.

 

Der Schnitt pro Anwender: drei Dinge, die zusammengehören

Der eigentliche Umschaltmoment besteht aus drei Handlungen, die koordiniert erfolgen müssen. Nicht gleichzeitig auf die Sekunde, aber im selben Zeitfenster — und in einer Reihenfolge, die vorher festgelegt und dann jede Woche identisch wiederholt wird.

Erstens: der Umzug des Kontos. Mit den On-Premises-Werkzeugen wird das Konto in die Cloud verschoben. Der Anwender landet dabei automatisch in TeamsOnly, die Besprechungen werden konvertiert.

Zweitens: die Route am SBC. Eingehende Anrufe für diese Rufnummer müssen ab jetzt nach Direct Routing gehen statt an den Mediation Server. Das ist eine Konfigurationsänderung an genau der Komponente, die euch am vertrautesten ist.

Drittens: die Voice-Routing-Richtlinie. Erst mit der Zuweisung der passenden OnlineVoiceRoutingPolicy kann der Anwender auch wieder nach draußen telefonieren. Ohne diesen Schritt geht es nur rein, nicht raus — ein Fehlerbild, das sich beim ersten Mal erstaunlich lange hält.

Vorbereitend gehören außerdem die Teams-Richtlinien für Besprechungen, Nachrichten und Anrufe gesetzt, und zwar bevor der Anwender umzieht. Sonst landet er kurzzeitig in einer Standardkonfiguration, die niemand haben wollte, und die Rückfragen kommen nicht aus der Technik, sondern aus dem Fachbereich.

Die technische Einrichtung von Direct Routing selbst — Kopplung, Zertifikate, Routing, Medienpfade — ist im eigenen Beitrag zum Einrichten von Teams Direct Routing ausführlich beschrieben. Und wenn ihr den SBC noch nicht als eigenständige Komponente denkt, hilft der Beitrag zu den Grundlagen des Session Border Controllers beim Einordnen.

TIPP Baue dir für Phase 4 ein Runbook, das exakt eine Welle beschreibt — inklusive der Vorher-Erfassung von Rufumleitungen und Delegierungen, der drei Umschaltschritte, einer festen Testliste und eines definierten Rückwegs. Führe dieses Runbook im Pilot dreimal durch und ändere es danach nicht mehr ohne Grund. Der Wert eines Migrationsprojekts liegt nicht in der Eleganz der ersten Welle, sondern in der Langeweile der zwanzigsten.

 

Rufnummern und der bestehende SBC

Alles an einer alten Telefonanlage lässt sich ersetzen. Die Hardware, die Software, die Bedienphilosophie, sogar die Gewohnheiten — irgendwann. Eines nicht: der Rufnummernblock. Er steht auf Briefpapier, in Verträgen, auf Fahrzeugen, in fremden CRM-Systemen und im Kopf von Leuten, die seit zwanzig Jahren dieselbe Durchwahl anrufen. Deshalb bekommt er ein eigenes Kapitel.

Drei Wege für die Rufnummern. Für Häuser mit bestehendem SBC ist der linke fast immer der richtige.

Drei Wege — und für euch ist einer davon deutlich bequemer

Der erste Weg ist der, für den ihr gebaut seid: Der SIP-Trunk bleibt beim bestehenden Anbieter, der Session Border Controller bekommt zusätzlich zur Route in Richtung Mediation Server eine zweite Route nach Direct Routing. Keine Portierung, kein Carrier-Termin, kein Stichtag, an dem das ganze Haus gleichzeitig umfällt. Ihr entscheidet pro Rufnummer, wann sie umzieht — und ihr könnt sie am selben Nachmittag wieder zurückdrehen, wenn etwas nicht passt.

Der zweite Weg ist die Portierung zu Microsoft mit Anbindung über einen Calling Plan. Fachlich sauber, betrieblich am schlanksten, aber mit einem harten Stichtag versehen und mit einem Rückweg, der Wochen dauert. Für kleine, übersichtliche Rufnummernblöcke ohne Sonderfälle ist das ein guter Weg. Für einen gewachsenen Durchwahlbereich mit Servicenummern, Faxanschlüssen und Alarmwählgeräten ist es ein deutlich größeres Wagnis.

Der dritte Weg ist Operator Connect: Ein zertifizierter Anbieter bringt die Rufnummern direkt in den Tenant, ohne eigenen SBC und ohne eigenen Trunk. Weniger Betrieb, weniger eigene Kompetenz nötig — dafür auch weniger Kontrolle über Medienpfade und Sonderfälle. Interessant vor allem dann, wenn die SBC-Kompetenz im Haus gerade ohnehin in Rente geht.

Weg	Portierung nötig?	Umschaltung	Rückweg	Passt zu
Trunk behalten, Direct Routing über bestehenden SBC	Nein	Pro Rufnummer, jederzeit	Sofort, per Konfiguration	Häusern mit SBC und SIP-Trunk — also praktisch allen SfB-Betreibern
Portierung zu Microsoft, Calling Plan	Ja	Stichtag, blockweise	Wochen	Kleinen, sauberen Nummernblöcken ohne analoge Sonderfälle
Operator Connect über zertifizierten Anbieter	In der Regel ja	Nach Absprache mit dem Anbieter	Anbieterabhängig	Häusern, die SBC-Betrieb abgeben wollen
Teams Phone Mobile über Mobilfunkanbieter	Anbieterabhängig	Pro Anwender	Anbieterabhängig	Belegschaften, die faktisch nur mobil telefonieren

 

Dein SBC: bleiben, ersetzen oder abgeben

Wenn euer Session Border Controller heute den SIP-Trunk terminiert und mit dem Mediation Server spricht, kann er in aller Regel dasselbe mit Direct Routing tun — parallel, im selben Gerät, am selben Trunk. Genau diese Doppelanbindung ist der Grund, warum ihr die sanfteste Migration aller TK-Ablösungen fahren könnt. Zu prüfen sind im Wesentlichen drei Dinge: ob das Modell für Direct Routing zertifiziert ist, ob die Firmware den Anforderungen entspricht, und ob die Zertifikatskette stimmt.

Der letzte Punkt ist keine Formalie. Microsoft ändert die Vertrauensketten für die Direct-Routing-Verbindung von Zeit zu Zeit, und ein SBC, dem die passenden Wurzelzertifikate fehlen, verliert die Anbindung ohne Vorwarnung. Das ist eine der wenigen Wartungsaufgaben, die im Betrieb wirklich zwingend ist — und eine der wenigen, für die es im Kalender einen Eintrag geben sollte.

FAKTEN Aus dem Eigenbetrieb: Unsere eigene Telefonie läuft über Teams Direct Routing mit einem eigenen anynode-SBC und SIP-Trunks von easybell. Kein Testaufbau, sondern die Anlage, über die wir täglich erreichbar sind. Der praktische Nutzen dieser Konstellation im Migrationsprojekt: Wir kennen die Fehlerbilder aus eigener Anschauung — Zertifikatswechsel, Codec-Verhandlung, Rufnummernformate im internationalen Format, das Verhalten bei Trunk-Ausfall. Das ist der Grund, warum wir bei SBC-Fragen nicht auf Herstellerfolien verweisen müssen.

 

Notruf, Standort und die Nummern, die nicht klingeln

In der alten Welt war der Standort implizit: Der Apparat hing an einem Kabel, das Kabel lag in einem Gebäude, das Gebäude hatte eine Adresse. Fertig. In Teams ist der Anwender mobil, und die Notrufadresse ist eine Konfigurationsentscheidung. Das ist kein Nachteil — es ist nur eine Aufgabe, die neu erledigt werden muss und die niemand übernimmt, wenn man sie nicht ausdrücklich vergibt.

WARNUNG Notrufwege gehören in den Testplan jeder einzelnen Migrationswelle — nicht in eine Zeile am Ende des Abnahmeprotokolls. Ebenfalls auf die Liste, und zwar bevor der erste Anwender umzieht: alle Servicenummern (Zentrale, Sammelanschluss, Störungsannahme, Bestellhotline) und alle Nummern, die gar nicht klingeln — Fax, Frankiermaschine, Alarmwählgerät, Aufzugsnotruf, Brandmeldeanlage. Diese Nummern haben keinen Anwender, der sich meldet, wenn sie nicht mehr funktionieren. Sie fallen erst auf, wenn jemand sie braucht.

 

Für Auto Attendants und Call Queues, die selbst Anrufe entgegennehmen, braucht es außerdem Ressourcenkonten mit der entsprechenden Lizenz. Diese Lizenz ist in einem Kontingent kostenfrei enthalten, muss aber ausdrücklich zugewiesen werden — vergessene Zuweisungen sind eine häufige und ärgerlich banale Fehlerursache beim ersten Test der neuen Zentrale. Den konkreten Umfang des Freikontingents solltet ihr für euren Tenant prüfen, statt euch auf allgemeine Angaben zu verlassen.

Fahrplan — und wann der Server wirklich vom Netz darf

Ein Migrationsprojekt dieser Art scheitert selten an der Technik. Es scheitert an der Zeitachse — genauer: daran, dass die Parallelphase kein Ende hat. Deshalb steht am Anfang kein Konzept, sondern ein Datum.

Ein typischer Zuschnitt. Die Wochenangaben sind Erfahrungswerte für ein mittelständisches Haus, kein Versprechen.

Fünf Phasen, und die vierte ist die gefährliche

Phase 1 ist die Bestandsaufnahme, und sie ist wertvoller, als sie klingt: jede Rufnummer, jede Response Group, jede analoge Leitung, jedes Telefon. Das Ergebnis ist bewusst eine Liste und kein Konzept — Konzepte entstehen erst, wenn man weiß, worüber man redet.

Phase 2 baut die Infrastruktur: Hybrid sauber aufsetzen, Direct Routing im Tenant koppeln, das Voice Routing spiegeln. Am Ende dieser Phase laufen beide Welten am selben Trunk, und noch hat sich für keinen einzigen Anwender etwas geändert. Das ist genau der Zustand, den ihr haben wollt, bevor irgendjemand umzieht.

Phase 3 ist der Pilot — und der wichtigste Rat dazu lautet: Nimm nicht die IT-Abteilung. Die IT telefoniert anders als der Rest des Hauses. Ein belastbarer Pilot besteht aus zwanzig bis vierzig Leuten aus allen Bereichen, ausdrücklich einschließlich Empfang, Sekretariat und der Abteilung mit der kompliziertesten Warteschlange. Wenn diese Gruppe nach zwei Wochen zufrieden ist, funktioniert das Konzept. Wenn nur die IT zufrieden ist, wisst ihr gar nichts.

Phase 4 ist der Rollout in Wellen — und hier kippen die Projekte. Nicht weil etwas kaputtgeht, sondern weil das Tempo verloren geht. Aus „drei Monate parallel“ werden zwei Jahre, in denen zwei Plattformen betrieben, zwei Fehlerbilder analysiert und zwei Wissensstände gepflegt werden müssen. Das kostet mehr als beide Plattformen einzeln — an Geld, an Nerven und an Glaubwürdigkeit gegenüber der Belegschaft, die den Zustand zu Recht als Halbfertiges wahrnimmt.

Phase 5 ist der Abbau. Und die kommt später, als die meisten denken.

Decommissioning: die Reihenfolge ist nicht verhandelbar

Der Rückbau der On-Premises-Umgebung folgt einer festen Reihenfolge, und wer sie abkürzt, baut sich unnötige Probleme. Erst wenn alle Anwender online sind, wird die Hybrid-Konfiguration deaktiviert. Danach wandern die Anwendungsendpunkte in die Cloud. Und erst danach darf die Umgebung tatsächlich abgebaut werden.

Schritt	Was passiert	Woran es in der Praxis hängt
1. Alle Anwender umziehen	Move der Konten aus der On-Premises-Umgebung in die Cloud	Der eine Anwender im Außendienst, der seit acht Monaten nicht erreichbar ist
2. Hybrid deaktivieren	Hybrid-Konfiguration abschalten, DNS-Einträge entfernen	Der lyncdiscover-Eintrag, den niemand mehr im DNS vermutet
3. Anwendungsendpunkte umziehen	Hybride Anwendungsendpunkte nach online verlagern	Vergessene Endpunkte für alte Warteschlangen und Vermittlungsdienste
4. Umgebung abbauen	Server, Pools, Datenbanken und Zertifikate zurückbauen	Die Angst, etwas Unbekanntes abzuschalten — deshalb Phase 1 so gründlich

 

WICHTIG Solange auch nur ein Anwender ein Skype-for-Business-Konto On-Premises hat oder ein lyncdiscover-DNS-Eintrag auf eine On-Premises-Umgebung zeigt, lässt sich TeamsOnly nicht auf Tenant-Ebene setzen. Konkret: Grant-CsTeamsUpgradePolicy mit UpgradeToTeams greift auf Tenant-Ebene nicht, solange ein lyncdiscover-Eintrag erkannt wird, der nicht auf Microsoft 365 zeigt. Das ist kein Schönheitsfehler. Es ist der Grund, warum viele Häuser jahrelang in einem Zwischenzustand hängen, ohne zu verstehen, warum die letzte Umstellung nicht greift.

 

Was den Unterschied macht

Am Ende entscheidet über den Erfolg dieser Projekte kein technisches Detail, sondern eine Handvoll organisatorischer Festlegungen: ein Enddatum, das jemand mit Budgetverantwortung unterschrieben hat. Feste Wellentermine statt „wenn die Abteilung so weit ist“. Ein Runbook, das sich nicht jede Woche ändert. Und die Bereitschaft, unbequeme Sonderfälle früh zu benennen statt sie ans Projektende zu schieben, wo sie garantiert teurer werden.

Wenn ihr an einer dieser Stellen Unterstützung braucht — von der Bestandsaufnahme über die Direct-Routing-Architektur bis zur Begleitung der Wellen —, findet ihr das Angebot auf der Seite zur Beratung rund um Teams-Telefonie. Für Häuser, die zunächst auf der On-Premises-Plattform bleiben, gibt es das Gegenstück in der Beratung zu Skype for Business Server SE sowie Hands-on-Workshops zur SE-Plattform. Wer parallel über Hochverfügbarkeit nachdenkt, findet die Details zur Enterprise-Topologie mit SQL AlwaysOn.

Häufige Fragen

Können wir einfach auf SE upgraden und das Thema für fünf Jahre vergessen?

Upgraden könnt ihr. Vergessen nicht. Das In-Place-Upgrade von 2019 auf SE ist technisch unspektakulär und verschafft euch eine unterstützte Plattform — das ist ein echter Gewinn gegenüber dem Status „außer Support“. Aber es beantwortet die strategische Frage nicht, sondern verschiebt sie. Nutzt den gewonnenen Zeitraum für ein geplantes Migrationsprojekt, nicht als Ersatz dafür.

Müssen wirklich alle Anwender in einem Rutsch umziehen?

Nein, und das ist genau der Vorteil eurer Ausgangslage. Über die Doppelanbindung am Session Border Controller lässt sich pro Rufnummer entscheiden, welche Welt einen eingehenden Anruf bekommt. Ihr könnt in Wellen migrieren, Abteilung für Abteilung, und bei Bedarf einzelne Anwender zurückdrehen. Nur sollte diese Möglichkeit ein Sicherheitsnetz bleiben und nicht zur Dauerlösung werden.

Was passiert mit unseren Response Groups?

Sie werden nicht migriert, weil es in der Cloud keinen Response-Group-Dienst gibt. Die Anrufflüsse müssen als Auto Attendant und Call Queue neu modelliert werden. Das klingt schlimmer, als es ist: In den meisten Häusern sind über die Jahre deutlich mehr Warteschlangen entstanden, als tatsächlich benutzt werden. Plant den Aufwand realistisch ein — und nutzt die Gelegenheit zum Aufräumen.

Behalten wir unsere Rufnummern?

Ja. Wenn ihr den SIP-Trunk und den bestehenden SBC behaltet und über Direct Routing anbindet, ist überhaupt keine Portierung nötig — die Nummern bleiben, wo sie sind. Nur wenn ihr auf einen Microsoft Calling Plan wechselt, müssen die Nummern portiert werden, und dann gehört ein sauber terminierter Portierungsauftrag in den Projektplan.

Können wir unseren vorhandenen SBC weiter nutzen?

Mit hoher Wahrscheinlichkeit ja. Zu prüfen sind drei Dinge: ob das Modell für Direct Routing zertifiziert ist, ob die Firmware den Anforderungen genügt und ob die Zertifikatsvertrauenskette zur Microsoft-Seite passt. Der letzte Punkt gehört auch nach der Migration dauerhaft überwacht, weil Microsoft die Vertrauensketten von Zeit zu Zeit ändert.

Was wird aus unseren alten Tischtelefonen?

Geräte mit Lync- oder Skype-for-Business-Firmware wechseln nicht einfach die Welt. Der vorgesehene Weg für kompatible Modelle ist das SIP Gateway: Das Telefon meldet sich mit dem Firmenkonto an und beherrscht die Grundfunktionen, liefert aber kein Teams-Bedienerlebnis. Nicht unterstützte Modelle müssen ersetzt werden. Prüft die Kompatibilität modellgenau, bevor ihr mit Stückzahlen und Budgets rechnet.

Warum funktioniert bei einzelnen Anwendern das Telefonieren nach dem Umzug nicht?

Der mit Abstand häufigste Grund ist die Eigenschaft EnterpriseVoiceEnabled in der Cloud. Sie wird nur dann automatisch korrekt gesetzt, wenn der Anwender On-Premises für Enterprise Voice aktiviert war und die Phone-System-Lizenz bereits vor dem Umzug zugewiesen wurde. Kommt die Lizenz später, muss die Eigenschaft ausdrücklich nachgezogen werden. Der zweithäufigste Grund: Die OnlineVoiceRoutingPolicy fehlt — dann gehen Anrufe nur rein, nicht raus.

Wann können wir die Server endlich abschalten?

Nachdem alle Anwender online sind, die Hybrid-Konfiguration deaktiviert ist, die DNS-Einträge entfernt sind und die Anwendungsendpunkte in die Cloud verlagert wurden. Erst dann ist der Rückbau dran — und erst dann lässt sich TeamsOnly auch auf Tenant-Ebene setzen. Der lyncdiscover-Eintrag im DNS ist dabei die mit Abstand häufigste Fußangel.

Wie lange dauert so ein Projekt realistisch?

Für ein mittelständisches Haus mit einigen Hundert Anwendern, überschaubaren Sonderfällen und vorhandenem SBC sind sechs bis zwölf Monate von der Bestandsaufnahme bis zum Rückbau ein realistischer Rahmen. Der Löwenanteil entfällt nicht auf die Technik, sondern auf Warteschlangen, Endgeräte, Sonderfälle an den Rändern und die Abstimmung mit den Fachbereichen. Wer deutlich schneller unterwegs ist, hat entweder wenig Sonderfälle oder plant sie noch nicht mit.

Fazit

Wenn du heute noch einen Skype for Business Server mit Enterprise Voice betreibst, hast du zwei Dinge gleichzeitig: ein Ablaufdatum und einen Startvorteil. Das Ablaufdatum ist unangenehm, aber es ist wenigstens ehrlich. Der Startvorteil dagegen wird regelmäßig unterschätzt — von euch selbst am meisten.

Ihr müsst SIP nicht lernen, ihr sprecht es. Ihr müsst keinen SBC beschaffen, ihr betreibt einen. Ihr müsst keinen Rufnummernplan rekonstruieren, ihr habt ihn in Regeln gegossen. Ihr müsst kein Hybrid erfinden, ihr habt es halb gebaut. Was bei einer klassischen TK-Ablösung die ersten vier Monate frisst, ist bei euch bereits erledigt.

Was bleibt, sind drei Aufgaben, die niemand euch abnimmt: die Warteschlangen neu bauen, die Ränder mit Analogtechnik und Altgeräten ehrlich budgetieren, und die Parallelphase kurz halten. Die ersten beiden sind Arbeit. Die dritte ist eine Entscheidung — und sie fällt nicht in der IT, sondern dort, wo Budgets unterschrieben werden.

Der Weg selbst ist gut ausgetreten: Hybrid, Direct Routing, Umzug in Wellen, Rückbau. Was ihn im Einzelfall interessant macht, sind nicht die Anwender — es sind der Aufzug, das Faxgerät und die Kollegin am Empfang mit ihren vierzehn Kurzwahltasten. Wenn du den Gesamtüberblick über Anbindungsarten, Lizenzen und Betrieb suchst, steht er im Pillar-Beitrag zur Teams-Telefonie. Und wenn ihr für die Übersetzung eurer bestehenden Voice-Konfiguration nach Direct Routing jemanden wollt, der dieselbe Konstellation selbst betreibt: hier entlang.

Quellen

Microsoft Learn: PSTN considerations when upgrading to Teams from Skype for Business — https://learn.microsoft.com/de-de/microsoftteams/upgrade-to-teams-on-prem-pstn-considerations

Microsoft Learn: Upgrade Skype for Business on-premises to Microsoft Teams — https://learn.microsoft.com/de-de/microsoftteams/upgrade-to-teams-execute-skypeforbusinesshybridonprem

Microsoft Learn: Move users between on-premises and cloud — https://learn.microsoft.com/de-de/skypeforbusiness/hybrid/move-users-between-on-premises-and-cloud

Microsoft Learn: Configure hybrid connectivity between Skype for Business Server and Microsoft 365 — https://learn.microsoft.com/de-de/skypeforbusiness/hybrid/configure-hybrid-connectivity

Microsoft Learn: Decommission your on-premises Skype for Business environment — https://learn.microsoft.com/de-de/skypeforbusiness/hybrid/decommission-on-prem-overview

Microsoft Learn: Migrate response groups (Skype for Business Server) — https://learn.microsoft.com/de-de/skypeforbusiness/migration/migrate-response-groups

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

Microsoft Learn: Enable users for Direct Routing — https://learn.microsoft.com/de-de/microsoftteams/direct-routing-enable-users

Microsoft Learn: Technical prerequisites and licensing for auto attendants and call queues — https://learn.microsoft.com/de-de/microsoftteams/aa-cq-reference-prerequisites-licensing

Microsoft Lifecycle: Skype for Business Server Subscription Edition — https://learn.microsoft.com/de-de/lifecycle/products/skype-for-business-server-subscription-edition

Microsoft Community Hub: Skype for Business Server Subscription Edition (SE) is now available — https://techcommunity.microsoft.com/blog/skype_for_business_blog/skype-for-business-server-subscription-edition-se-is-now-available/4424925

Microsoft Community Hub: Why „in-place upgrade“ from Skype for Business Server 2019 to SE is low risk — https://techcommunity.microsoft.com/blog/skype_for_business_blog/why-%E2%80%9Cin-place-upgrade%E2%80%9D-from-skype-for-business-server-2019-to-subscription-editi/4427179

Microsoft Community Hub: End of Support for Skype for Business Server 2015 and 2019 — https://techcommunity.microsoft.com/blog/skype_for_business_blog/end-of-support-for-skype-for-business-server-2015-and-skype-for-business-server-/4268502

Microsoft Community Hub: Deadline approaching to migrate 3PIP phones to Teams through SIP Gateway — https://techcommunity.microsoft.com/t5/microsoft-teams-blog/deadline-approaching-to-migrate-3pip-phones-to-microsoft-teams/ba-p/3814072

TE-SYSTEMS: anynode und Microsoft Teams (Zertifizierung, Zertifikatswechsel) — https://www.anynode.de/features/anynode-and-microsoft-teams/

boddenberg.de: SE oder Teams — die ehrliche Entscheidungsmatrix — https://www.boddenberg.de/se-oder-teams-entscheidungsmatrix/

boddenberg.de: Skype for Business Server 2019 zu SE — In-Place-Upgrade-Playbook — https://www.boddenberg.de/skype-for-business-server-2019-zu-se-in-place-upgrade-playbook/

boddenberg.de: Dedicated Hybrid Application für Skype for Business — https://www.boddenberg.de/dedicated-hybrid-application-fuer-skype-for-business/

boddenberg.de: Teams-Telefonie — der Überblick — https://www.boddenberg.de/teams-telefonie/

Stand der Recherche: 2. September 2026. Produktnamen, Lizenzbedingungen und Herstellerangaben ändern sich; Versionen, Kontingente und Konditionen bitte vor der Umsetzung am eigenen Tenant und im eigenen Vertrag prüfen.