Questo articolo fornisce un framework di migrazione self-service strutturato per partner e clienti che migrano gli ambienti di chiamata verso Webex Calling - Dedicated Instance (DI).

Le pratiche e le tappe fondamentali della migrazione descritte in questo articolo si basano sulla metodologia del programma Webex Setup Assist e riflettono la vasta esperienza nel mondo reale dei team di consegna, progettazione e sviluppo di Cisco. Questi metodi sono stati perfezionati attraverso centinaia di migliaia di implementazioni uniche sulla posizione dei clienti negli ultimi sette anni, comprese le migrazioni da BroadCloud, BroadWorks, Spark Calling, Unified CM (UCM), Hosted Collaboration Solution (HCS) e piattaforme PBX di terze parti. Le linee guida si applicano a un'ampia gamma di ambienti dei clienti, dalle implementazioni a postazione singola alle implementazioni su larga scala che superano 100.000 postazioni e centinaia di sedi, e seguono processi Cisco consolidati e comprovati per garantire coerenza, qualità ed efficienza operativa durante tutto il ciclo di vita della migrazione.

L'articolo presuppone che i lettori conoscano già le licenze per istanze dedicate, il modello amministrativo Webex Control Hub e il software e le funzionalità di base di Unified Communications Manager. Webex Calling

Siamo onesti: la parola migrazione raramente suscita entusiasmo in un team IT. Suscita domande. «Cosa si rompe?» «Chi lavora?» «Su cosa perdiamo il controllo?» «È realistico anche se siamo già stretti a tenere le luci accese?» Questi non sono segni di resistenza al progresso; sono l'istinto di professionisti esperti che comprendono che spostare una piattaforma di chiamata mission critical non è un progetto per il fine settimana. Voice è l'unico servizio in cui gli utenti notano un problema tecnico due secondi prima di notare uno sforzo di pianificazione delle interruzioni di due settimane, e questa realtà fa sembrare ogni modifica più pesante di quanto dovrebbe.

La buona notizia? I numeri raccontano una storia molto diversa rispetto alla paura. Nelle migrazioni cloud ben strutturate, circa il 95% degli sforzi ingegneristici viene investito nella preparazione e solo il 5% nel cambiamento effettivo. Ancora meglio, la maggior parte di quel 95% è costituito da attività che il suo team svolge già nell'ambito delle normali operazioni del secondo giorno: igiene dell'inventario, gestione dei certificati, revisione del piano telefonico, monitoraggio del ciclo di vita dei dispositivi e documentazione. In altre parole, la maggior parte del «lavoro di migrazione» è il lavoro che sta già facendo. Questo approccio strutturato lo canalizza semplicemente verso un risultato definito, a un ritmo che si adatta al suo ritmo operativo esistente piuttosto che ad esso.

La sensazione di «missione impossibile» svanisce anche quando vede che ogni migrazione può essere provata completamente. Un piccolo progetto pilota rappresentativo Le consente di convalidare il processo end-to-end, le integrazioni, il comportamento di failover e l'esperienza utente prima che venga contattato un singolo utente di produzione. Niente è lasciato al caso nel giorno limite, perché il giorno limite è semplicemente la ripetizione di un processo che Lei ha già eseguito con successo. E se dovesse succedere qualcosa di imprevisto, il rollback è uno specchio del cutover stesso, delimitato da una chiara finestra di manutenzione. La prevedibilità sostituisce l'ansia.

Sì, passare all'istanza dedicata significa rinunciare al controllo, in particolare sull'infrastruttura e sui livelli di virtualizzazione. Ma consideri cosa guadagna in cambio: le ore trascorse dal suo team ad applicare patch agli hypervisor, a cercare avvisi hardware, a gestire la sicurezza a livello di sistema operativo e a pianificare gli aggiornamenti della capacità. Quel tempo torna al business, dove può essere speso per ciò che effettivamente differenzia la sua organizzazione: esperienza utente, adozione, integrazioni e i servizi che stanno davvero a cuore ai suoi stakeholder. Non sta perdendo il controllo; sta scambiando un lavoro pesante indifferenziato con un focus strategico.

Ciò che riceve in cambio è una piattaforma strettamente integrata con il portafoglio di Calling, Meetings e Contact Center più avanzato sul mercato, supportata dalla profondità ingegneristica di Cisco e da un ecosistema di partner perfezionato attraverso centinaia di migliaia di implementazioni. Mantiene tutta la potenza dell'Unified CMecosistema familiare: le stesse funzionalità, la stessa affidabilità, lo stesso modello amministrativo che già conosce il suo team, ora abbinato a Control Hub, un ombrello di gestione e analisi moderno e orientato all'utente che è davvero semplice da imparare. Gli upgrade, gli aggiornamenti e le patch per le vulnerabilità critiche sul software più recente sono gestiti da Cisco, su computer certificati Cisco, con la stessa (o migliore) affidabilità che si aspetta dal suo ambiente locale.

Quindi sì, il cambiamento comporta dei rischi. Ma non cambiare comporta un rischio più silenzioso: rimanere indietro sulle funzionalità, affrontare la complessità costante delle modifiche, rilasciare aggiornamenti e vulnerabilità, mettere a dura prova il suo team su un'infrastruttura che non differenzia più il business e ritardare un'inevitabile transizione finché non deve essere eseguita sotto pressione. L'approccio strutturato e controllato che segue è progettato per rendere questa migrazione ciò che dovrebbe essere: ben preparata, poco drammatica e altamente convalidata, eseguita principalmente attraverso il lavoro che sta già facendo, verso una piattaforma creata per la prossima direzione della collaborazione.

Dalla fiducia a un piano: come è organizzata questa guida

Per trasformare questa fiducia in una tabella di marcia eseguibile, questa guida La guida attraverso un processo di migrazione in sette fasi, ogni fase con criteri di ingresso e uscita chiari, lezioni apprese sul campo e controlli preliminari che evitano le sorprese più comuni:

• Avvio del progetto
• Scoperta e valutazione
• Pianificazione
• Implementazione
• Congelare
• Trasmetta in diretta
• Trasferimento al secondo giorno

Uno dei motivi per cui questo modello funziona così bene è che il rischio per il suo ambiente di produzione è deliberatamente portato vicino allo zero e aumenta solo in una fase finale controllata. Ecco cosa aspettarsi in ogni fase:

Impatto sulla produzione	Fasi
Nessun impatto	Avvio del progetto, scoperta e valutazione, pianificazione
Impatto minimo	Implementazione
Limitato ai processi operativi	Congelare
Impatto diretto	Trasmetta in diretta

In termini pratici: la maggior parte del viaggio avviene in sicurezza nel suo ambiente esistente. Quando arriva il momento che tocca la produzione, ogni integrazione è stata creata, ogni processo è stato provato e ogni riserva è stata verificata.

In tutta la guida, facciamo riferimento alle principali risorse informative su cui farà affidamento durante la migrazione e fino al secondo giorno:

• Cisco Calling Sales Connect — Cisco Calling Sales Connect Link
• Help.webex.com — documentazione autorevole sul prodotto e sulla configurazione
• Webex Spaces: accesso diretto agli esperti Cisco e alle community di colleghi per domande in tempo reale

Con il framework impostato e le risorse a disposizione, esaminiamo ogni fase nel dettaglio, iniziando da dove inizia ogni migrazione riuscita: avvio del progetto.

Impatto sulla produzione: NESSUN impatto

• Identificare le principali parti interessate

Ricorda che non si tratta solo dei team tecnici e dei team aziendali interessati, ma anche dei partner coinvolti. Ecco l'esempio delle parti interessate richieste:

• gestione IT
• Gestione aziendale
• Team dei servizi vocali
• Il team dei contact center
• Team di networking
• Team DNS/DHCP
• Team di sicurezza
• Team IAM (ad esempio Entra, AD, SSO)
• Cambia consiglio
• Partner MACD
• Partner di servizi gestiti
• fornitori di integrazione di terze parti (cercapersone, fax, registrazione ecc.)
• Supporto locale in sede
• RedSky /Squadra di pubblica sicurezza.

• Scelta del responsabile del progetto o del responsabile del progetto.

Considerando che le migrazioni verso l'istanza dedicata richiedono un coordinamento più complesso rispetto alle tradizionali integrazioni «Solo a livello di applicazione», è auspicabile che un membro del team sia assegnato a guidare la gestione interna dei progetti e tutte le attività associate come le chiamate settimanali, il coordinamento dei team interni, il coinvolgimento dei fornitori esterni, il coordinamento delle modifiche ecc.

• Sincronizzazione degli input con cui inizia il progetto

Ci sono diversi vantaggi e motivi per cui è stata adottata una strategia per migrare all'istanza dedicata. È importante basare la visione sulla soluzione futura.

Sono previste modifiche come il consolidamento dei cluster, il dial plan, nuove funzionalità pianificate?

Migra gli endpoint software «così come sono» o la migrazione presuppone il passaggio all'app Webex?

Qual è il rapporto tra gli utenti e i contact center?

• Si metta al passo con Dedicated Instance

Introduzione all'istanza dedicata: Introduzione all'istanza dedicata

BDM (diapositive per i decisori aziendali) BDM

TDM (diapositive tecniche per i decisori) TDM.

Impatto sulla produzione: NESSUN impatto

La scoperta e la valutazione sono una continuazione e l'utilizzo delle informazioni ottenute durante le precedenti riunioni di sincronizzazione del team sugli input con l'obiettivo di identificare tutti gli elementi di ambito necessari, che costituiranno la base per lo sviluppo professionale del progetto e del piano tecnico di progetto

• Configurazione del cluster esistente

Definire la configurazione locale esistente con tutte le funzionalità e le integrazioni eseguite. Ecco gli esempi da guardare:

• Applicazioni e dimensionamento,
• Sedi,
• indirizzo IP,
• Come gli utenti hanno sincronizzato/effettuato il provisioning (locale, ldap),
• Autenticazione configurata (SSO),
• CA vs certificati autofirmati,
• modalità di sicurezza,
• utilizzo di ILS/GDPR,
• Caratteristiche,
• Particolare attenzione alle funzionalità intersito come, Extension Mobility
• integrazione CER/911,
• Uso della risonanza magnetica,
• CDR,
• Messaggi vocali e integrazione con O365,
• Jabber contro WebexApp
  • In caso di migrazione di Jabber, ci si dovrebbe concentrare molto sulla configurazione degli endpoint Jabber esistenti (ad esempio configurazione xml, dominio del servizio vocale) e quali sono le opzioni di riconfigurazione come l'uso di SCCM. Ecco gli scenari standard indicati: Configura Jabber
• Elenco dei dispositivi da controllare
  • Dispositivi obsoleti (non ci sono nuovi dispositivi aggiunti nell'elenco dei dispositivi obsoleti a partire da REL12.0x) Telefoni obsoleti
  • Dispositivi con fine del supporto (i dispositivi potrebbero essere ancora registrati per qualsiasi versione software, ma non sono supportati dal punto di vista del secondo giorno)
  • CSR-Compatibility-Matrix-Interactive.html
  • Dispositivi di restrizione speciali 7925, 7940, 7960 Registra i vecchi modelli di telefono su un'istanza dedicata
    • Strumenti in aiuto:

      Assistente dedicato alla pre-migrazione delle istanze: genera report di valutazione

      L'Assistente per la pre-migrazione in Control Hub La aiuta a raccogliere i dati di origine e a verificare i prerequisiti per la migrazione da UCM a un'istanza dedicata utilizzando uno strumento di terze parti. Prima della migrazione, valuta la disponibilità, fornisce liste di controllo e Le consente di confrontare i dati tra il suo cluster locale e l'istanza dedicata.

      Per eseguire Assistant, il suo cluster locale deve essere integrato nell'ambiente UC Webex Cloud-Connected. Descrizione generale e prerequisiti che può trovare qui: WebexCloud-ConnectEduc

      Processo di onboarding per UCM: configurazione di Webex Cloud Connected-UC

      Elenco di informazioni importanti che può ottenere come risultato da Pre-Migration Assistant in formato xls facilmente leggibile:

      • Nodi e software in esecuzione
      • Parametri aziendali
      • Elenco dei trunk SIP
      • Elenco degli utenti dell'applicazione, ruoli
      • Numero di dispositivi (e elenco completo dei dispositivi), gruppi di percorsi e partizioni, sedi, utenti finali
      • Gruppi CM, pool di dispositivi
      • Stato di integrità della replica DB
      • COP installati
      • Piani di numerazione
      • Servizi telefonici
      • Destinazioni remote
    • Webex Spaces per rispondere alle sue domande specifiche:

      Chiedi a UCM Cloud & Dedicated Instance: webexteams: //im? spazio=5db6bb40-d3c7-11e9-a319-df8a35abe85a

      Chiedi a RedSky External - E911 Solutions Plus Partner Unisciti a: https://eurl.io/#fWfT1SnOz

      Chieda a Webex Setup Assist - Webex Calling e DI: webexteams: //im? spazio=76beab50-084b-11ed-abc8-ab581010b1de.

Impatto sulla produzione: impatto minimo sull'ambiente di produzione esistente

Le migliori pratiche di Cisco in termini di processo di migrazione delle istanze dedicate sono rappresentate di seguito:

Peering/Connettività

Architettura di rete con descrizioni dettagliate degli scenari di Edge Connect perWebex Calling, istanze dedicate e riunioni. PA_Edge_Connect_Design.pdf

*Il documento deve essere usato con attenzione, poiché descrive più scenari che potrebbero essere in conflitto o integrarsi tra loro, dipende dal caso d'uso esatto. Il riferimento esatto all' istanza dedicata è disponibile nel capitolo «Edge Connect for Dedicated Instance Architecture»

Webex EdgeSi connetta

Webex EdgeConnect Domande più frequenti, note:

• I link dedicati all'Istanza 2 sono un «must»
• 4 link sono un'opzione ma il «incrocio» non è consentito, sono usati in «coppie»
• Qualsiasi prioritizzazione del traffico DI verso uno dei collegamenti NON è supportata e generalmente non applicabile, poiché ogni lato/DC pubblicizza la propria sottorete univoca /25 sedi di data center a istanze dedicate.

Ciò è spiegato anche nel documento sull'architettura di rete citato di seguito:

Impatto sulla produzione: con impatto limitato ai processi operativi

Lo scopo della fase di congelamento è spostare i dati dal sistema di origine all'istanza dedicata di destinazione ed eseguire le convalide necessarie per garantire il successo del cutover. Consigliamo un lasso di tempo di 2-3 settimane per il blocco per assicurarci che i team abbiano il tempo necessario per lo spostamento dei dati, i controlli di coerenza dei dati, i failover dei test e i relativi test.

Nel caso in cui sia necessario il MACD durante la fase di congelamento, le modifiche richieste devono essere completate su entrambi i sistemi.

Sono disponibili diversi modi e strumenti per lo spostamento/la copia dei dati. In generale, consigliamo di utilizzare le partizioni e gli strumenti attivi/inattivi come indicato di seguito:

UCM:

Esportazione/importazione BAT e script associati

Guida all'amministrazione in blocco perCisco Unified Communications Manager, Release 15 e SUS: CUCM_b_bulk-administration-guide-15.html.

Strumenti esterni per le migrazioni UCM come Yarnlab.

Unità:

• Cisco UnityUtensili. Raccolta di strumenti gratuiti Cisco Unity e Cisco Unity Connection correlati.

https://www.ciscounitytools.com/index.html

Consigliamo l'uso di Cobras per le migrazioni di Unity.

CER:

Manuale, esportazione/importazione in blocco

Dopo lo spostamento dei dati di configurazione, consideri i prossimi elementi/azioni importanti:

• Manuale o tramite l'opzione 150 su DHCP in relazione al reindirizzamento in gruppo di test di diversi modelli di telefono al nuovo DI TFTP. Fatto il consolidamento dei certificati, può testare entrambi: scenario di migrazione e rollback
• Riconfigurazione del gateway di test, se disponibile
• Preparazione dei modelli di configurazione dei gateway per i cutover di produzione effettivi. Scripting, se necessario.
• Trasferimento dell'utente WebexApp tramite modifica del comportamento di chiamata presso CH
• Trasferimento di Jabber tramite il metodo di accesso definito in precedenza e la modifica del cluster principale
• Test dei flussi di chiamata e delle funzionalità di base fino alle capacità dell'ambiente:
  • Verifica della coerenza del comportamento in rete o connesso tramite VPN
  • Test di MRA con telefono e endpoint software
  • PSTN
  • Test del servizio 911

• Supporto per istanze dedicate di primo livello (TAC) Supporto per istanze dedicate di primo livello

• Richieste di assistenza associate agli argomenti elencati: Come inviare una richiesta di assistenza
  • Inserimento DNS
  • Aggiornamenti del firewall
  • Caricamento del firmware
  • Connettività al cloud
  • Impostazioni del registro di controllo
  • Gestione delle applicazioni UC
  • Trunk SIP DI-MT Inter-op
  • Ciclo di vita delle applicazioni UC
  • Infrastruttura come servizio
    • Guida operativa per i partner

• Guida operativa per i partner

  Questo è uno dei documenti più importanti che spiega il supporto tecnico, la gestione delle modifiche, la gestione degli incidenti, gli aggiornamenti, gli upgrade, la gestione della capacità, la gestione dei certificati, la guida operativa per i partner DRS

Questo è uno dei documenti più importanti che spiega il supporto tecnico, la gestione delle modifiche, la gestione degli incidenti, gli aggiornamenti, gli upgrade, la gestione della capacità, la gestione dei certificati, la guida operativa dei partner DRS

• Matrice di responsabilità

Il documento spiega la divisione RACI tra Partner, Cisco e Cliente durante l'onboarding e la matrice di assegnazione della responsabilità operativa

• Chieda a RedSky Webex Space webexteams: //im? spazio=7074fce0-489a-11ea-89f3-8f977dd07aa0.