Dos caminos para migrar de BroadWorks a Ribbon AS Standalone
El plan se enfoca en 181 entidades — quedan dos caminos posibles para sacarlas de BroadWorks
BroadWorks llegó a su fin de vida útil y de soporte del fabricante. El plan de migración se enfoca en 181 entidades de Gobierno, ya con dominio raíz creado en el AS Ribbon. Las 17 entidades restantes de BroadWorks sin correspondencia confirmada quedan diferidas al final de la migración. Para sacar estas 181 entidades de BroadWorks se identificaron dos mecanismos técnicos genuinamente distintos — no son excluyentes, y el resto de esta presentación los compara en detalle.
¿Cómo se saca cada entidad de BroadWorks?
Redirección en el cluster de SBC Oracle — sin visita de sitio
Cada entidad tiene su propia SIP Interface en el cluster de SBC. Se redirige el dominio de la entidad para que apunte al AS Ribbon en vez de BroadWorks — sin tocar el teléfono ni el switch de la sede. Precondición crítica: recuperar/preservar el SIP password de cada subscriptor (ver sección Riesgos).
- No requiere técnico de sitio ni coordinar agenda con cada sede — cero visitas físicas.
- Corte casi instantáneo por entidad: es un cambio de enrutamiento en el SBC, no miles de intervenciones físicas.
- Desacopla "salir de BroadWorks" (la urgencia real, fin de soporte) de "modernizar el parque de dispositivos" (un objetivo distinto, sin la misma urgencia).
- Costo de recursos bajo: solo reconfiguración del SBC + validación del SOC.
- El módulo ACS de gestión de dispositivos de Ribbon no se usa — los teléfonos siguen con configuración manual, indefinidamente.
- Solo se puede migrar la entidad completa de una vez — no hay forma de redirigir solo algunas sedes.
Técnico de sitio + gestión ACS
Un técnico reconfigura cada teléfono y habilita DHCP option 66 en el switch de la sede, dejando los dispositivos soportados bajo gestión zero-touch de ACS. Requiere visitar hasta 849 sedes físicas dentro del alcance de 181 entidades.
- Modernización real del parque — gestión centralizada futura (contraseñas, firmware, reemplazos) sin necesidad de visita.
- Abre la puerta a decidir el reemplazo de hardware no soportado por ACS.
- Permite fasear tanto por entidad completa como por sede dentro de una entidad grande.
- Riesgo distribuido y contenible: un teléfono/sede a la vez, fácil de revertir.
- Requiere visitar hasta 849 sedes físicas reales — la ruta más lenta y más cara en dotación de personal.
- No se puede paralelizar más allá de la cantidad de cuadrillas contratadas.
- El 43,4% de los dispositivos actuales no está soportado por ACS y exige una decisión de reemplazo aparte.
Los mismos tres pilares, con distinto peso según la opción
La Herramienta de migración (OPI hacia el AS) es obligatoria en ambas opciones — lo que cambia es si hace falta o no desplegar personal en sitio. Haga clic en cada recurso para ver su función en detalle.
Opción 1 — Migración remota
Opción 2 — Migración personal en sitio
Por entidad completa (Opción 1) o por sede (Opción 2)
Así se ve en la práctica, paso a paso, dentro de cada opción.
Opción 1 — por entidad completa
- Extraer/preservar el SIP passwordDe cada subscriptor de la entidad, desde BroadWorks.
- Cargar credenciales en el ASVía OPI, replicando usuario y password tal cual los tiene el teléfono hoy.
- Redirigir el dominio en el SBCCambiar el enrutamiento de la SIP Interface de la entidad hacia el AS.
- Validar registro y llamada de pruebaSOC confirma registro SIP exitoso, llamada entrante/saliente y buzón de voz.
Opción 2 — por sede, dentro de la entidad
- Preparar el paquete de la sedeLa Herramienta #1 entrega MAC/usuario/categoría y credenciales nuevas por teléfono.
- Habilitar DHCP option 66Una sola vez, en el switch/DHCP de la sede.
- Reconfigurar cada teléfonoSoportados: pasar a DHCP y auto-aprovisionar vía ACS. No soportados: configurar a mano.
- Prueba de llamada y buzón de voz100% en sedes chicas, muestra representativa en sedes grandes.
- Reportar estado al SOCMigrado OK / con incidencia, por cada dispositivo de la sede.
De semanas a meses, según la opción elegida
Cifras de orden de magnitud, no un compromiso — dependen de piloto real y de datos que faltan por confirmar.
Tres frentes abiertos antes de comprometer un cronograma final
Viabilidad de recuperar el SIP password
La Opción 1 depende de autenticar cada teléfono en el AS con la misma contraseña SIP que ya tiene guardada. Si BroadWorks solo expone un hash no reversible, la opción "cero-touch" deja de ser viable.
El AS hoy solo acepta username en minúsculas
El campo "User name" del AS no admite mayúsculas. Ribbon trabaja en un hot patch para soportar mayúsculas y minúsculas mezcladas (no para pasar a solo-mayúsculas). Afecta al 11,5% de los usuarios y 18,0% de los usernames de dispositivo de BroadWorks, con 119 pares que colisionarían si se normaliza todo a minúsculas. En la Opción 2 no aplica: el técnico en sitio reconfigura el teléfono y puede fijar un username congruente con el que se cree en el AS.
43,4% de dispositivos sin soporte ACS
15.662 de los 36.086 dispositivos en alcance (43,4%) no están soportados por SIP ACS — quedan en aprovisionamiento manual permanente salvo que se decida reemplazarlos.
No son excluyentes: dos capas complementarias
La forma más eficiente de leer estas dos opciones es como dos capas del proyecto, con objetivos distintos, que pueden ejecutarse en paralelo y a ritmos distintos.
"Salir de BroadWorks" — Migración remota
Responde a la urgencia real del proyecto (fin de soporte de BroadSoft). Se aplica, entidad por entidad, apenas se confirme la precondición del SIP password — del orden de 20 a 22 semanas para las 181 entidades, sin necesidad de visitar ninguna sede.
"Modernizar el parque" — Personal en sitio
Lleva los dispositivos soportados a gestión zero-touch. Puede correr después, en paralelo y sin presión de fecha, al ritmo que el presupuesto de cuadrillas permita — del orden de 10 meses para las 849 sedes.
Adoptar el enfoque de dos capas (Capa 1 rápida + Capa 2 de modernización continua), sobre las 181 entidades confirmadas — dejando las 17 diferidas para el final.
Lo que falta confirmar para fijar el cronograma final
- Confirmar con BroadWorks si el SIP password se puede extraer/cargar en el ASPrioridad 1
- Dar seguimiento con Ribbon al hot patch de username mixto (mayúsculas/minúsculas)Prioridad 1
- Definir cuántas capas se adoptan y sobre qué subconjunto de las 181Decisión CWP
- Definir cuadrillas de técnico de sitio disponibles para la Opción 2Insumo pendiente
- Elegir entidades piloto para cada capa y ejecutar el primer corteSiguiente hito
Con el SIP password confirmado y las cuadrillas definidas, se puede fijar una fecha real de cierre de BroadWorks para las 181 entidades — hoy el rango de 20-22 semanas (Capa 1) y ~10 meses (Capa 2) es ilustrativo.
Gracias. Quedamos atentos a sus comentarios.
El objetivo compartido es sacar a las 181 entidades de Gobierno de BroadWorks con el menor riesgo posible, decidiendo con datos reales — no supuestos — qué combinación de las dos capas conviene a CWP.