Este artículo proporciona un marco de migración estructurado y de autoservicio para socios y clientes que migran entornos de llamadas aWebex Calling: instancia dedicada (DI).

Las prácticas e hitos de migración descritos en este artículo se basan en la metodología del programa Webex Setup Assist y reflejan la amplia experiencia en el mundo real de los equipos de entrega, ingeniería y desarrollo de Cisco. Estos métodos se han perfeccionado a través de cientos de miles de implementaciones únicas en ubicaciones de clientes en los últimos siete años, incluidas migraciones desde BroadCloud, BroadWorks, Spark Calling Unified CM (UCM), Hosted Collaboration Solution (HCS) y plataformas PBX de terceros. La guía se aplica a una amplia gama de entornos de clientes, desde implementaciones en un solo asiento hasta implementaciones a gran escala que superan los 100,000 asientos y cientos de ubicaciones, y sigue los procesos Cisco probados desde hace mucho tiempo para garantizar la consistencia, la calidad y la eficiencia operativa durante todo el ciclo de vida de la migración.

El artículo asume que los lectores ya están familiarizados con Webex Calling las licencias de instancias dedicadas, el modelo administrativo de Webex Control Hub y el software y las características básicas de Unified Communications Manager.

Seamos honestos: la palabra migración rara vez suscita entusiasmo en un equipo de TI. Esto suscita preguntas. “¿Qué se rompe?” “¿Quién hace el trabajo?” “¿Sobre qué perdemos el control?” “¿Es esto incluso realista mientras ya estamos estirados manteniendo las luces encendidas?” Estos no son signos de resistencia al progreso; son los instintos de profesionales experimentados que entienden que mover una plataforma de llamadas de misión crítica no es un proyecto de fin de semana. Voice es el único servicio en el que los usuarios notan una falla de dos segundos antes de que se den cuenta de un esfuerzo de planificación de interrupciones de dos semanas, y esa realidad hace que cada cambio se sienta más pesado de lo que debería.

¿Las buenas noticias? Los números cuentan una historia muy diferente a la del miedo. En migraciones a la nube bien estructuradas, aproximadamente el 95% del esfuerzo de ingeniería se invierte en la preparación y solo el 5% en el cambio real. Aún mejor, la mayor parte de ese 95% se compone de actividades que su equipo ya realiza como parte de las operaciones normales del día 2: higiene de inventario, gestión de certificados, revisiones de planes de marcado, seguimiento del ciclo de vida del dispositivo y documentación. En otras palabras, la mayor parte del “trabajo de migración” es un trabajo que ya está haciendo. Este enfoque estructurado simplemente lo canaliza hacia un resultado definido, a un ritmo que encaja dentro de su ritmo operativo existente en lugar de encima de él.

La sensación de “misión imposible” también se desvanece una vez que ve que cada migración puede ser completamente ensayada. Un piloto pequeño y representativo le permite validar el proceso de extremo a extremo, las integraciones, el comportamiento de conmutación por error y la experiencia del usuario antes de que se toque a un solo usuario de producción. Nada se deja al azar el día de corte, porque el día de corte es simplemente la repetición de un proceso que ya ha ejecutado con éxito. Y en caso de que ocurra algo inesperado, la reversión es un espejo del corte en sí, delimitado por una ventana de mantenimiento clara. La previsibilidad reemplaza a la ansiedad.

Sí, pasar a una instancia dedicada significa dejar de lado cierto control, específicamente sobre las capas de infraestructura y virtualización. Pero considere lo que gana: las horas que su equipo pasa parcheando hipervisores, persiguiendo alertas de hardware, administrando la seguridad a nivel de SO y planificando actualizaciones de capacidad. Ese tiempo regresa al negocio, donde se puede gastar en lo que realmente diferencia a su organización: la experiencia del usuario, la adopción, las integraciones y los servicios que realmente preocupan a sus partes interesadas. No está perdiendo el control; está negociando el trabajo pesado indiferenciado por un enfoque estratégico.

Lo que recibe a cambio es una plataforma estrechamente integrada con la cartera de llamadas, reuniones y centros de contacto más avanzada del mercado, respaldada por la profundidad de ingeniería de Cisco y un ecosistema de partners refinado a través de cientos de miles de implementaciones. Mantiene todo el poder del Unified CM ecosistema familiar, las mismas características, la misma confiabilidad, el mismo modelo administrativo que su equipo ya conoce, ahora combinado con Control Hub, un paraguas de administración y análisis moderno y orientado al usuario que es realmente fácil de aprender. Cisco administra las actualizaciones, las actualizaciones y la aplicación de parches de vulnerabilidades críticas en el software más reciente, en computación certificada por Cisco, con la misma (o mejor) confiabilidad que espera de su entorno local.

Entonces, sí, el cambio conlleva riesgos. Pero no cambiar conlleva su propio riesgo más silencioso: quedarse atrás en las funciones, abordar la complejidad constante de los cambios, lanzar actualizaciones y vulnerabilidades, ampliar su equipo en una infraestructura que ya no diferencia al negocio y retrasar una transición inevitable hasta que deba hacerse bajo presión. El enfoque estructurado y cerrado que sigue está diseñado para hacer de esta migración lo que debería ser: bien preparada, poco dramatizada y altamente validada, ejecutada principalmente a través del trabajo que ya está haciendo, hacia una plataforma construida para donde la colaboración se dirige a continuación.

De la confianza a un plan: cómo se organiza esta guía

Para convertir esa confianza en una hoja de ruta ejecutable, esta guía lo guía a través de un proceso de migración de siete puertas, cada fase con criterios claros de entrada y salida, lecciones aprendidas del campo y verificaciones previas que evitan las sorpresas más comunes:

• Iniciación del proyecto
• Descubrimiento y evaluación
• Planeación
• Implementación
• Congelar
• Vaya en vivo
• Traslado al día 2

Una de las razones por las que este modelo funciona tan bien es que el riesgo para su entorno de producción es deliberadamente frontal a casi cero y solo aumenta en un paso final controlado. Esto es lo que puede esperar en cada etapa:

Impacto en la producción	Fases
Sin impacto	Iniciación del proyecto, descubrimiento y evaluación, planificación
Impacto mínimo	Implementación
Limitado a los procesos de operaciones	Congelar
Impacto directo	Vaya en vivo

En términos prácticos: la mayor parte del viaje ocurre de manera segura junto con su entorno existente. Para cuando llegue al momento en que toca la producción, se ha construido cada integración, se ha ensayado cada proceso y se ha verificado cada retroceso.

A lo largo de la guía, hacemos referencia a los recursos de información clave en los que confiará durante la migración y hasta bien entrado el día 2:

• Cisco Calling Sales Connect — Enlace de Cisco Calling Sales Connect
• Help.webex.com: documentación autorizada del producto y de la configuración
• Webex Spaces: acceso directo a expertos de Cisco y comunidades de pares para preguntas en tiempo real

Con el marco establecido y los recursos en la mano, analicemos cada fase en detalle, comenzando por donde comienza cada migración exitosa: Iniciación del proyecto.

Impacto en la producción: SIN impacto

• Identificar a las partes interesadas clave

Recuerde que no se trata solo de equipos técnicos y equipos comerciales impactados, sino también de socios involucrados. Este es el ejemplo de las partes interesadas requeridas:

• Administración de TI
• Administración de empresas
• Equipo de servicios de voz
• Equipo de centros de contacto
• Equipo de redes
• Equipo DNS/DHCP
• Equipo de seguridad
• Equipo de IAM (por ejemplo, Entra, AD, SSO)
• Cambiar tablero
• Socio de MACD
• Socio de servicios gestionados
• Proveedores de integración de terceros (paginación, fax, grabación, etc.)
• Soporte local local en las locales
• RedSky /Equipo de seguridad pública.

• Elección de líder de proyecto o gerente de proyecto.

Teniendo en cuenta que las migraciones a la instancia dedicada implican una coordinación más compleja que las integraciones tradicionales “solo a nivel de aplicación”, es deseable tener un miembro del equipo asignado para dirigir la gestión interna del proyecto y todas las tareas asociadas, como llamadas semanales, coordinación de equipos internos, participación de proveedores externos, coordinación de cambios , etc.

• Sincronice las entradas con las que comienza el proyecto

Existen múltiples ventajas y razones por las que se ha tomado una estrategia para migrar a una instancia dedicada. Es importante basar la visión sobre la solución futura.

¿Hay algún cambio como consolidación de clústeres, plan de marcado, nuevas funciones planificadas?

¿Migra los puntos finales de software “tal cual” o la migración supone que se traslada a la aplicación Webex?

¿Cuál es la relación de los usuarios con los centros de contacto?

• Ponte al día con la Instancia Dedicada

Introducción a la instancia dedicada: Introducción a la instancia dedicada

BDM (Diapositivas para tomador de decisiones empresariales) BDM

TDM (Diapositivas para la toma de decisiones técnicas) TDM.

Impacto en la producción: SIN impacto

El descubrimiento y la evaluación son una continuación y la utilización de la información que se obtuvo durante reuniones anteriores de sincronización del equipo en las entradas con el objetivo de identificar todos los elementos de alcance necesarios que serán la base para el desarrollo profesional del proyecto y del plan técnico del proyecto

• Configuración de clúster existente

Defina la configuración on-prem existente con todas las funciones e integraciones realizadas. Estos son los ejemplos a tener en cuenta:

• Aplicaciones y tamaño,
• Ubicaciones,
• Direccionamiento IP,
• Cómo se sincronizan/aprovisionaron los usuarios (local, ldap),
• Autenticación configurada (SSO),
• CA vs certificados autofirmados,
• Modo de seguridad,
• Uso de ILS/GDPR,
• Características,
• Enfoque especial en características multisitio como, Extension Mobility
• Integración CER/911,
• Uso de MRA,
• CDR,
• Mensajes de voz e integración con O365,
• Jabber contra WebExApp
  • En caso de migración de Jabber, debe centrarse mucho en cómo se configuran los puntos finales de Jabber existentes (por ejemplo, configuración xml, dominio de servicio de voz) y cuáles son las opciones para la reconfiguración, como el uso de SCCM. Aquí se indican los escenarios estándar: Configurar Jabber
• Lista de dispositivos con enfoque para verificar
  • Dispositivos en desuso (no se han agregado dispositivos nuevos en la lista de obsoleto desde REL12.0x) Teléfonos en desuso
  • Dispositivos de fin de soporte (los dispositivos aún podrían estar registrados en cualquier versión de software, pero no son compatibles desde la perspectiva del día 2)
  • CSR-Compatibility-Matrix-Interactive.html
  • Dispositivos especiales de restricción 7925, 7940, 7960 Registrar modelos de teléfono antiguos en una instancia dedicada
    • Herramientas en ayuda:

      Asistente de pre-migración de instancia dedicada: Generar informes de evaluación

      El Asistente previo a la migración en Control Hub le ayuda a recopilar datos de origen y verificar los requisitos previos para migrar de UCM a una instancia dedicada utilizando una herramienta de terceros. Antes de la migración, evalúa la preparación, proporciona listas de verificación y le permite comparar datos entre su clúster local y la instancia dedicada.

      Para ejecutar Assistant, su clúster on-prem debe estar integrado en el entorno de UC conectado a la nube de Webex. Descripción general y requisitos previos que puede encontrar aquí: WebExcloud-ConnecteDUC

      Proceso de incorporación para UCM: Configuración de Webex Cloud Connected-UC

      Lista de información importante que puede obtener como resultado de Pre-Migration Assistant en formato xls fácilmente legible:

      • Nodos y software en ejecución
      • Parámetros empresariales
      • Lista de troncales SIP
      • Lista de usuarios de aplicaciones, roles
      • Número de dispositivos (y lista completa de dispositivos), grupos de rutas y particiones, ubicaciones, usuarios finales
      • Grupos CM, Grupos de dispositivos
      • Estado de estado de la replicación de la base de datos
      • COP instalados
      • Planes de numeración
      • Servicios telefónicos
      • Destinos remotos
    • Webex Spaces para ayudar con sus preguntas específicas:

      Pregunte a UCM Cloud e instancia dedicada: webexteams: //im? espacio=5db6bb40-d3c7-11e9-a319-df8a35abe85a

      Pregunte a RedSky External - E911 Solutions Plus Partner Únase a: https://eurl.io/#fWfT1SnOz

      Pregunte a Webex Setup Assist Webex Calling y DI: webexteams: //im? espacio=76beab50-084b-11ed-abc8-ab581010b1de.

Impacto en la producción: impacto mínimo en el entorno de producción existente

Las mejores prácticas de Cisco en términos del proceso de migración de instancias dedicadas se representan a continuación:

Peering/Conectividad

Arquitectura de red con descripciones detalladas de escenarios de conexión Edge para Webex Calling instancias dedicadas y reuniones. PA_Edge_Connect_Design.pdf

*El documento debe usarse con cuidado, como describe múltiples escenarios que podrían ser contradictorios o complementarse entre sí, dependiendo del caso de uso exacto. La referencia exacta a la instancia dedicada se puede encontrar en el capítulo “Edge Connect para arquitectura de instancia dedicada “

Webex EdgeConectar

Webex EdgeConectar Preguntas más comunes, señala:

• Los enlaces de la Instancia 2 dedicada son una “necesidad”
• 4 enlaces es una opción, pero “cruzar” no está permitido, esos se usan en “pares”
• Cualquier priorización de tráfico DI hacia uno de los enlaces NO es compatible y, por lo general , no es aplicable, ya que cada lado/DC anuncia su subred única/25 ubicaciones de centros de datos de instancia dedicada.

Esto también se explica en el documento de Arquitectura de red mencionado a continuación:

Impacto en la producción: con impacto limitado a los procesos de operaciones

El propósito de la fase de congelación es mover los datos del sistema de origen a la instancia dedicada de destino y ejecutar las validaciones necesarias para asegurar una transferencia exitosa. Recomendamos un plazo de 2 a 3 semanas para la congelación para asegurarse de que los equipos tengan el tiempo necesario para el movimiento de datos, verificaciones de consistencia de datos, conmutación por error de prueba y pruebas relacionadas.

En caso de que se necesite MACD durante la fase de congelación, los cambios requeridos deben completarse en ambos sistemas.

Hay múltiples formas y herramientas disponibles para mover/copiar datos. En general, recomendamos utilizar particiones y herramientas activas/inactivas como se indica a continuación:

UCM:

Exportación/importación de BAT y secuencias de comandos asociadas

Guía de administración masiva paraCisco Unified Communications Manager, versión 15 y SUs: CUCM_b_bulk-administration-guide-15.html.

Herramientas externas para migraciones UCM como Yarnlab.

Unidad:

• Cisco UnityHerramientas. Colección de herramientas gratuitas Cisco Unity y Cisco Unity Connection relacionadas.

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

Recomendamos el uso de Cobras para migraciones de Unity.

CER:

Manual, Exportación/Importación a granel

Al mover los datos de configuración, considere los siguientes ítems o acciones importantes:

• Manual o a través de la opción 150 en DHCP en relación con el redireccionamiento del grupo de prueba de diferentes modelos de teléfono al nuevo DI TFTP. Una vez realizada la consolidación de certificados, puede probar ambos: escenario de migración y retroceso
• Reconfiguración de la puerta de enlace de prueba, si está disponible
• Preparación de plantillas de configuración de Gateways para los recortes de producción reales. Guión, si es necesario.
• Traspaso del usuario WebExApp a través del cambio de comportamiento de llamadas en CH
• Movimiento de Jabber a través del método de inicio de sesión definido previamente y el cambio de clúster de inicio
• Prueba de los flujos básicos de llamadas y la funcionalidad hasta las capacidades del entorno:
  • Comprobación de la consistencia del comportamiento al estar en la red o conectado a través de VPN
  • Prueba de MRA con teléfono y punto final de software
  • PSTN
  • Prueba del servicio 911

• Soporte de instancia dedicada de nivel 1 (TAC) Soporte de instancia dedicada de nivel 1

• Solicitudes de servicio asociadas con temas enumerados: Cómo presentar una solicitud de servicio
  • Entrada DNS
  • Actualizaciones del cortafuegos
  • Carga de firmware
  • Conectividad en la nube
  • Configuración del registro de auditoría
  • Administración de aplicaciones UC
  • Truncos SIP interop DI-MT
  • Ciclo de vida de la aplicación UC
  • Infraestructura como servicio
    • Guía de operaciones para socios

• Guía de operaciones para socios

  Este es uno de los documentos más importantes que explica el soporte técnico, la gestión de cambios, la gestión de incidentes, las actualizaciones, las actualizaciones, la gestión de la capacidad, la gestión de certificados, la guía de operaciones para socios de DRS

Este es uno de los documentos más importantes que explica soporte técnico, gestión de cambios, administración de incidentes, actualizaciones, actualizaciones, administración de capacidad, administración de certificados, guía de operaciones para socios de DRS

• Matriz de responsabilidad

El documento explica la división de RACI entre Partner, Cisco y Cliente durante la incorporación y la matriz de asignación de responsabilidad de operaciones

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