En toda empresa chilena con más de quince años de historia hay un sistema que nadie quiere tocar: el ERP que se cayó tres veces el último año, el software de gestión inventado por un proveedor que ya no existe, la base de datos que corre en un servidor antiguo que sigue prendido por miedo a lo que pase si se apaga. Reemplazarlo parece urgente. Intentarlo mal es una de las formas más caras de quebrar la continuidad operativa.
Cuándo migrar, cuándo evolucionar
Antes de empezar un proyecto de migración, vale la pena distinguir entre dos situaciones que se confunden.
Migrar tiene sentido cuando el sistema actual limita la operación: no se puede integrar con nada, el proveedor dejó de darle soporte, los costos de mantenimiento suben cada año, o impide cumplir una regulación. En estos casos, quedarse tiene un costo que crece.
Evolucionar tiene sentido cuando el problema es de funcionalidad, no de plataforma. Si el sistema funciona pero le faltan features, a veces basta con módulos adicionales, integraciones o un frontend nuevo encima del backend existente. Reemplazar todo por algo moderno pero mal implementado suele ser peor que quedarse.
La señal más clara de que toca migrar es cuando el sistema se ha convertido en una excusa constante. Si cada nueva iniciativa depende de un parche sobre algo que ya nadie entiende, es hora de cambiar.
El error que se repite
El error más caro en migraciones de sistemas críticos es subestimar la complejidad de los datos y de los procesos que el sistema sostiene. Un ERP antiguo no es solo una base de datos: contiene reglas de negocio que nunca se documentaron, integraciones con sistemas satélites que nadie mapea, validaciones que el equipo operativo aprendió a aplicar "a mano" cuando el sistema no las hacía bien, y años de datos con formatos que ya nadie sabe leer.
Por eso las migraciones que empiezan con "vamos a reemplazar el ERP en seis meses" casi nunca cumplen el plazo ni el presupuesto. No porque el equipo sea malo, sino porque la fase de descubrimiento se hizo apurada.
Tres metodologías, tres perfiles de riesgo
Big bang
Reemplazo total en una fecha cortada. Toda la operación migra de un día para otro. Funciona solo cuando el sistema nuevo es una réplica 1:1 del anterior más algunas mejoras, y cuando el equipo está dispuesto a operar en paralelo durante semanas para validar. Es arriesgado en sistemas con datos históricos críticos o procesos no documentados.
Paralelo
Ambos sistemas conviven durante meses. El sistema antiguo sigue siendo la fuente de verdad, el nuevo se valida en sombra. La migración se hace funcional por funcional cuando el equipo operativo confía. Es más lento y más caro, pero baja el riesgo de forma importante. Es la elección correcta cuando la continuidad operacional no admite cortes.
Strangler fig
El sistema nuevo crece alrededor del antiguo. Funcionalidad por funcionalidad se va moviendo al sistema nuevo, hasta que el antiguo queda como una dependencia menor o se apaga. Requiere más arquitectura (un middleware que enrute), pero permite migrar en un horizonte de uno a dos años sin poner en riesgo la operación.
En sistemas críticos, strangler fig es la opción más segura. En sistemas menos complejos, el paralelo bien ejecutado también funciona. El big bang solo se justifica cuando el sistema es chico y la operación puede absorber semanas de ajuste.
Lo que casi nadie planifica bien
Tres frentes aparecen tarde si no se planifican desde el inicio:
- Migración de datos. No es solo copiar tablas. Hay que limpiar, normalizar, validar reglas de negocio y decidir qué se lleva y qué se archiva. Un equipo dedicado a esto durante semanas evita meses de problemas en producción.
- Capacitación del equipo operativo. Un sistema nuevo que el equipo no entiende se traduce en resistencia, errores y baja de productividad durante meses. La capacitación debe empezar antes del go-live, no después.
- Plan de rollback. Si algo sale mal, hay que poder volver al sistema anterior sin perder información. Esto significa mantener el sistema antiguo operativo durante al menos un ciclo completo después de la migración, y tener un procedimiento claro de reversa.
La diferencia entre un proyecto exitoso y uno problemático
Las migraciones de sistemas críticos no se ganan en la fase de desarrollo, se ganan en la fase de descubrimiento y planificación. Las empresas que migran bien invierten entre un 30% y 40% del proyecto en entender el sistema actual, mapear procesos, limpiar datos y diseñar la arquitectura de transición. Las que migran mal se lanzan a programar y descubren los problemas en producción.
En CodeHub acompañamos a empresas en migraciones de sistemas legacy, desde el descubrimiento y diseño de la arquitectura de transición hasta el go-live y la estabilización post migración.