Dieser Artikel bietet Partnern und Kunden, die ihre Anrufumgebungen auf Webex Calling - Dedicated Instance (DI) migrieren, ein strukturiertes Self-Service-Migrationsframework.

Die in diesem Artikel beschriebenen Migrationspraktiken und Meilensteine basieren auf der Methodik des Webex Setup Assist-Programms und spiegeln die umfangreiche Praxiserfahrung der Cisco-Liefer-, Engineering- und Entwicklungsteams wider. Diese Methoden wurden in den vergangenen sieben Jahren durch Hunderttausende von individuellen Kundeneinsätzen verfeinert, darunter Migrationen von BroadCloud, BroadWorks, Spark Calling, Unified CM (UCM), Hosted Collaboration Solution (HCS) und PBX-Plattformen von Drittanbietern. Die Richtlinien gelten für eine breite Palette von Kundenumgebungen, von Einzelplatzinstallationen bis hin zu groß angelegten Implementierungen mit mehr als 100.000 Arbeitsplätzen und Hunderten von Standorten, und folgen langjährig etablierten, bewährten Cisco-Prozessen, um Konsistenz, Qualität und betriebliche Effizienz während des gesamten Migrationslebenszyklus zu gewährleisten.

Der Artikel setzt voraus, dass die Leser bereits mit der Lizenzierung von Webex Calling - Dedicated Instance, dem administrativen Modell von Webex Control Hub sowie der Basissoftware und den Funktionen des Unified Communications Manager vertraut sind.

Seien wir ehrlich – das Wort Migration löst in einem IT-Team selten Begeisterung aus. Das wirft Fragen auf. "Was geht kaputt?" Wer erledigt die Arbeit? „Worüber verlieren wir die Kontrolle?“ Ist das überhaupt realistisch, wo wir doch schon jetzt alle Hände voll zu tun haben, um den Betrieb aufrechtzuerhalten? Dies sind keine Anzeichen von Widerstand gegen Fortschritt; es sind die Instinkte erfahrener Fachleute, die verstehen, dass die Migration einer unternehmenskritischen Telefonieplattform kein Wochenendprojekt ist. Bei Voice ist es so, dass die Nutzer einen zweisekündigen Fehler bemerken, bevor sie die zweiwöchige Ausfallplanung mitbekommen – und genau diese Tatsache lässt jede Änderung schwerer erscheinen, als sie sein sollte.

Die gute Nachricht? Die Zahlen erzählen eine ganz andere Geschichte als die Angst. Bei gut strukturierten Cloud-Migrationen beträgt die tatsächliche Änderung etwa 95% of engineering effort is invested in preparation, and only 5%. Noch besser: Der größte Teil dieser 95 % besteht aus Aktivitäten, die Ihr Team bereits im Rahmen des normalen Tagesgeschäfts durchführt – Bestandspflege, Zertifikatsverwaltung, Überprüfung von Wählplänen, Nachverfolgung des Gerätelebenszyklus und Dokumentation. Mit anderen Worten: Der Großteil der "Migrationsarbeit" besteht aus Arbeit, die Sie bereits erledigen. Dieser strukturierte Ansatz lenkt den Prozess einfach auf ein definiertes Ergebnis, und zwar in einem Tempo, das sich in Ihren bestehenden Arbeitsablauf einfügt, anstatt ihn zu überlagern.

Das Gefühl, eine „Mission Impossible“ zu sein, verfliegt ebenfalls, sobald man erkennt, dass jede Migration vollständig geprobt werden kann. Ein kleines, repräsentatives Pilotprojekt ermöglicht es Ihnen, den gesamten Prozess, die Integrationen, das Failover-Verhalten und die Benutzererfahrung zu validieren, bevor ein einziger Produktionsbenutzer betroffen ist. Am Umstellungstag wird nichts dem Zufall überlassen – denn der Umstellungstag ist lediglich die Wiederholung eines Prozesses, den Sie bereits erfolgreich durchgeführt haben. Und sollte etwas Unerwartetes eintreten, ist der Rollback ein Spiegelbild des Umstellungsprozesses selbst, begrenzt durch ein klares Wartungsfenster. Vorhersehbarkeit ersetzt Angst.

Ja, der Wechsel zu einer dedizierten Instanz bedeutet, dass man einen Teil der Kontrolle abgibt – insbesondere über die Infrastruktur- und Virtualisierungsschichten. Aber bedenken Sie, was Sie dadurch zurückgewinnen: die Stunden, die Ihr Team mit dem Patchen von Hypervisoren, dem Verfolgen von Hardware-Warnungen, dem Verwalten der Sicherheit auf Betriebssystemebene und dem Planen von Kapazitätsaktualisierungen verbringt. Diese Zeit steht dem Kerngeschäft wieder zur Verfügung und kann für das genutzt werden, was Ihr Unternehmen wirklich auszeichnet – Benutzererfahrung, Akzeptanz, Integrationen und die Dienstleistungen, die Ihren Stakeholdern wirklich wichtig sind. Sie verlieren nicht die Kontrolle; Sie tauschen lediglich undifferenzierte, schwere Arbeit gegen strategische Ausrichtung.

Im Gegenzug erhalten Sie eine Plattform, die eng mit dem fortschrittlichsten Portfolio für Telefonie, Meetings und Contact Center auf dem Markt integriert ist und auf Ciscos umfassender Ingenieurskompetenz sowie einem Partner-Ökosystem basiert, das durch Hunderttausende von Implementierungen optimiert wurde. Sie behalten die volle Leistungsfähigkeit des vertrauten Unified CM-Ökosystems – dieselben Funktionen, dieselbe Zuverlässigkeit, dasselbe Verwaltungsmodell, das Ihr Team bereits kennt – jetzt kombiniert mit Control Hub, einem modernen, benutzerorientierten Management- und Analyse-Dach, das wirklich einfach zu erlernen ist. Upgrades, Updates und die Behebung kritischer Sicherheitslücken in der neuesten Software werden von Cisco auf Cisco-zertifizierten Rechnern verwaltet – mit der gleichen (oder sogar einer besseren) Zuverlässigkeit, die Sie von Ihrer On-Premises-Umgebung erwarten.

Ja, Veränderungen bergen Risiken. Aber die Nichtänderung birgt ein eigenes , stilleres Risiko: Sie geraten bei der Entwicklung neuer Funktionen in Rückstand, müssen die ständige Komplexität von Änderungen, Release-Upgrades und Sicherheitslücken bewältigen, überlasten Ihr Team mit einer Infrastruktur, die das Unternehmen nicht mehr differenziert, und verzögern einen unvermeidlichen Übergang, bis er unter Druck erfolgen muss. Der folgende strukturierte, schrittweise Ansatz soll sicherstellen, dass diese Migration so verläuft, wie sie verlaufen sollte: gut vorbereitet, unkompliziert und hochgradig validiert — größtenteils umgesetzt durch Arbeit, die Sie bereits leisten, hin zu einer Plattform, die für die Zukunft der Zusammenarbeit geschaffen wurde.

Vom Selbstvertrauen zum Plan: Wie dieser Leitfaden aufgebaut ist

Um dieses Vertrauen in einen umsetzbaren Fahrplan zu verwandeln, führt Sie dieser Leitfaden durch einen siebenstufigen Migrationsprozess, wobei jede Phase klare Ein- und Austrittskriterien, aus der Praxis gewonnene Erkenntnisse und Vorabprüfungen enthält, die die häufigsten Überraschungen verhindern:

• Projektinitiierung
• Entdeckung & Bewertung
• Planung
• Implementierung
• Standbildfunktion ein
• Live wiedergeben
• Transfer zu Tag 2

Einer der Gründe, warum dieses Modell so gut funktioniert, ist , dass das Risiko für Ihre Produktionsumgebung bewusst im Vorfeld auf nahezu null reduziert wird und erst in einem kontrollierten, letzten Schritt ansteigt. Hier erfahren Sie, was Sie in jeder Phase erwartet:

Auswirkungen auf die Produktion	Phasen
Keine Auswirkungen	Projektinitiierung, Entdeckung & Bewertung, Planung
Minimale Auswirkungen	Implementierung
Beschränkt auf betriebliche Prozesse	Standbildfunktion ein
Direkte Auswirkungen	Live wiedergeben

In der Praxis: Der größte Teil der Reise findet sicher in Ihrer bestehenden Umgebung statt. Bis zum Zeitpunkt, an dem die Produktion beginnt, ist jede Integration erstellt, jeder Prozess geprobt und jeder Ausweichmechanismus verifiziert.

Im gesamten Leitfaden verweisen wir auf die wichtigsten Informationsquellen, auf die Sie während der Migration und auch noch am Tag der Migration zurückgreifen werden. 2:

• Cisco Calling Sales Connect — Cisco Calling Sales Connect Link
• Help.webex.com — maßgebliche Produkt- und Konfigurationsdokumentation
• Webex Spaces — direkter Zugang zu Cisco-Experten und Peer-Communities für Fragen in Echtzeit

Nachdem der Rahmen geschaffen und die Ressourcen bereitgestellt sind, gehen wir nun jede Phase im Detail durch – beginnend dort, wo jede erfolgreiche Migration beginnt: Projektinitiierung.

Auswirkungen auf die Produktion: Keine Auswirkungen

• Identifizierung der wichtigsten Stakeholder

Vergessen Sie nicht, dass es nicht nur um die technischen Teams und die betroffenen Geschäftsteams geht, sondern auch um die beteiligten Partner. Hier einige Beispiele für erforderliche Stakeholder:

• IT-Management
• Unternehmensführung
• Team für Sprachdienstleistungen
• Team der Kontaktzentren
• Netzwerkteam
• DNS/DHCP Team
• Sicherheitsteam
• IAM-Team (z. B. Entra, AD, SSO)
• Wechseltafel
• MACD-Partner
• Managed-Services-Partner
• Drittanbieter für Integrationen (Paging, Fax, Aufzeichnung usw.)
• Lokaler Support vor Ort
• RedSky /Public Sicherheitsteam.

• Wahl zwischen Projektleiter und Projektmanager.

Da Migrationen zu dedizierten Instanzen eine komplexere Koordination erfordern als herkömmliche Integrationen auf reiner Anwendungsebene, ist es wünschenswert, ein Teammitglied mit der Steuerung des internen Projektmanagements und aller damit verbundenen Aufgaben wie wöchentliche Telefonkonferenzen, Koordination interner Teams, Einbindung externer Anbieter, Koordination von Änderungenusw. zu beauftragen.

• Synchronisieren Sie die Eingaben, mit denen Sie das Projekt starten.

Es gibt zahlreiche Vorteile und Gründe, warum eine Strategie zur Migration zu dedizierten Instanzen verfolgt wird. Es ist wichtig, eine grundlegende Vision gegenüber zukünftigen Lösungen zu entwickeln.

Sind Änderungen wie Cluster-Konsolidierung, Wählplan oder neue Funktionen geplant?

Migrieren Sie die Software-Endpunkte „im Ist-Zustand“ oder gehen Sie bei der Migration von einem Wechsel zur Webex-App aus?

In welcher Beziehung stehen die Nutzer zu den Contact Centern?

• Mit einer dedizierten Instanz sind Sie immer auf dem neuesten Stand.

Einführung in dedizierte Instanzen: Einführung in dedizierte Instanz

BDM (Folien für Geschäftsentscheider) BDM

TDM (Folien für technische Entscheidungsträger) TDM.

Auswirkungen auf die Produktion: Keine Auswirkungen

Die Ermittlung und Bewertung ist eine Fortsetzung und Nutzung der Informationen, die in vorherigen Team-Synchronisationssitzungen zu den Inputs gewonnen wurden, mit dem Ziel, alle notwendigen Scope-Elemente zu identifizieren, die die Grundlage für die professionelle und technische Projektplanentwicklung bilden.

• Vorhandene Clusterkonfiguration

Bestehende On-Premise-Konfiguration mit allen implementierten Funktionen und Integrationen definieren. Hier sind einige Beispiele:

• Anwendungen und Dimensionierung,
• Standorte,
• IP-Adressierung,
• Wie Benutzer synchronized/provisioned (lokal, LDAP),
• Authentifizierung konfiguriert (SSO),
• CA-Zertifikate vs. selbstsignierte Zertifikate
• Sicherheitsmodus
• ILS/GDPR verwenden,
• Merkmale,
• Besonderer Fokus auf standortübergreifende Funktionen wie Extension Mobility,
• CER/911 Integration,
• Verwendung von MRA
• CDRs,
• Voicemails und Integration mit O365,
• Jabber vs WebexApp
  • Im Falle einer Jabber-Migration sollte besonderes Augenmerk darauf gelegt werden, wie die bestehenden Jabber-Endpunkte konfiguriert sind (z. B. XML-Konfiguration, Sprachdienstdomäne) und welche Optionen für eine Neukonfiguration bestehen, wie beispielsweise die Verwendung von SCCM. Hier sind die Standard-Szenarien aufgeführt: Jabber konfigurieren
• Liste der zu überprüfenden Geräte mit Fokus auf
  • Veraltete Geräte (seit Rel12 wurden keine neuen Geräte zur Liste der veralteten Geräte hinzugefügt.0x) Veraltete Telefone
  • Geräte, deren Support eingestellt wurde (Die Geräte können zwar noch für jede Softwareversion registriert sein, werden aber ab dem zweiten Tag nicht mehr unterstützt).
  • CSR-Compatibility-Matrix-Interactive.html
  • Geräte mit Sonderbeschränkungen 7925, 7940, 7960 Alte Telefonmodelle bei dedizierter Instanz registrieren
    • Werkzeuge in der Hilfe:

      Assistent für die Vormigration dedizierter Instanzen: Erstellung von Bewertungsberichten

      Der Pre-Migration Assistant in Control Hub hilft Ihnen beim Sammeln von Quelldaten und beim Überprüfen der Voraussetzungen für die Migration von UCM zu Dedicated Instance mithilfe eines Drittanbietertools. Vor der Migration bewertet es die Bereitschaft, stellt Checklisten bereit und ermöglicht Ihnen den Datenvergleich zwischen Ihrem lokalen Cluster und der dedizierten Instanz.

      Um Assistant ausführen zu können, muss Ihr lokaler Cluster in die Webex Cloud-Connected UC-Umgebung eingebunden werden. Eine allgemeine Beschreibung und die Voraussetzungen finden Sie hier: WebexCloud-ConnectedUC

      Onboarding-Prozess für UCM: Webex Cloud Connected-UC einrichten

      Liste wichtiger Erkenntnisse, die Sie vom Pre-Migration Assistant im leicht lesbaren XLS-Format erhalten:

      • Knoten und laufende Software
      • Unternehmensparameter
      • Liste der SIP-Trunks
      • Liste der Anwendungsbenutzer und Rollen
      • Anzahl der Geräte (und vollständige Geräteliste), Routengruppen und Partitionen, Standorte, Endbenutzer
      • CM-Gruppen, Gerätepools
      • Gesundheitszustand der Datenbankreplikation
      • Installierte COPs
      • Nummerierungspläne
      • Telefondienst
      • Fernziele
    • Webex Spaces bietet Unterstützung bei Ihren konkreten Fragen:

      Fragen Sie UCM Cloud & Dedizierte Instanz: webexteams://im?space=5db6bb40-d3c7-11e9-a319-df8a35abe85a

      RedSky External fragen – E911 Solutions Plus Partner beitreten: https://eurl.io/#fWfT1SnOz

      Fragen Sie den Webex-Einrichtungsassistenten – Webex Calling und DI: webexteams://im?space=76beab50-084b-11ed-abc8-ab581010b1de.

Auswirkungen auf die Produktion: minimale Auswirkungen auf die bestehende Produktionsumgebung

Die Cisco Best Practices im Hinblick auf den Migrationsprozess dedizierter Instanzen sind nachfolgend dargestellt:

Peering/Connectivity

Netzwerkarchitektur mit detaillierten Beschreibungen von Edge-Connect-Szenarien für Webex Calling, Dedicated Instance und Meetings. PA_Edge_Connect_Design.pdf

*Document sollte mit Vorsicht verwendet werden, da es mehrere Szenarien beschreibt, die einander widersprechen oder ergänzen können; es hängt vom jeweiligen Anwendungsfall ab. Genaue Angaben zu Dedicated Instance finden Sie im Kapitel„ Edge Connect für Dedicated Instance Architecture“ .

Webex Edge Connect

Webex Edge Connect Häufig gestellte Fragen, Hinweise:

• Eine dedizierte Instanz mit 2 Verbindungen ist ein Muss.
• 4 Glieder sind eine Option, aber „Kreuzungen“ sind nicht erlaubt, sie werden paarweise verwendet.
• Eine Priorisierung des DI-Verkehrs über eine der Verbindungen wird NICHT unterstützt und ist im Allgemeinen nicht anwendbar, dajede side/DC wirbt für sein einzigartiges Subnetz /25 Standorte der dedizierten Instanzen in Rechenzentren.

Dies wird auch im erwähnten Dokument zur Netzwerkarchitektur wie folgt erläutert: