Migraciones legacy: vas a fallar (y eso no es malo)
Reconstruir una plataforma legacy desde cero es realmente divertido. A veces necesitas replicar mucha lógica de negocio colocada en algún lugar dentro de un monolito realmente grande lleno de hacks ilegibles, funciones masivas o carente de cualquier tipo de tests. A veces incluso comparte responsabilidades con procedimientos almacenados en diferentes bases de datos con acceso restringido, o nadie es capaz de contarte una sola cosa sobre ellos.
Bajo estas circunstancias, déjame contarte un pequeño secreto: vas a fallar. No hay forma de que un equipo sea capaz de entender toda esa complejidad, así como reconstruir todo el conjunto en un tiempo sensato. Por tanto, tienes dos opciones:
- Enfocarte en construir el sistema perfecto que nunca falla
- Enfocarte en construir un sistema que falla perfectamente
Yo naturalmente prefiero ir por la opción número 2. Trabajar con reconstrucciones de sistemas legacy te hace confiar en muy pocas cosas, ya que tantas cosas pueden salir mal. Así que reemplazar un sistema legacy tiene que ver con gestionar el riesgo—aquí van algunos consejos:
Gestionando tus datos y resiliencia en migraciones
Uno de los primeros desafíos cuando reemplazas sistemas legacy es lidiar con los datos y la resiliencia. Sin una estrategia adecuada, cualquier fallo puede tener consecuencias duraderas.
Haz backup de tus datos
No solo estoy hablando de hacer backup de tus bases de datos aquí. Especialmente si eres la fuente de la verdad, asegúrate de hacer backup de tus datos en diferentes almacenamientos baratos como Azure Blob Storage o Amazon S3. No solo en caso de fallo del servidor, sino también en caso de que tu modelo de datos se corrompa en el camino.
Usa un data bus para resiliencia
Introducir un data bus añade una red de seguridad esencial. Entre sus principales ventajas:
- Ayuda a desacoplar tus servicios
- Descarga peticiones
- Mejora y facilita la recuperación y reintentos
- Hace que el manejo de errores sea más fácil
- Ayuda a evitar cuellos de botella
Asegurando control y visibilidad
Reconstruir un sistema sin visibilidad es como volar a ciegas. Necesitas mecanismos para mantener el control y asegurar la estabilidad.
Reproduce tus eventos
Como dije, lo vas a hacer mal. Si tus datos de entrada vienen de personas operando otros sistemas como un CRM externo o CMS, no querrás pedirles que vuelvan a guardar 1000 ítems para ti, tres veces al día solo porque tu equipo necesita reprocesar datos de la semana pasada. Guárdalos en tu plataforma y construye la capacidad de reproducir estos datos para tener más control internamente.
Construye una cabina de mando
¿Saltarías a un avión que se pilota sin ningún tipo de feedback del entorno? Asegúrate de construir una cabina de mando operacional para poder pilotar tu software con garantías: monitores mostrando métricas operacionales, alertas proactivas y un buen sistema de logging son algunos de los aspectos que necesitarás considerar en cada plataforma que construyas.
Manteniendo al equipo responsable y alineado
Más allá de la tecnología, las migraciones tienen éxito cuando el equipo está cerca del problema y es responsable de los resultados.
Para entender cómo conceptos como agile, delivery y DevOps juegan juntos, probablemente necesitamos entender primero cuál es el valor de un equipo de software. Su valor principal es resolver problemas reales de negocio, a menudo hecho mediante la entrega de software funcionando en un entorno de producción en ejecución frecuentemente y de manera sostenible.
Para lograr esto, los desarrolladores necesitan mantenerse muy cerca del problema:
- Hablar directamente con los stakeholders para evitar malentendidos.
- Trabajar colaborativamente con el product owner para asegurar que las prioridades estén alineadas.
- Operar, liberar, hacer rollback y monitorizar el software que construyen, tomando propiedad del ciclo de vida.
Esto incrementa la responsabilidad y reduce las cargas de comunicación (que usualmente traen retrasos).
Preparándose para dependencias externas y cuellos de botella
No importa cuán sólida sea tu plataforma, terceras partes y restricciones de rendimiento pueden socavarla. Prepararse para estos riesgos es esencial.
No confíes en terceros. Nunca.
«Este viejo sistema nunca falló en 10 años». Esto es lo que escuché de un cliente cuando empezamos una reconstrucción de su plataforma legacy. Bueno, ¿adivina qué? Sí falló.
Asegúrate siempre de evaluar los sistemas antiguos de los que dependerás, y ten en cuenta restricciones técnicas como límites de velocidad, tamaños de payload…
También considera cómo procesar datos cuando estos sistemas fallen, porque pueden hacerlo: podría ser un token revocado sin comunicación previa, podría ser un error 500, podría ser una fuga de memoria, o podría ser un contrato de API que ya no se respeta. Planifica para el fallo.
Descubre dónde están tus cuellos de botella
Cuando estés construyendo una nueva plataforma (especialmente si necesita integrarse con terceros), ejecuta siempre tests de rendimiento involucrando a estos sistemas externos antes de salir a producción. ¿En qué áreas sufrirá tu plataforma cuando escale la capacidad? Enfócate en hacer esa área más fuerte, o te morderá tarde o temprano.
En una de las migraciones legacy que implementamos recientemente, notamos que el sistema antiguo tardaría 6 segundos en digerir datos. Porque ejecutamos tests de rendimiento a tiempo, pudimos cambiar el diseño de arquitectura, descargando ese proceso para que sucediera en segundo plano de modo que los usuarios no se vieran afectados por esta restricción legacy.
Conclusión: planificando para el fallo, construyendo para la resiliencia
¡Espero que estos consejos te sean valiosos! ¿Qué otros aprendizajes de tu experiencia puedes añadir?
Las migraciones legacy siempre implicarán incertidumbre. El objetivo no es evitar el fallo sino planificar para él—a través de backups, resiliencia, visibilidad, responsabilidad y previsión.
En Orbitant, sabemos que las migraciones no son solo desafíos técnicos: son oportunidades para fortalecer sistemas mientras se protege la continuidad del negocio. Por eso ayudamos a las organizaciones a diseñar arquitecturas que son fiables, adaptables y resilientes, convirtiendo los fallos inevitables en momentos de aprendizaje y mejora.