Migrar legacy no es un project de reescritura. Es una serie de pasos controlados donde viejo y nuevo coexisten temporalmente hasta que viejo se puede apagar.
Por qué "reescribir todo" casi nunca funciona
La reescritura total toma años. Mientras, el viejo sistema sigue acumulando cambios que necesitas replicar. Al final, gastas 10x el tiempo original y el resultado sigue siendo instable.
La mejor estrategia es incremental: migra una pieza a la vez mientras mantienes el sistema funcionando.
- Evita reescrituras de 12 meses.
- Migra una feature a la vez.
- Mantén ambos sistemas en paralelo temporalmente.
Primero, entiende qué tienes
Antes de migrar, mapea el legacy: qué features hay, cómo fluye datos, qué dependencias criticas existen. Sin ese mapa, el riesgo de romper algo importante es alto.
Eso toma tiempo, pero es la inversión que previene desastres después.
- Audita el código legacy.
- Documenta features y dependencias.
- Identifica lo crítico vs lo que puede cambiar.
Estrategia de migración por capas
Backend antes que frontend. Datos antes que UI. Lo que menos toca usuarios primero. Eso reduce riesgo porque si algo falla, pocas personas lo ven.
Dentro de cada capa, pequeños pasos: una tabla, un endpoint, un componente a la vez.
- Migra datos primero.
- Luego APIs y lógica.
- Finalmente frontend.
Testing es tu seguridad
Sin tests del legacy, no tienes cómo validar que la migración mantiene comportamiento. Es demasiado riesgo. Escribe tests del comportamiento crítico del legacy antes de migrar.
Esos tests se ejecutan después de la migración para comprobar que nada rompió.
Una migración sin tests es como conducir en niebla. Estás haciendo cambios grandes sin saber si algo rompió.
Punto de corte y rollback
En algún punto, debes "cambiar el switch" y apuntar usuarios al nuevo sistema. Eso debe ser ensayado, reversible en cuestión de minutos si algo falla.
Rollback es tan importante como el cambio mismo. Ten plan claro para volver a viejo en emergencia.