Migración de un panel SMS: de SaaS a autoalojado, paso a paso

Dejar un panel SMS alquilado es un proyecto con una forma conocida. Las partes que fallan son siempre las mismas: una identidad de remitente (sender ID) registrada a nombre del fabricante, un nombre de host de la API que sus clientes dejaron fijado en el código, un libro mayor que no se exporta, un traspaso hecho en viernes. Esta es la lista de verificación para la migración de un panel SMS que usamos cuando pasamos a un revendedor a su propia plataforma, redactada para que pueda aplicarla con cualquier plataforma autoalojada. Cubre el paso de un panel SaaS a una plataforma autoalojada en siete etapas: el inventario, las exportaciones, la plataforma nueva, lo que no viaja, la convivencia, el traspaso y el cierre del panel antiguo. La comparativa de paneles SaaS trata de si conviene marcharse; esta guía trata de cómo hacerlo.

Etapa 0: fije el calendario según la tarea más lenta

Antes de tocar los datos, haga una lista de todo lo que depende del reloj de otros: los nuevos registros de identidades de remitente y de códigos cortos a nombre de su propia sociedad, las identidades regulatorias (DLT en la India, 10DLC en Estados Unidos y sus equivalentes), las aprobaciones de los operadores para sus propios binds SMPP y, si añade WhatsApp, la verificación empresarial de Meta. Cada una lleva semanas, no días, y ninguna se puede empezar demasiado pronto. Empiécelas todas en la primera semana, en paralelo con todo lo que sigue, y el resto de la migración terminará esperándolas a ellas, y no al revés.

Etapa 1: el inventario para la migración del panel SMS

Anote, a partir de la consola de administración del panel, una línea por elemento:

• Clientes: cada cuenta, su modo de facturación (crédito prepago, monedero, pospago), su saldo actual, su plan de tarifas, su persona de contacto y si se integra por la consola, por API HTTP o por bind SMPP.
• Planes de tarifas y rutas: cada plan de precios, cada fila de destino, cada ruta de proveedor con sus credenciales y su coste.
• Identidades de remitente y números: identidades alfanuméricas, números largos, códigos cortos, y a nombre de qué sociedad está registrado cada uno ante cada operador.
• Integraciones: cada nombre de host al que llaman sus clientes (la API, la URL del panel, los endpoints de webhook en los que reciben los acuses) y si está en su dominio o en el del fabricante.
• Volúmenes de datos: contactos, plantillas, histórico de campañas, registros de entrega y facturas, por mes.
• Contratos: el plazo de preaviso del panel y cada contrato de cliente que mencione el nombre o la URL del panel.

Este inventario es el plan de migración. Todo lo que sigue es ese mismo inventario con fechas.

Etapa 2: consiga exportaciones reales mientras todavía es cliente

Pida las exportaciones ahora, antes de dar el preaviso, porque la respuesta es más amable mientras usted paga. Pida cada elemento del inventario en un formato legible por máquina (CSV sirve) y abra cada archivo: compare el número de filas con la consola, compruebe que los registros de consentimiento viajan con los contactos y compruebe que los registros de entrega llevan el ID del mensaje y el estado final, y no solo un recuento. “Admitimos exportación en CSV” y “el archivo contiene lo que mis clientes necesitarían” son frases distintas.

Cuente con que el libro mayor sea lo menos portable de todo el edificio: los saldos y el histórico de facturas a menudo se exportan como PDF, o no se exportan en absoluto. En ese caso, reconstruya los saldos a partir de sus propios registros (las facturas que emitió, los pagos que recibió, la pantalla de saldo actual del panel en una captura fechada) y acuerde por escrito el saldo inicial con cada cliente en el traspaso. Es un correo de una línea por cliente, y evita todas las disputas que tendría de otro modo.

Etapa 3: levante la plataforma nueva en su propio dominio

Instale la plataforma en su propio servidor, en su propio dominio, antes de que se mueva ningún cliente. Dos reglas de la guía comparativa se aplican desde este día: el panel y la API viven en nombres de host que son suyos (panel.suempresa.com, api.suempresa.com), y las identidades de remitente y las identidades regulatorias se registran a nombre de su sociedad allí donde el regulador lo permita. Después:

1. Conecte sus propios contratos de operador como rutas de proveedor, y pruebe cada una con terminales reales en cada destino antes de que la toque ningún tráfico de cliente.
2. Reconstruya los planes de tarifas a partir de la exportación, por destino y por nivel de cliente, y ponga un suelo de margen bajo cada fila (la guía de facturación explica los tres modos de facturación y por qué el modo se elige al crear la cuenta y queda fijado después, así que decídalo ahora).
3. Cree las cuentas de cliente con el modo de facturación, el plan de tarifas, las identidades de remitente y los contactos correctos, pero con el envío desactivado y los saldos a cero hasta el traspaso.
4. Importe los contactos, los registros de consentimiento y las plantillas. Un consejo de negocio que damos a cada comprador: importe los registros de opt-in junto con los contactos, para cumplir la normativa desde el primer día en lugar de reconstruir el consentimiento más adelante.
5. Importe el histórico si puede. Vale la pena trasladar el histórico de campañas y los registros de entrega para que los clientes conserven sus informes; en Smppcube esa es la diferencia entre la Importación estándar (contactos, plantillas y configuración de remitentes y rutas) y la Migración completa (todo lo anterior más el histórico de envíos, las campañas y los registros de facturación) que figuran en la página de precios.
6. Configure el servidor SMPP para los clientes que se conectan por bind, con credenciales por cuenta, límites de rendimiento y listas de IP permitidas listos para entregar; en Smppcube, el servidor SMPP y la API HTTP forman parte de la plataforma, no son un complemento.

Etapa 4: lo que no viaja

Cuatro cosas necesitan su propio plan, porque ninguna exportación las incluye.

El nombre de host de la API. Si sus clientes llaman a api.fabricante.com, su código tiene que cambiar o algo tiene que responder con la misma interfaz. La mejor opción es una capa de compatibilidad en su plataforma que acepte la forma de las peticiones antiguas y la traduzca a la API nueva, de modo que la integración de un cliente siga funcionando el día en que se mueve su tráfico; después, el cliente puede pasar a su API nativa a su propio ritmo. Si el nombre de host antiguo es del fabricante, no puede llevárselo, así que la capa de compatibilidad vive en su nombre de host y cada cliente cambia una sola línea: el host.

Webhooks. Los clientes que reciben los acuses de entrega por webhook lo tienen configurado en el panel antiguo. Recoja ahora la URL de recepción de acuses de cada cliente y configúrela en la plataforma nueva antes del traspaso, para que el primer mensaje que envíen a través de usted produzca un acuse donde lo esperan.

Identidades de remitente, códigos cortos, identidades regulatorias. Vuelva a registrarlas a nombre de su sociedad, por operador y por país. Donde el fabricante las tenga a su nombre y no las libere, la identidad de remitente del cliente puede cambiar, y esa es una conversación que conviene tener pronto y con honestidad, con la fecha a partir de la cual sus mensajes llevarán la nueva.

Binds SMPP. Cada cliente que se conecta por bind necesita un host, un puerto, un system_id, una contraseña, unas IP permitidas y un límite de rendimiento nuevos, y una ventana de pruebas en su ruta de prueba antes de que se mueva su tráfico real. Envíe el paquete de credenciales en un solo documento y programe una prueba de 30 minutos con su ingeniero.

La migración falla por lo que nadie exportó, no por lo que todos exportaron. Los nombres de host, los webhooks, las identidades de remitente y los binds son el plan; los archivos CSV son la parte fácil.

Etapa 5: la convivencia

Mantenga el panel antiguo activo y pagado de 60 a 90 días después de que la plataforma nueva esté lista. Mueva primero a un cliente amable y de poco volumen, a ser posible uno que le diga la verdad. Su tráfico circula por su plataforma, sus rutas y su libro mayor; el panel antiguo queda como red de seguridad. Concilie a diario los mensajes enviados, los acuses emparejados y los movimientos de saldo con lo que ve el cliente. Cuando pase una semana sin nada que explicar, mueva al siguiente cliente, y luego al siguiente. Mueva a su cliente más grande el último, cuando los pequeños ya hayan destapado todos los problemas aburridos.

Durante la convivencia, tres comprobaciones van en la lista diaria: la latencia de los acuses por ruta (un bind con un operador que es más lento en su plataforma que en el panel suele deberse a un ajuste de ventana o de limitación de caudal), el margen por cliente frente al precio combinado del panel antiguo (aquí es donde ve desaparecer el impuesto sobre el margen) y las incidencias de soporte por categoría (un aumento de consultas del tipo “dónde está mi acuse” apunta a un webhook, no a una ruta).

Etapa 6: el traspaso, cliente a cliente

Para cada cliente, el traspaso es una lista de verificación con fecha: saldo acordado por escrito, identidades de remitente activas a nombre de su sociedad, integración probada (capa de compatibilidad de la API o credenciales nuevas, webhook recibiendo acuses, bind SMPP probado en la ruta de prueba), envío activado, primera campaña seguida de principio a fin y cuenta del panel antiguo en modo de solo recepción o desactivada. Hágalo un martes por la mañana, con el contacto del cliente localizable, y nunca un viernes.

La comunicación es la mayor parte del trabajo. Una nota breve a cada cliente con un mes de antelación (“pasamos a nuestra propia plataforma; esto es lo que cambia para usted y esto es lo que no cambia”), un recordatorio una semana antes con su fecha concreta y una confirmación el mismo día. Los clientes se van por las sorpresas, no por los cambios.

Etapa 7: cierre el panel antiguo como es debido

Cuando el último cliente se haya trasladado y la convivencia lleve un mes sin incidencias, haga una exportación final de todo y guárdela en su archivo con la fecha, revoque cada clave de API e integración que tuviera el panel, retire las IP del panel de las listas de IP permitidas de sus operadores, dé el preaviso según el contrato y obtenga confirmación por escrito de que sus datos se han borrado de los sistemas del fabricante. Después, cierre la cuenta. Aquí termina el doble pago, y a partir de ahora, cada mes, la cuota de plataforma que crecía con su tráfico es margen en su propio libro mayor.

Lo que cuesta y lo que vale

Presupueste la migración con honestidad: de dos a seis semanas de calendario, la mayor parte esperando a los operadores, más de 60 a 90 días pagando dos veces, más lo que cobre la plataforma nueva por la importación. A los volúmenes en los que marcharse tiene sentido, ese total es menor que uno o dos meses de la tarifa de plataforma por mensaje que deja atrás y, a diferencia de esa tarifa, se paga una sola vez. En Smppcube, la migración de usuarios, rutas, tarifas y saldos es una parte estándar y acotada del despliegue, y las opciones de Importación estándar y Migración completa tienen su precio publicado en la página de precios, en lugar de presupuestarse por sorpresa. Sea cual sea la plataforma que elija, las reglas que abaratan la salida son las mismas dos que debería haber aplicado el primer día: su dominio y sus registros.