Migration von der TK-Anlage zu Teams: Der Phasenplan, der funktioniert

Telefonie-Migrationen scheitern fast nie an der Technik — sie scheitern an der Türsprechstelle, die niemand auf der Liste hatte, am Wartungsvertrag mit 18 Monaten Kündigungsfrist und an der Vermittlungs-Sekretärin, die am Montag nach dem Big Bang eine neue Oberfläche und null Schulung vorfindet. Die Gegenmedizin ist unspektakulär: ein Vier-Phasen-Modell aus Analyse, Pilot, Rollout und Abschluss, bei dem jede Phase die nächste absichert. Dieser Artikel beschreibt den Phasenplan in voller Tiefe — inklusive der Sonderfall-Inventur als Checkliste und einer klaren Ansage, warum Phase 1 die einzige ist, an der du nicht sparen darfst.

Warum Telefonie-Migrationen wirklich scheitern

Die Teams-Seite einer Migration ist heute erfreulich unspektakulär: Lizenzen zuweisen, Nummern zuordnen, Warteschleifen bauen — alles beherrschtes Handwerk. Die Risiken wohnen woanders, nämlich in der alten Welt: in dreißig Jahren gewachsener Telefonie-Infrastruktur, von der niemand mehr vollständig weiß, was eigentlich alles dranhängt. Das Fax der Buchhaltung kennt jeder. Aber der Aufzugsnotruf, der über eine analoge Nebenstelle läuft? Die Alarmanlage, die sich nachts auf eine Wählleitung aufschaltet? Der Wartungszugang des Heizungsbauers am Modem im Keller? Genau diese Dinge fallen bei der Big-Bang-Migration am Stichtag auf — und zwar dadurch, dass sie nicht mehr funktionieren. Der zweite Klassiker ist der Kalender: Wartungsverträge und Anschlussverträge haben Kündigungsfristen, die länger sind als so mancher Projektplan, und wer sie zu spät prüft, zahlt die alte Welt ein Jahr länger als nötig — die Kostenrechnung kippt dann in der Übergangszeit spürbar. Das Vier-Phasen-Modell ist gegen beide Fehlerarten gebaut: Es zwingt die Inventur an den Anfang und hält jede Umstellung reversibel, bis sie sich bewiesen hat.

Skizze 1: Das Vier-Phasen-Modell — Analyse, Pilot, Rollout, Nur Teams, mit Meilenstein je Phase.

Alt-Text-Vorschlag: Zeitstrahl des Vier-Phasen-Modells der Teams-Migration: Phase 1 Analyse über vier bis acht Wochen mit Telefonprofilen, Sonderfall-Inventur, Spitzenlastmessung, Vertragsprüfung und Architekturentscheidung, Meilenstein ist die Entscheidung. Phase 2 Pilot über vier bis acht Wochen mit zehn bis dreißig repräsentativen Nutzern in Koexistenz mit der Altanlage, Meilenstein ist das durch Zahlen belegte Go. Phase 3 Rollout über Wochen bis Monate mit Wellen je Abteilung oder Standort, Portierungs-Stichtagen und Rollback-Fähigkeit, Meilenstein ist die letzte Welle. Phase 4 Nur Teams mit Altanlagen-Abschaltung, Vertragskündigungen und Regelbetrieb. Darunter die eiserne Regel: Phase 1 wird nicht übersprungen.

Phase 1 — Analyse: Die Inventur, die alles entscheidet

Die Analysephase beantwortet vier Fragen, und jede davon verhindert eine eigene Sorte Projektkatastrophe. Erstens: Wer telefoniert wie? Nicht jeder Nutzer ist gleich — die Sachbearbeiterin mit drei Anrufen am Tag, der Vertriebsinnendienst in der Warteschleife, die Vermittlung mit Besetztlampenfeld, der Außendienstler auf dem Handy. Aus diesen Telefonprofilen ergeben sich später Lizenzen, Endgeräte und Schulungsbedarf — die Bestandsseite dazu liefert die Lizenz-Inventur aus dem Lizenzierungs-Überblick gleich mit. Zweitens: Was hängt noch an der Anlage? Das ist die berühmte Sonderfall-Inventur — dazu gleich mehr. Drittens: Wie viel Verkehr läuft wirklich? Die Spitzenlast aus der Anlagen-Statistik dimensioniert später Kanäle und SBC. Und viertens: Was steht in den Verträgen? Kündigungsfristen von Wartungsvertrag, Anschlüssen und eventuellen Mietanlagen definieren den frühestmöglichen Endtermin der alten Welt — manchmal ist dieser Termin der eigentliche Taktgeber des ganzen Projekts.

Die Sonderfall-Inventur: Der Rundgang, der Projekte rettet

Die Sonderfall-Inventur ist eine physische Übung, keine Aktenlage: mit der Anlagen-Konfiguration in der einen und einem Klemmbrett in der anderen Hand durchs Gebäude, jede Nebenstelle verfolgen, jede Anschlussdose hinterfragen. Die Konfiguration der Altanlage lügt dabei in beide Richtungen — sie enthält Nebenstellen, die seit Jahren tot sind, und ihr fehlen Dinge, die irgendwann am Amt vorbei gebastelt wurden. Die folgende Checkliste versammelt die üblichen Verdächtigen; jeder Fund bekommt drei Angaben: Wo ist es, wird es noch gebraucht, und was ist der Zielweg?

Am Ende der Phase 1 steht die Architekturentscheidung: Welcher Anbindungsweg — oder welche Kombination — passt zu Profilen, Sonderfällen und Budget? Die Entscheidungslogik dazu liefert der Entscheider-Vergleich; die Faustregel bleibt: Wer eine volle Sonderfall-Liste hat, landet fast immer bei Direct Routing oder einem Mischbetrieb. Mit Weg, Budget und Wellenplan ist der Meilenstein erreicht — und erst jetzt wird bestellt.

Phase 2 — Pilot: Beweisen statt hoffen

Der Pilot hat einen einzigen Zweck: die Annahmen aus der Analyse gegen die Wirklichkeit zu testen, solange Fehler noch billig sind. Dafür braucht er die richtige Gruppe — 10 bis 30 Nutzer, und zwar nach drei Kriterien ausgewählt: freiwillig (Zwangspiloten melden keinen Fehler, sie sammeln Frust), repräsentativ (mindestens ein Vieltelefonierer, jemand aus einer Warteschleife, ein Homeoffice-Fall — nicht nur die IT-Abteilung) und kommunikativ (Leute, die sagen, was klemmt). Technisch läuft der Pilot im Parallelbetrieb: Die Pilotgruppe telefoniert über Teams, der Rest über die Altanlage, und der SBC verbindet beide Welten, sodass interne Gespräche und die Erreichbarkeit von außen nahtlos bleiben — die Brückenmechanik dafür bringt der SBC von Haus aus mit.

Skizze 2: Die Übergangsarchitektur — Altanlage und Teams parallel, der SBC als Brücke.

Alt-Text-Vorschlag: Architekturdiagramm des Parallelbetriebs während der Migration: Das Telefonnetz ist über einen SIP-Trunk mit allen Rufnummern an den SBC angebunden, der als Brücke je Rufnummer entscheidet, ob der Anruf in die Altanlage mit den noch nicht migrierten Abteilungen oder in die Teams-Cloud mit den bereits migrierten Wellen geht. Interne Gespräche zwischen beiden Welten laufen ebenfalls über den SBC. Die Altanlage schrumpft mit jeder Welle, die Teams-Seite wächst — Anrufer merken davon nichts.

Was der Pilot beweisen muss, gehört vorher schriftlich festgelegt — sonst endet er im „lief doch ganz gut“-Nebel. Die Kernkriterien: Sprachqualität in Zahlen (Beschwerden pro Woche, Blick in die Anrufanalyse), Notruf-Funktion mit korrektem Standort (einmal kontrolliert testen, nicht hoffen), die Sonderfälle im Kleinen (ein Fax am ATA probeweise, bevor zwanzig umziehen) und die Alltagstauglichkeit der Abläufe (Weiterleiten, Vertretung, Voicemail). Vier bis acht Wochen reichen — lang genug für einen Monatswechsel mit Lastspitze, kurz genug, um das Projektmomentum zu halten. Am Ende steht ein Go oder No-Go mit Begründung: Entweder die Kriterien sind erfüllt und der Rollout startet, oder es gibt eine konkrete Nacharbeitsliste und einen zweiten Anlauf. Beides ist ein Erfolg — nur das unentschiedene Weiterwursteln ist keiner.

Phase 3 — Rollout: Wellen mit Rückfahrkarte

Der Rollout ist Fließbandarbeit mit Sicherheitsnetz. Die Wellen werden nach organisatorischen Einheiten geschnitten — Abteilung, Team oder Standort, niemals alphabetisch: Eine Abteilung samt ihrer Warteschleifen und Vertretungsregeln wandert geschlossen, damit keine halben Arbeitsgruppen zwischen den Welten hängen. Die Reihenfolge folgt der Robustheit: erst IT und Freiwillige, dann unkritische Abteilungen, dann die anspruchsvollen, und die Zentrale mit Empfang und den heikelsten Sonderfällen zum Schluss — gut geprobt statt mutig vorangestellt. Jede Welle bekommt ihr Drehbuch: Stichtag, Nummernumzug, Endgeräte-Ausgabe, Kurzschulung in der Woche davor, Ansprechpartner in der Woche danach — und ein Rollback-Fenster, in dem die Rückkehr zur Altanlage technisch noch möglich ist. Erst wenn die Welle stabil läuft, startet die nächste; der Wellenabstand ist der Puffer, der aus Fehlern Lerneffekte statt Flächenbrände macht.

Skizze 3: Der Wellenplan — jede Welle mit Stabilisierungsphase und Rollback-Fenster.

Alt-Text-Vorschlag: Wellenplan des Rollouts als Treppendiagramm über die Zeit: Welle 1 mit IT und Freiwilligen als robusteste Gruppe, Welle 2 mit einer geschlossenen Abteilung samt ihrer Warteschleifen, Welle 3 mit einem Standort samt eigenem Portierungs-Stichtag an einem Dienstag, Welle 4 mit Zentrale, Empfang und Sonderfällen zum Schluss. Nach jeder Welle folgt eine Stabilisierungsphase mit Rollback-Fenster, bevor die nächste startet. Dazu zwei Regeln: Stichtage liegen dienstags oder mittwochs und nie freitags, und jede Welle behält ihre Rückfahrkarte bis zur bestandenen Stabilisierung.

Phase 4 — Nur Teams: Abschalten mit System

Die letzte Phase ist die unterschätzteste, weil sich das Projekt fertig anfühlt, bevor es fertig ist. Abgeschaltet wird die Altanlage erst, wenn drei Listen leer sind: die Nutzerliste (alle Wellen durch), die Sonderfall-Liste (jeder Fund aus Phase 1 hat sein Ziel erreicht oder ist dokumentiert abgekündigt) und die Nummernliste (keine Rufnummer routet mehr in die alte Welt). Dann folgt der formale Teil: Wartungsvertrag und Anschlüsse zum korrekten Termin kündigen — mit den Fristen aus Phase 1, die genau für diesen Moment erhoben wurden —, die Anlage stromlos, den Raum zurückbauen und die frei werdenden Posten aus der Kostenrechnung streichen. Und schließlich der Übergang in den Regelbetrieb: der wöchentliche Qualitätsblick ins Call Quality Dashboard, die gepflegte Dokumentation von Nummern, Ressourcenkonten und Sonderfällen, die Jahres-Inventur. Ein kurzes Projekt-Review lohnt sich immer — nicht für die Schublade, sondern weil die nächste Migration bestimmt kommt: der Zukauf, der neue Standort, die Tochterfirma.

Der realistische Zeitplan — und die Fehler je Phase

Wie lange das Ganze dauert, hängt an Größe und Sonderfall-Dichte, aber die Größenordnungen sind stabil: Ein 50-Nutzer-Betrieb mit grüner Wiese schafft es in drei bis vier Monaten, der 200-Nutzer-Mittelständler mit Sonderfällen sollte mit fünf bis neun Monaten planen, Konzernstrukturen mit vielen Standorten entsprechend länger — wobei dort meist die Portierungs- und Abstimmungstakte den Takt vorgeben, nicht die Technik. Wichtiger als die Gesamtdauer ist die Verteilung: Analyse und Pilot dürfen zusammen gern die Hälfte der Zeit beanspruchen. Das fühlt sich zäh an und ist der Grund, warum die zweite Hälfte dann wie am Schnürchen läuft.

FAQ: Häufige Fragen zur Teams-Migration

Wie lange dauert die Migration zu Teams-Telefonie?

Als Größenordnung: drei bis vier Monate für kleine Umgebungen um 50 Nutzer, fünf bis neun Monate für einen Mittelständler mit 200 Nutzern und realer Sonderfall-Liste, länger bei vielen Standorten. Analyse und Pilot dürfen dabei ruhig die Hälfte der Zeit beanspruchen — das ist kein Verzug, sondern der Grund, warum der Rollout danach glatt läuft.

Können Teams und die alte TK-Anlage parallel betrieben werden?

Ja — der Parallelbetrieb ist sogar das Rückgrat des Wellen-Rollouts: Der SBC routet je Rufnummer in die alte oder neue Welt, interne Gespräche zwischen beiden funktionieren, und Anrufer merken nichts. Die Koexistenz ist als Übergang gedacht, nicht als Dauerzustand — jede Welle verkleinert die alte Seite, bis sie leer ist.

Was passiert bei der Migration mit unseren Rufnummern?

Sie bleiben erhalten — entweder verbleiben sie beim bestehenden SIP-Trunk-Provider (bei Direct Routing oft der einfachste Weg) oder sie werden zum neuen Carrier bzw. zu Microsoft portiert. Portierungen laufen zu geplanten Stichtagen je Welle; die Fristen und Abläufe gehören in den Wellenplan, und der Stichtag liegt — wie jeder Stichtag — nicht am Freitag.

Big Bang oder wellenweise Migration?

Wellen, in fast allen Fällen. Der Big Bang spart scheinbar Projektzeit und bezahlt dafür mit maximalem Risiko: kein Rollback, keine Lerneffekte zwischen den Wellen, und jeder übersehene Sonderfall trifft sofort das ganze Haus. Vertretbar ist der Big Bang allenfalls bei sehr kleinen Umgebungen ohne Sonderfälle — also genau dort, wo er auch am wenigsten Zeit spart.

Was ist der größte Fehler bei der Teams-Migration?

Die übersprungene oder vom Schreibtisch aus erledigte Analysephase. Fast jede teure Überraschung — der tote Aufzugsnotruf, das fehlende Fax, die verpasste Kündigungsfrist — ist ein Analysefehler, der im Rollout zum Störungsfall wird. Danach kommen mit Abstand: Freitags-Stichtage, reine IT-Pilotgruppen und fehlende Schulung für die Vielnutzer am Empfang.

Wann sollten wir die alte Anlage und ihre Verträge kündigen?

Die Fristen gehören in Phase 1 auf den Tisch — Wartungsverträge haben gern zwölf Monate Kündigungsfrist und mehr, und dieser Termin kann zum Taktgeber des Projekts werden. Gekündigt wird zum frühesten Termin nach dem geplanten Phase-4-Abschluss, mit Puffer: Lieber die alte Welt zwei Monate länger bezahlen als ohne Rückfallebene dazustehen, falls der Rollout hakt.

Brauchen wir für die Migration externe Unterstützung?

Ehrliche Antwort: kommt auf die Sonderfall-Dichte und die interne Erfahrung an. Die Teams-Seite ist gut dokumentiert und mit solider IT-Mannschaft machbar; die heiklen Stellen sind Inventur-Vollständigkeit, SBC-Design und die Stichtags-Choreografie mit Carrier und Portierung — dort zahlt sich Erfahrung aus, weil man die Löcher kennt, in die andere schon gefallen sind. Ein bewährtes Modell: Analyse und Konzept mit Begleitung, Rollout in Eigenregie mit Rückfrage-Draht.

Fazit: Langsam planen, schnell umstellen

Das Vier-Phasen-Modell ist keine Projektmanagement-Poesie, sondern destillierte Fehlervermeidung: Die Analyse findet die Minen, der Pilot beweist die Annahmen, der Wellen-Rollout hält jeden Schritt reversibel, und Phase 4 macht den Deckel drauf, ohne die Kündigungsfristen zu verschenken. Wer sich an die eine eiserne Regel hält — Phase 1 wird nicht übersprungen —, erlebt eine unspektakuläre Migration, und genau so soll sie sein. Wenn du vor der Migration stehst und wissen willst, wo deine Minen liegen: Melde dich kurz für eine Standortbestimmung — die Sonderfall-Inventur und der Phasenplan für dein Szenario sind ein überschaubarer erster Schritt mit maximaler Wirkung.