Modernizar sin reescribir: cómo separamos un módulo de un monolito

“Hay que reescribirlo” es probablemente la frase más cara en la vida de un sistema. Suena a solución y casi siempre es el comienzo de un proyecto que tarda el doble, convive años con el sistema viejo y termina replicando sus errores.

La alternativa es separar por partes, con el sistema original funcionando. Este es el método que seguimos, con ejemplos de cuando sacamos la gestión de usuarios de nuestro propio monolito —el origen de Ailita—.

1. Encontrar el límite real, no el del diagrama

El diagrama de arquitectura dice dónde termina un módulo. El código dice otra cosa. Empezamos por listar lo que el módulo usa del resto del sistema y lo que el resto usa de él: clases compartidas, tablas que se consultan desde otros lados, utilidades comunes, configuración.

En nuestro caso, la identidad compartía más piezas con el resto del sistema de lo que parecía. Decidimos llevarlas con ella, aunque eso significara repetir un poco de trabajo. Duplicar un poco es más barato que atar dos sistemas nuevos entre sí.

2. Fijar el comportamiento antes de moverlo

Antes de cambiar código que funciona, escribimos pruebas que describen lo que hace hoy, incluso lo que hace mal. Se llaman pruebas de caracterización: no validan que el comportamiento sea correcto, validan que no cambie sin querer.

Son la red que permite mover cosas con confianza. Cuando una falla, la pregunta no es “¿qué rompimos?” sino “¿este cambio de comportamiento era intencional?”.

3. Poner una interfaz en el medio

La pieza que se separa pasa a tener una puerta de entrada clara. El sistema original deja de meterse en sus detalles y empieza a usar esa puerta: primero apuntando a su propio código, después a la pieza nueva. Ese cambio de destino es el paso más importante, y tiene que poder deshacerse en minutos.

4. Convivir un tiempo

Durante la migración, el sistema viejo y el nuevo funcionan a la vez. Los datos se mudan con verificaciones: que no falte nada, que todo coincida, muestras revisadas a mano. Si algo no coincide, se detiene y se entiende antes de seguir.

5. Apagar cuando ya no hay tráfico

El código viejo se elimina cuando las métricas muestran que nadie lo usa, no cuando el calendario dice que el proyecto terminó. Apagar antes es la forma más común de descubrir, en producción, una dependencia que nadie había listado.

Por qué lo hacemos así

• Valor en cada etapa. Cada paso deja algo funcionando, en lugar de un gran estreno al final.
• Riesgo acotado. Cada paso puede revertirse sin coordinar a medio equipo.
• Mejoras que no estaban en el plan. En nuestro caso, separar la identidad nos obligó a pensar el aislamiento por empresa y el login alojado desde cero, en lugar de heredar decisiones de otra época. Hoy ese servicio lo usa también Alfred.

Si tienes un sistema que sostiene el negocio y nadie quiere tocar, este es el tipo de trabajo que hacemos en modernización.