Tu sistema funciona. Lo usa la gente todos los días, tiene años de datos y nadie quiere tocarlo. Y hace bien en no querer. También tiene un techo: hay un módulo que no se puede agregar, un reporte que toma una tarde, un proveedor que guarda todo y un solo ambiente donde cada cambio se prueba con clientes reales.
Esta guía sale de tres migraciones distintas: la plataforma de un club de bienestar que vivía en un proveedor externo, el sistema de gestión de un hotel que corría en una herramienta sin código, y un blog con años sin mantenimiento que se convirtió en una plataforma de aprendizaje. Tres negocios que no se parecen en nada. Los tres siguieron el mismo esquema.
Cuándo migrar (y cuándo no)
«Es viejo» no es un motivo. Hay sistemas de diez años que cumplen y no conviene tocar; si el tuyo es uno de esos, ahórrate la migración. Las señales que sí la justifican son otras:
- El proveedor genera y aloja tu aplicación, y tus datos están en su base de datos. Si cierra o cambia de condiciones, tu operación se detiene.
- No existe un ambiente de pruebas. Cada cambio se prueba en producción, con usuarios reales.
- La plataforma llegó a su límite. En el caso del hotel, la herramienta sin código tenía decenas de tablas, cientos de vistas y robots automáticos haciendo transiciones de estado. Agregar el módulo de finanzas que el negocio necesitaba era imposible.
- El núcleo lleva años sin actualizarse y depende de complementos con riesgos de seguridad conocidos. El blog abandonado tenía un administrador de archivos y un editor de código instalados como complementos, y cuatro usuarios administradores para un solo autor.
- Los pagos, las ventas o las conciliaciones se hacen «a mano» fuera del sistema porque conectarlas no es posible.
Si reconoces dos o más, el sistema ya está frenando decisiones del negocio, y eso cuesta más que migrarlo. Con una sola, mantenlo y vuelve a esta lista en un año.
Qué conservar y qué reconstruir
El error más común es asumir que migrar es rehacer todo. Nada más lejos de la realidad. Lo valioso de un sistema viejo suele estar en lo menos visible: el modelo de datos y las reglas de negocio que años de uso validaron. Eso se queda. Lo que se va es el motor que ya no te deja crecer.
| Parte del sistema | Qué hacer | Por qué |
|---|---|---|
| Modelo de datos y reglas de negocio | Conservar, portar con fidelidad | Son el conocimiento del negocio; años de uso los validaron |
| Interfaz de usuario | Conservar si funciona | El equipo ya la conoce; reduce el alcance a la mitad |
| Motor de la aplicación | Reconstruir por módulos | Es donde está el techo: un bloque único o una plataforma cerrada |
| Alojamiento | Ambientes separados y dimensionados al negocio | Pruebas fuera de producción y costo ajustado |
| Contenido histórico | Conservar con un mapa explícito | Nada se borra sin saber a dónde va |
En el hotel, la documentación de la herramienta sin código resultó ser la mejor especificación posible: cada fórmula, cada máquina de estados y cada lista de valores se portó tal cual, con una referencia al original en el código. Cuando alguien propuso una simplificación «razonable» de una regla de confirmación, la comparación con el original mostró que era una desviación y se corrigió antes de integrarla. Parecía una mejora, y era un cambio de comportamiento que nadie había pedido.
Fidelidad antes que interpretación. Un sistema en uso durante años tiene razones que nadie recuerda; la migración no es el momento de descubrirlas a la fuerza.
Etapa cero: congela el comportamiento
Antes de escribir el sistema nuevo, escribe pruebas que describan cómo se comporta el actual. Para cada operación, qué entra y qué sale, incluidos los errores y las validaciones. Si hay interfaz, un recorrido automatizado por las pantallas principales. Sí, es trabajo que no se ve. También es lo que te dice cuándo terminaste.
Esa suite es el contrato. El sistema nuevo está terminado cuando la pasa completa. Y tiene una regla incómoda: los errores que encuentres en el sistema viejo se anotan con su severidad, pero no se corrigen. Cuesta resistirse, sobre todo cuando el error es evidente. Si mezclas correcciones con la migración, después no puedes distinguir una regresión de un cambio intencional. En el caso de la plataforma del club de bienestar se registró una lista de hallazgos, algunos críticos, y se dejaron para después del cambio.
La etapa cero también sirve para auditar lo que el sistema dice tener. Un módulo descrito como «construido y probado» resultó no existir en el código entregado. Descubrirlo antes de cotizar la migración evitó tratar como trabajo de portado lo que era trabajo nuevo.
Por etapas, no de golpe
Un cambio de golpe (todo el sistema nuevo un lunes) concentra el riesgo en un solo día y en una sola persona. ¿Por qué alguien lo haría así? Porque parece más rápido. Migrar por etapas reparte ese riesgo.
El esquema que usamos:
- Elige el orden de los módulos por dependencia: primero los que no dependen de nada (usuarios, catálogos), después los que dependen de esos (ventas, inventario), al final los que cruzan todo (reportes, portal).
- Reconstruye un módulo, verifícalo contra el contrato, intégralo. Solo entonces empieza el siguiente.
- Mantén el sistema viejo como referencia durante todo el proceso, en un ambiente propio, para comparar respuestas cuando algo no cuadre.
- Producción no se toca hasta la última etapa. El día del cambio ya no hay incógnitas técnicas; queda una ventana corta y una vuelta atrás preparada.
Cuando el sistema viejo es un gestor de contenidos, las etapas son de otro tipo: sobre una copia local, primero se actualizan los complementos, después el núcleo en saltos de versión, y al final el lenguaje del servidor. Cada salto expone fallas que se corrigen antes del siguiente. El blog abandonado pasó por ese proceso completo sin que la versión pública cambiara hasta el día del lanzamiento.
Regla de las tres capas: una copia para trabajar, el original como referencia, producción intacta hasta el final.
Los datos rompen todo lo demás
La parte que más sorprende a los equipos es la carga de datos reales. Un importador construido con datos de ejemplo funciona perfecto hasta que llega la hoja de cálculo verdadera: encabezados en la fila tres, fechas en un formato distinto, números con formato contable. Siempre pasa. Con el archivo del contador, más.
En el hotel, la primera carga real de los archivos del contador rechazó casi la mitad de las filas y dividió tres montos entre mil sin avisar. Se descubrió antes de producción porque la carga real se hizo temprano, con la intención de romper el importador. Mejor que se rompa en tu computadora que en la recepción del hotel.
Dos decisiones ayudan aquí:
- Lo que se puede desviar, se calcula, no se guarda. Un estado de conciliación que cinco procesos distintos escribían en el sistema viejo se convirtió en un valor derivado al momento de consultar, y cada importación pasó a ser repetible sin duplicados.
- Las reglas que el dueño cambia se guardan como datos, no como código. Categorías de habitaciones, métodos de pago, canales de venta: todo eso cambió durante las sesiones de revisión y se ajustó desde el panel sin volver a desplegar.
Cómo saber que terminó
La migración termina cuando el contrato de la etapa cero pasa completo, los datos reales están cargados por un proceso que se puede repetir, y el sistema corre en ambientes propios, con pruebas y producción separadas. Ahí se hace el cambio.
Lo que sigue ya no es migración: son mejoras con su propio alcance. Las correcciones pendientes de la lista de hallazgos, el módulo que nunca existió, la integración que se dejó para después. Conviene decirlo así, y decírselo al equipo, porque un sistema «en pruebas con datos reales» y un sistema «en uso diario» son etapas distintas. Confundirlas es la forma más rápida de perder la confianza de la gente que lo va a operar.
Si tu sistema muestra dos o más de las señales del inicio, el primer paso es congelar cómo se comporta hoy. Qué influye en el esfuerzo de una migración está en la guía sobre qué define el costo de un software a la medida, y lo que tomamos de cada caso, en nuestras capacidades.
Preguntas frecuentes.
¿Cuándo conviene migrar un sistema legacy en lugar de mantenerlo?
Cuando el sistema frena decisiones del negocio: no puedes agregar un módulo, cada cambio se prueba en producción, el proveedor guarda tus datos o el mantenimiento consume más que la operación. Si solo es viejo pero cumple, mantenerlo suele ser la mejor decisión.
¿Qué es una migración por etapas?
Reconstruir el sistema módulo por módulo, verificando cada uno contra el comportamiento del sistema actual, mientras el original sigue operando. El cambio a producción ocurre una sola vez, al final, cuando todo el contrato está cumplido.
¿Se puede migrar sin detener la operación?
Sí. Todo el trabajo ocurre sobre una copia del sistema y de sus datos. El original sigue en uso hasta el día del cambio, que se planifica con una ventana corta y una vuelta atrás preparada.
¿Qué pasa con los errores que ya tiene el sistema actual?
Se documentan y se reproducen en el nuevo, no se corrigen durante la migración. Así cualquier diferencia entre viejo y nuevo es una regresión que hay que revisar. Las correcciones vienen después, como mejoras con su propio alcance.
