Tu negocio corre sobre una plataforma que funciona. Tiene clientes, ventas, inventario, un portal. Hasta ahí, bien. El problema es dónde vive: un proveedor la genera, la aloja y guarda la base de datos, y tú no tienes forma de sacarla de ahí. No hay ambiente de pruebas. No sabes qué se despliega ni cuándo. Si el proveedor cambia de precio o cierra, la operación se detiene ese mismo día.
Así llegó un club de bienestar en Ecuador con el que trabajamos. Este es el recorrido, sin nombres y sin cifras de negocio.
El punto de partida
El club vendía membresías, protocolos de seguimiento y productos. Su plataforma cubría bastante: fichas de clientes, ventas y cobros pendientes, cotizaciones con PDF, inventario, protocolos, mediciones, reportes, un sitio público y un portal para miembros. Operaba a diario con usuarios reales.
Lo que faltaba era control. La aplicación había sido generada en una plataforma de un tercero que también la alojaba, y eso se traducía en cinco cosas:
- Un solo ambiente: cada cambio se probaba en producción.
- Pagos sin conectar: «pagado» era una casilla que alguien marcaba a mano.
- Ventas que llegaban por chat y se volvían a escribir en el sistema.
- Datos en una base de datos del proveedor, sin integridad entre tablas.
- Ninguna forma documentada de desplegar o reproducir el sistema.
El pedido del cliente cabía en dos frases. Sacar la plataforma de ahí sin perder usuarios ni datos, y no volver a depender de un proveedor para operar.
Primero congelar, después tocar
¿Por qué no empezar a escribir el sistema nuevo desde el primer día? Porque nadie sabía con precisión cómo se comportaba el viejo. Migrar sin esa red es migrar a ciegas, y las diferencias aparecen cuando ya hay usuarios adentro.
Corrimos la aplicación heredada en un ambiente local y escribimos pruebas que capturan lo que hace hoy: para cada operación, qué entra y qué sale, con las validaciones y los errores que devolvía. A eso le sumamos un recorrido automatizado de la interfaz. Esa suite se volvió el contrato. El sistema nuevo estaría terminado cuando pasara exactamente las mismas pruebas.
Regla durante toda la migración: ningún error del sistema viejo se corrige. Se anota con su severidad y se deja para después.
Suena a dejar problemas sueltos a propósito. En parte lo es. Encontramos una lista de hallazgos, algunos serios, y los dejamos ahí. Si mezclas correcciones con la migración, después no puedes distinguir una regresión de un cambio intencional. Con el comportamiento congelado, cada diferencia entre viejo y nuevo tiene una sola explicación posible.
La auditoría también mostró algo que la descripción del sistema no decía: un módulo que se daba por construido no existía en el código que nos entregaron. Pasó de «migrar» a «construir desde cero», y las pruebas que lo cubrían quedaron marcadas como fallas esperadas para que nadie las confundiera con un problema del sistema nuevo.
Conservar lo que funciona, reconstruir lo que duele
No todo se rehizo. La interfaz que usaba el equipo del club funcionaba y ellos ya la conocían. Rehacerla habría sido cobrar por algo que no dolía. Se conservó y se apuntó al sistema nuevo, respetando los mismos contratos de datos. Eso redujo el alcance de la primera versión a la mitad.
Lo que sí se reconstruyó fue el motor. Un bloque único de código pasó a ser un conjunto de módulos independientes, y la base de datos de documentos pasó a una base relacional que sí exige integridad entre clientes, ventas, inventario y protocolos.
| Componente | Decisión | Por qué |
|---|---|---|
| Interfaz de usuario | Se conserva y se reconecta | Funciona y el equipo la domina |
| Motor de la aplicación | Se reconstruye por módulos | Un solo bloque de código, difícil de probar y de extender |
| Base de datos | Se migra a relacional | Integridad entre tablas y transacciones seguras para dinero |
| Alojamiento | Ambientes separados, dimensionados al negocio | Pruebas fuera de producción y costo ajustado al tamaño del negocio |
El motor se construyó en rebanadas verticales: autenticación y clientes, catálogo e inventario, protocolos y mediciones, cotizaciones, ventas y deuda, reportes, portal de miembros. Cada rebanada se verificaba contra el contrato antes de empezar la siguiente.
Rechazamos un atajo: un conjunto de respuestas genéricas que hubiera dejado la interfaz «en verde» en un día. Claro que se veía bien. Pero una pantalla que funciona sobre datos falsos esconde los módulos que todavía no existen. Solo quedaron unas pocas rutas marcadas explícitamente como pendientes.
Sin depender del proveedor
La segunda frase del pedido se resolvió con una plataforma propia, que el club puede desplegar y reproducir sin pedirle nada a nadie. El despliegue quedó documentado, hay un ambiente de pruebas separado de producción y las claves viven en un gestor de secretos, fuera del código. Con el proveedor anterior nada de eso existía: cada cambio se probaba con usuarios reales y nadie sabía cómo levantar el sistema en otro lugar.
La infraestructura se eligió para un negocio pequeño: un servicio para el motor que escala según el uso, una base de datos administrada y la interfaz servida desde una red de distribución, todo en la misma región para que la latencia entre partes sea mínima. Nada sobredimensionado, porque la cuenta mensual tiene que parecerse al tamaño del negocio.
Qué quedó
Los resultados que podemos afirmar son técnicos, porque son los que están documentados.
- La suite de paridad quedó completa en verde, salvo los casos del módulo que nunca existió, marcados como esperados.
- La plataforma quedó operando fuera del proveedor, en ambientes propios y separados, con sus datos reales cargados por un proceso repetible, en cuestión de semanas desde la propuesta.
- Sobre esa base se agregaron después un portal de miembros más completo, una tienda pública con pago con tarjeta a través de una pasarela local (donde el servidor, nunca el navegador, decide si un pago se confirmó) y un ciclo comercial con invitaciones y atribución de origen.
Lo que se puede desviar no se guarda: se calcula. El stock restante, el estado de un miembro o la vigencia de una invitación se derivan de hechos que no cambian.
Lo que no vamos a afirmar son cifras de ventas o de tiempo ahorrado, porque no las medimos. Si tu plataforma vive en un lugar que no controlas, el primer paso es saber, con pruebas, cómo se comporta la de hoy. La cotización viene después. En la guía sobre modernizar un sistema legacy por etapas está el método completo, y en nuestras capacidades lo que podemos tomar de tu caso.
Preguntas frecuentes.
¿Cuánto tarda sacar una plataforma de un proveedor?
Depende del tamaño del sistema y de cuánto de él conviene conservar. En este caso la primera versión funcionando fuera del proveedor, con datos reales, tomó semanas. Lo que más acelera es tener el comportamiento actual documentado con pruebas desde el inicio.
¿Se pierden datos al migrar de una base de datos a otra?
No deberían perderse si la migración tiene un contrato. Aquí las pruebas de paridad comparaban respuesta por respuesta el sistema viejo con el nuevo, y la carga de datos reales se hizo con un proceso repetible que se podía correr las veces necesarias.
¿Tengo que rehacer también la parte visual?
No siempre. Si la interfaz funciona y a tu equipo le sirve, se conserva y se conecta al nuevo sistema respetando los mismos contratos. Rehacerla es una decisión aparte, con su propio momento.
¿Se puede hacer sin frenar la operación?
Sí. El sistema viejo siguió atendiendo a sus usuarios mientras el nuevo se construía por módulos sobre una copia, y los datos reales se cargaron con un proceso que se podía repetir. El cambio ocurrió una sola vez, cuando la suite de paridad pasó completa.