Migration von Skype for Business Server SE zu TeamsOnly
Phasenplan, PowerShell und Kommunikation für den letzten Schritt zur reinen Teams-UmgebungW I S S E N · S K Y P E F O R B U S I N E S S S E R V E R S E
Von Skype for Business Server SE zu TeamsOnly: Wave-Planung, User-Move und Decommissioning
Das Projekt-Framework für die saubere Migration – mit Phasenplan, Move-CsUser-Skripten, Kommunikationsvorlage und Final-State-Checkliste.
Boddenberg – IT-Beratung & Engineering · boddenberg.de · Stand: Juni 2026
|
TL;DR Die Kurzfassung für Eilige Die Migration von Skype for Business Server SE nach TeamsOnly ist ein Projekt, kein Knopfdruck: Hybrid steht und Shared SIP Address Space ist aktiv, dann werden User wellenweise mit Move-CsUser -MoveToTeams verschoben – der Move setzt den User automatisch auf TeamsOnly. Erst wenn kein einziger User mehr on-prem gehostet ist, folgt das Disable-Hybrid (Shared SIP aus, DNS umstellen, Coexistence tenant-weit auf TeamsOnly). Danach kann der SE-Server dekommissioniert werden. Finger weg von den msRTCSIP-Attributen – blindes Löschen schießt migrierte User offline. Realistisch: Pilot 1–2 Wochen, Wellen je nach Größe Wochen bis Monate. |
|---|
Worum es hier geht
Wenn Teams das Endziel ist, ist Skype for Business Server SE nur die Brücke – und irgendwann soll die Brücke weg. Dieser Artikel ist das Projekt-Framework für genau diesen letzten Schritt: User wellenweise nach TeamsOnly verschieben, Hybrid sauber trennen, den SE-Server abbauen. Kein loser Cmdlet-Zettel, sondern ein Ablauf mit Phasen, Zeitfenstern und einer Final-State-Checkliste. Das große Bild liefert der Pillar „Skype for Business Server SE im Überblick“; die Steuerung der Übergangs-Modi steht im Coexistence-Spoke.
Der wichtigste Satz vorweg, weil er die Reihenfolge des ganzen Projekts bestimmt: Das Disable-Hybrid kommt zuletzt – erst wenn der allerletzte relevante User in der Cloud ist. Wer die Reihenfolge dreht, schießt sich die noch verbliebenen On-Prem-User ab. Migration ist hier zu 20 Prozent PowerShell und zu 80 Prozent Reihenfolge und Kommunikation.
Der Phasenplan
Die Migration läuft in fünf Phasen. Die ersten vier sind nacheinander abzuarbeiten, die fünfte ist der Abbau am Ende. Quer durch alle Phasen gilt die msRTCSIP-Regel.
Skizze 1: Die fünf Phasen von der Vorbereitung bis zum Decommissioning. Disable-Hybrid (rot) erst, wenn null User mehr on-prem sind – dann erst der Abbau (grün).
Phase 1 – Vorbereiten
Hybrid muss stehen und der Shared SIP Address Space aktiv sein, sonst funktioniert kein sauberer Move. In dieser Phase planst du die Wellen (welche Gruppen in welcher Reihenfolge), bereitest die Kommunikation vor und legst die Erfolgskriterien fest.
Phase 2 – Pilot
Die IT-Abteilung migriert sich selbst zuerst. Das ist nicht Symbolik, sondern Testlauf: Hier findest du heraus, ob Move-CsUser sauber durchläuft, ob das Anruf-Routing nach dem Move stimmt und welche Stolpersteine die echten Wellen erwarten. Lessons dokumentieren, dann erst weiter.
Phase 3 – Wellen
Jetzt geht es Gruppe für Gruppe. Jede Welle bekommt ihren eigenen Termin, ihre eigene Ankündigung und einen Tag erhöhter Support-Bereitschaft. Der Move selbst setzt den User automatisch auf TeamsOnly – daran musst du nicht separat denken.
Phase 4 – Disable Hybrid
Erst wenn null User mehr on-prem gehostet sind, wird Hybrid logisch getrennt: Shared SIP Address Space deaktivieren, DNS umstellen, Coexistence tenant-weit auf TeamsOnly. Das ist der Punkt ohne einfaches Zurück – entsprechend sorgfältig.
Phase 5 – Decommission
Der SE-Server wird abgebaut, Edge und Reverse Proxy stillgelegt, die Lizenzen beendet. Hier hakst du die Final-State-Checkliste ab und dokumentierst den Endzustand.
|
ACHTUNG Die Reihenfolge ist nicht verhandelbar User zuerst, Hybrid zuletzt. Das Disable-Hybrid (Phase 4) darf erst starten, wenn wirklich kein produktiver User mehr on-prem gehostet ist. Prüfe das mit einem Report, nicht aus dem Bauch – ein einziger vergessener On-Prem-User, und das vorzeitige Trennen schießt ihn offline. Plane zwischen „letzte Welle migriert“ und „Hybrid trennen“ einen Stabilisierungspuffer ein. |
|---|
Der User-Move per PowerShell
Das Kommando ist erstaunlich schlicht – die Kunst liegt im Drumherum (Reporting, Wellenlisten, Verifikation). Der Move verschiebt das Konto in die Cloud und setzt es automatisch auf TeamsOnly.
# Einzelnen User nach Teams verschieben
Move-CsUser -Identity max.muster@contoso.de `
-Target sipfed.online.lync.com -MoveToTeams
# Eine ganze Welle aus einer Liste
Get-Content .\welle3.txt | ForEach-Object {
Move-CsUser -Identity $_ -Target sipfed.online.lync.com -MoveToTeams }
# Nach dem Move verifizieren: wer ist noch on-prem?
Get-CsUser -Filter {HostingProvider -eq 'SRV:'} # = noch on-prem
Der letzte Befehl ist dein wichtigster Report: Get-CsUser mit Filter auf den On-Prem-HostingProvider zeigt dir, wer noch nicht migriert ist. Genau diese Liste muss vor Phase 4 leer sein – das ist die objektive Voraussetzung fürs Disable-Hybrid, nicht das Bauchgefühl „sind wir durch“.
|
HINWEIS Verschieben heißt automatisch TeamsOnly Das Verschieben eines Users vom On-Prem-SE in die Cloud setzt ihn automatisch auf TeamsOnly. Du musst den Modus nach dem Move nicht separat setzen – und solltest es auch nicht versuchen, weil Cloud-User ohnehin nur TeamsOnly sein können. Der Move ist der Modus-Wechsel. |
|---|
Communication-Plan-Vorlage
Die Kommunikation entscheidet, ob die Migration als reibungslos oder als Katastrophe wahrgenommen wird – unabhängig davon, wie sauber die Technik läuft. Pro Welle dieselbe Sequenz:
|
Zeitpunkt |
Kanal |
Inhalt |
|---|---|---|
|
− 1 Woche |
E-Mail an Welle |
„Am <Datum> wechselt deine Telefonie/Chat zu Teams. Was sich ändert, was zu tun ist.“ |
|
− 1 Tag |
Erinnerung |
Kurze Reminder-Mail + Link zur Kurzanleitung (Anmeldung, Anruf, Meeting in Teams) |
|
Move-Tag |
Move + Support |
Move durchführen, erhöhte Support-Bereitschaft, klare „ab jetzt klingelt es in Teams“-Ansage |
|
+ 2 Tage |
Nachfass |
Kurze Rückfrage: läuft alles? Offene Tickets der Welle abarbeiten. |
|
TIPP Eine Mail spart zehn Tickets Der größte vermeidbare Aufwand jeder Migration sind „Wo ist mein Anruf?“-Tickets von Usern, die nicht wussten, dass sich etwas ändert. Die eine klare Ansage „ab Donnerstag klingelt dein Telefon in Teams, nicht mehr in Skype for Business“ ist mehr wert als jedes technische Detail im Runbook. Kommunikation ist kein Beiwerk, sie ist der halbe Projekterfolg. |
|---|
Disable Hybrid – die Schritte
Phase 4 ist die heikelste. Sie wird erst gestartet, wenn der On-Prem-Report leer ist. Dann in dieser Reihenfolge:
|
ACHTUNG msRTCSIP: das gefährlichste Aufräumen Die msRTCSIP-Attribute im lokalen Active Directory bleiben auch nach der Cloud-Migration synchronisiert. Wer sie im Rahmen eines „AD-Cleanups“ blind löscht, kann bereits migrierte TeamsOnly-User offline schießen – ausgerechnet die, die schon fertig sein sollten. Diese Attribute werden nur im Rahmen eines bewussten, getesteten Schritts angefasst, niemals nebenbei. Im Zweifel: stehen lassen. |
|---|
Final-State-Checkliste
Bevor das Projekt als abgeschlossen gilt, muss jeder Punkt abgehakt sein. Diese Liste ist die objektive Abnahme – kein „sieht gut aus“, sondern Punkt für Punkt:
Praxis: die Migration der Trendforge Digital GmbH
Die Trendforge Digital GmbH migrierte rund 400 User in sechs Wellen über gut zwei Monate. Pilot war die zehnköpfige IT, die dabei zwei Dinge lernte: Erstens lief Move-CsUser sauber, zweitens hatten drei User noch ein altes ISDN-Telefon am Platz, das niemand auf dem Schirm hatte – ein Fall für den Voice-Spoke, nicht für die User-Migration. Die Wellen liefen danach nach Abteilung, jeweils mit der Vier-Schritt-Kommunikation.
Der einzige ernste Moment: Ein gut gemeinter AD-Cleanup wollte „alte SfB-Reste“ entfernen und hätte beinahe die msRTCSIP-Attribute der bereits migrierten Wellen gelöscht. Gestoppt, weil ein Change-Prozess griff. Das Disable-Hybrid kam erst zwei Wochen nach der letzten Welle – bewusst als Puffer. Ergebnis: kein einziger „Wo ist mein Anruf?“-Eskalationsfall, weil die Kommunikation pro Welle saß, und ein sauber dekommissionierter SE-Server, dessen Lizenzen pünktlich endeten.
|
HINWEIS Der Consulting-Hebel Eine TeamsOnly-Migration scheitert fast nie an Move-CsUser, sondern an drei anderen Dingen: vergessene On-Prem-Reste vor dem Disable-Hybrid, blind gelöschte msRTCSIP-Attribute und fehlende Kommunikation. Ein Projekt-Framework mit Wellen-Vorlage, leerem On-Prem-Report als Gate und einem Change-Prozess fürs AD ist der Unterschied zwischen einem ruhigen Abschluss und einem Eskalations-Sommer. Genau hier liegt der Beratungswert – nicht im Cmdlet, sondern im Ablauf. |
|---|
Häufige Fragen
Wie verschiebe ich einen User nach TeamsOnly?
Mit Move-CsUser -Identity <user> -Target sipfed.online.lync.com -MoveToTeams. Der Move verschiebt das Konto in die Cloud und setzt es automatisch auf TeamsOnly – ein separates Setzen des Modus ist nicht nötig.
Muss ich den Coexistence-Modus nach dem Move noch setzen?
Nein. Cloud-gehostete User sind zwingend TeamsOnly, und der Move setzt das automatisch. Tenant-weit auf TeamsOnly stellst du erst im Rahmen des Disable-Hybrid, damit auch neu angelegte User korrekt landen.
Wann darf ich Hybrid trennen?
Erst wenn kein produktiver User mehr on-prem gehostet ist. Prüfe das objektiv mit Get-CsUser und dem On-Prem-Filter – die Liste muss leer sein. Plane danach einen Stabilisierungspuffer ein, bevor du Shared SIP und DNS umstellst.
Darf ich die msRTCSIP-Attribute im AD aufräumen?
Nicht nebenbei. Sie bleiben nach dem Move synchronisiert, und blindes Löschen kann bereits migrierte TeamsOnly-User offline schießen. Sie werden nur in einem bewussten, getesteten Schritt angefasst – im Zweifel stehen lassen.
In welcher Reihenfolge läuft das Disable-Hybrid?
Verifizieren (null On-Prem-User), Coexistence tenant-weit auf TeamsOnly, Shared SIP Address Space deaktivieren, DNS umstellen, On-Prem-Kommunikation einstellen. Die Reihenfolge ist wichtig – DNS zuerst wäre ein Premature DNS-Switch.
Wie lange dauert so eine Migration?
Der Pilot 1–2 Wochen, die Wellen je nach Userzahl Wochen bis Monate, dann ein Stabilisierungspuffer vor dem Disable-Hybrid. Eine 400-User-Umgebung ist in sechs Wellen über rund zwei Monate gut machbar – die Technik ist schnell, die Kommunikation und das Abfangen von Sonderfällen brauchen die Zeit.
Was passiert mit der Telefonie bei der Migration?
Die läuft parallel über den Voice-Migrationspfad (meist Direct Routing, das die bestehenden SIP-Trunks mitnimmt). Analoge Sondergeräte – Türöffner, Aufzüge – sind oft der zäheste Teil und gehören in die Wellenplanung. Details im Enterprise-Voice-Spoke.
Weiterführende Themen
Die Migration greift in mehrere Nachbarthemen. Weiter geht es hier:
Fazit
Die Migration nach TeamsOnly ist ein Projekt mit klarer Reihenfolge: vorbereiten, pilotieren, wellenweise verschieben, Hybrid trennen, dekommissionieren. Move-CsUser ist der einfache Teil – der Wert liegt in der Wellenplanung, der Kommunikation pro Welle, dem leeren On-Prem-Report als Gate vor dem Disable-Hybrid und der eisernen msRTCSIP-Disziplin.
Wer das als Framework angeht statt als Cmdlet-Sammlung, kommt ohne Eskalationen durch. User zuerst, Hybrid zuletzt, msRTCSIP in Ruhe lassen – das sind die drei Sätze, die das Projekt tragen.
Über den Autor
Ulrich B. Boddenberg ist unabhängiger IT-Berater, Software-Engineer und Fachbuchautor mit rund 30 Jahren Erfahrung in Microsoft-Enterprise-Infrastrukturen (Active Directory, ADFS, Entra ID, Exchange, SharePoint, PKI, Teams-Telefonie). Webseite: boddenberg.de.