Cómo migrar tu central telefónica a la nube en 2026: guía paso a paso

Si tu central telefónica tiene más de 8-10 años, dejó de tener soporte del fabricante, o ya no aguanta la cantidad de gente trabajando remoto y desde sucursales, tarde o temprano vas a evaluar moverla a la nube. La pregunta deja de ser si migrar y pasa a ser cuándo y cómo hacerlo sin romper el negocio en el camino.

Esta guía no es un brochure: es el cronograma real que aplicamos en proyectos de migración. Vas a encontrar las decisiones técnicas que vas a tener que tomar, los 8 pasos del proyecto, los errores frecuentes y cuánto tarda realmente según el tamaño de tu empresa.

Por qué las empresas están migrando (los drivers reales)

Los motivos que aparecen en propuestas comerciales y los que realmente disparan el proyecto son distintos. En la práctica, una migración a central virtual se acelera por una de estas razones:

• El hardware está al final de su vida útil. PBX con más de 10 años, tarjetas E1 que ya no se consiguen, vendors que dejaron de dar soporte (caso típico: Nortel, líneas legacy de Avaya, Panasonic descontinuados). Cuando se rompe una tarjeta y no hay repuesto, la decisión se acelera sola.
• Necesitan trabajar desde cualquier lado. El home office estable y el modelo híbrido hicieron que las extensiones físicas dejaran de tener sentido. Una central virtual da extensión en el celular, la laptop o en cualquier IP phone con internet.
• Las sucursales son un dolor de cabeza. Cada sucursal con su propia centralita chica, troncales locales y dial-plans inconsistentes. La cloud unifica eso en un único sistema con un solo plan de marcado.
• Quieren métricas y grabación que la PBX no da. Reportería de llamadas atendidas, abandonadas, tiempos de espera, grabación con búsqueda, integración con CRM. La PBX tradicional puede dar algo, pero requiere módulos pagos por separado o no escala.
• El CapEx no cierra más. Renovar una PBX hoy son entre USD 15.000 y 80.000+ de inversión inicial. La nube lo convierte en un OpEx mensual previsible.

Si te identificás con dos o más de estos, ya hay caso. Lo que sigue es cómo hacerlo bien.

Antes de empezar: el inventario obligatorio

El error más común es lanzarse a comparar proveedores antes de saber qué se tiene. La migración bien hecha empieza con un discovery técnico. Si tu proveedor no te pide esta información, mala señal: están vendiendo una solución sin entender el problema.

Inventario de la planta actual

• Marca y modelo de la PBX, versión de firmware.
• Cantidad de extensiones activas (no las habilitadas — las que efectivamente se usan).
• Tipo de extensiones: analógicas, digitales, IP.
• Teléfonos físicos: cantidad, marca, modelo.
• Troncales: cuántas líneas analógicas, E1/R2, SIP trunks. Carrier de cada una.
• Gateways y ATAs si los hubiera.
• Equipos legacy conectados: fax, alarmas, ascensores con teléfono, intercomunicadores.

Tráfico real, no el percibido

Pedile a tu PBX (o a tu carrier) los CDRs (Call Detail Records) de los últimos 3-6 meses. Lo que necesitás saber:

• BHCA (Busy Hour Call Attempts): intentos de llamada en la hora pico.
• Simultaneidad máxima: cuántas llamadas activas hay en el peor momento del día.
• Distribución entrante/saliente.
• Duración promedio y picos por hora.
• Llamadas internas vs externas.

Estos números definen cuánta licencia y ancho de banda vas a necesitar. Sin esto, los proveedores te van a sobredimensionar (más caro) o subdimensionar (rompe el día 1).

Integraciones que no se pueden romper

Lista todo lo que hoy se conecta a la PBX:

• CRM con click-to-call o screen pop (Salesforce, HubSpot, Zoho, otros).
• ERP con registro de llamadas.
• Ticketing (Zendesk, Freshdesk, Jira Service Management).
• Software de fax sobre IP (T.38).
• Sistemas de alarma o seguridad que usan la línea.
• Grabadores externos, dashboards de KPIs.

Cualquier integración debe estar mapeada antes de elegir plataforma cloud — algunas centrales virtuales tienen integraciones nativas, otras requieren middleware o API.

Numeración y portabilidad

• DIDs actuales (números directos): listado completo.
• ¿Hay que portar todos o se pueden retirar algunos?
• ¿Qué carrier los tiene hoy? Importante: el plazo de portabilidad en Argentina es de 5 a 10 días hábiles según el destino.
• ¿Hay rangos con numeración corporativa (ej: 5500 a 5599)?

Decisiones técnicas clave

Modelo de despliegue

Modelo	Cuándo usarlo
Cloud puro (UCaaS)	La opción default hoy. La central vive 100% en la nube del proveedor. Vos solo necesitás teléfonos IP, softphones e internet decente.
Híbrido (gateway on-prem)	Si tenés muchas extensiones analógicas legacy difíciles de reemplazar (fax, alarmas, faxes médicos), un gateway local las traduce a SIP hacia la nube.
Hosted dedicado	Una instancia propia (no compartida) en infraestructura del proveedor. Más caro pero permite customización profunda. Lo eligen banca, salud, contact centers grandes.

Codec y ancho de banda

El codec define la calidad y el consumo. Las opciones serias hoy:

Codec	Bitrate por llamada (con overhead)	Cuándo usarlo
G.711	~85-100 kbps	Calidad máxima, internet sobrado
G.722 (HD)	~95-110 kbps	Voz HD, recomendado si tu red lo banca
G.729	~30-40 kbps	Compresión alta, links angostos
Opus	~25-90 kbps adaptativo	Estado del arte, calidad variable según red

Regla práctica para dimensionar internet: tomá la simultaneidad pico y multiplicá por el bitrate del codec. Por ejemplo, 30 llamadas simultáneas con G.711 = ~3 Mbps solo de voz. Reservá QoS y banda dedicada.

QoS (Quality of Service)

La voz no convive bien con el resto del tráfico sin reglas. Si tu router corporativo no tiene QoS configurada para priorizar voz (DSCP EF), la calidad se va a degradar el día que alguien baje un archivo grande o se haga un backup. Esto es no negociable — sin QoS no hay migración exitosa.

Endpoints: ¿softphone, IP phone o ambos?

• Softphone (Linphone, Bria, app del proveedor): cero hardware, perfecto para home office y movilidad. Necesita auriculares decentes con micrófono.
• IP phone físico (Yealink, Grandstream, Polycom): mejor para puestos fijos, gente que está todo el día al teléfono, recepción.
• Mix: lo más común. IPs en puestos fijos, softphone en remoto.

Importante: si vas a reusar IP phones existentes, validá que el proveedor cloud soporte el modelo y firmware actual. No siempre es directo.

Los 8 pasos del proyecto de migración

1. Discovery y inventario (2-3 semanas)

Lo descripto arriba. Es el paso más subestimado y el que más arruina los proyectos cuando se hace mal.

2. Diseño y dimensionamiento (1-2 semanas)

• Definición del modelo de despliegue.
• Mapeo de extensiones, grupos, colas, IVRs, horarios.
• Dial-plan unificado entre sucursales.
• Plan de portabilidad de DIDs.
• Definición de roles y permisos en la plataforma.
• Documentación funcional aprobada por el cliente antes de provisionar.

3. Network readiness (en paralelo)

• Test de red: jitter, latencia, pérdida de paquetes, ancho de banda real.
• Configuración de QoS en routers y switches.
• Apertura de puertos SIP/RTP en firewall (típicamente UDP 10000-20000 RTP + 5060/5061 SIP).
• VLAN separada para voz si la red lo permite.
• Validación de internet redundante o failover si el caso lo amerita.

4. Provisioning y build (1-3 semanas)

El proveedor carga la configuración en la plataforma: extensiones, grupos, IVR, colas, mensajes de bienvenida, integraciones. Se prepara una versión “espejo” del entorno actual mejorada.

5. Piloto controlado (1-2 semanas)

Un subconjunto chico de usuarios (5-15) usa la nueva central en paralelo a la vieja. Idealmente IT, ventas y un sector crítico. Se valida:

• Calidad de audio en distintos escenarios.
• Funcionamiento de transferencias, conferencias, grabación.
• Llamadas a celular, llamadas internacionales, números especiales.
• Funcionamiento de softphone en home office.
• Integraciones con CRM.

Si algo falla en piloto, no se sigue. Se corrige antes del cutover masivo.

6. Capacitación

• Capacitación a usuarios finales (1 hora, suele alcanzar — la UX moderna es intuitiva).
• Capacitación a administradores (4-8 horas — uso del panel, reportería, cambios básicos).
• Documentación de procedimientos para soporte interno.
• Capacitación específica a recepción y call center si aplica.

7. Cutover (1 día crítico)

• Idealmente fuera de hora pico (típicamente viernes a la noche o sábado a la mañana).
• Portabilidad de DIDs ya programada con el carrier — momento más sensible.
• Apagado controlado de la PBX vieja. No se desconecta físicamente hasta confirmar todo OK.
• Validación de cada DID portado.
• Soporte presencial o remoto extendido las primeras 48-72hs.

8. Hypercare post-cutover (2-4 semanas)

• Soporte priorizado: tiempos de respuesta menores.
• Ajustes finos sobre la marcha.
• Análisis de los primeros reportes de uso real.
• Optimización de IVR, colas y horarios según comportamiento observado.

Errores frecuentes que cuestan caro

• No portar los DIDs y dejarlos en redirección permanente. Funciona los primeros 6 meses, pero un día el carrier viejo discontinúa el servicio y se cae todo. Hay que portar.
• Ignorar las extensiones analógicas raras. El fax del departamento de legales, la línea del ascensor, la alarma. Si no se planifican antes, quedan colgadas el día 1.
• No probar internet en sucursales chicas. La oficina principal anda perfecto, pero la sucursal con 20 Mbps compartido tiene cortes de voz. Network readiness aplica para todos los sitios.
• Saltarse el piloto por presión comercial. “Lo necesitamos para el lunes” termina en cutover el viernes sin pruebas. El que sufre es el usuario final el lunes a la mañana.
• No documentar el dial-plan viejo antes de apagarlo. Cuando alguien pregunta “¿por qué la cola del 4711 desviaba a tal teléfono?”, nadie se acuerda. Documentar antes.
• Subestimar la capacitación. El usuario final no lee documentos. 30-45 min sincrónicos con ejemplos en vivo previenen el 80% de los tickets de los primeros días.
• Comparar proveedores solo por precio mensual. El costo total de propiedad incluye implementación, portabilidad, hardware si se reemplaza, integraciones, capacitación y soporte. El “más barato” en cuota mensual puede ser el más caro en el año 1.

¿Cuánto tarda realmente?

Tamaño	Discovery	Diseño + Build	Piloto + Cutover	Total realista
Hasta 25 extensiones	1 semana	1-2 semanas	1 semana	3-4 semanas
25-100 extensiones	2 semanas	2-3 semanas	2 semanas	6-8 semanas
100-500 extensiones	2-3 semanas	3-4 semanas	3-4 semanas	10-12 semanas
500+ extensiones / multi-sucursal	3-4 semanas	4-8 semanas	4-8 semanas	3-5 meses

Si alguien te promete migrar 200 extensiones en 2 semanas, está vendiendo humo o está omitiendo el discovery y el piloto. Va a salir mal.

Checklist final pre-go-live

• Inventario completo de extensiones, troncales y endpoints.
• Tráfico real medido (BHCA, simultaneidad pico).
• Modelo de despliegue definido y aprobado.
• Internet validado: ancho de banda + jitter + latencia + pérdida.
• QoS configurada en routers/switches.
• Portabilidad de DIDs solicitada con plazo confirmado.
• Configuración funcional documentada y aprobada.
• Piloto ejecutado y aprobado por usuarios líderes.
• Capacitación completada con materiales entregados.
• Plan de rollback definido por si algo falla en cutover.
• Contactos de soporte L2/L3 en mano del responsable IT.
• Comunicación interna del cutover enviada con anticipación.

Cómo lo trabajamos en Globaltech

Operamos centrales virtuales sobre VitalPBX para empresas de todos los tamaños, desde PyMEs con 15 extensiones hasta operaciones multi-sucursal con cientos. Aplicamos el cronograma de arriba sin saltos: discovery, diseño, piloto, cutover y hypercare. Sin sorpresas en factura y con la migración bancada por SLA.

Si estás evaluando migrar tu central, podemos hacerte un discovery técnico sin compromiso: relevamos tu setup actual, dimensionamos correctamente y te entregamos una propuesta basada en datos reales, no en plantillas. Si decidís no avanzar, te queda igual el diagnóstico para usarlo con quien quieras.

---

Conocé Central Telefónica Virtual de Globaltech →