¿Migrar, refactorizar o reconstruir una aplicación legacy? Un marco de decisión para directivos IT

Que las aplicaciones y herramientas digitales que utilizas cada día no son eternas, ya lo sabes de sobra. Cada cierto tiempo, y cada vez con más frecuencia, necesitan actualizaciones que mejoran aspectos de seguridad de los datos, o se optimizan para las también actualizaciones de los sistemas operativos, ponen parches, añaden funciones… y así vas tirando durante el mayor tiempo posible para rentabilizar al máximo la inversión.  Y, más allá del puro coste económico, también es importante el tiempo de aprendizaje de la nueva herramienta, o la configuración y personalización, vencer la resistencia al cambio… muchas son las razones por las que la máxima de “si funciona, no lo toques” suele ser la más tenida en cuenta por muchas empresas. Y tienen razón. 

Pero, llega un momento en que esas aplicaciones o sistemas ya no dan para más, han quedado obsoletas para tu día a día o, aquí no hay opción, el desarrollador la retira del mercado y la deja sin soporte. Es el momento de dar el salto y migrar. El problema es cómo hacerlo sin roturas de producción y sin costes ocultos sobrevenidos con la nueva solución.

Es un miedo justificado, porque muchas de esas aplicaciones que usas cada día son estratégicas y fundamentales para tus operaciones y modernizar un software puede dar lugar a incidentes graves como parones en la cadena de producción o fallos en la facturación. Hoy, que casi todos los procesos están digitalizados, los sistemas son una infraestructura crítica de casi cualquier modelo de negocio u organización. Paralizar un programa de facturación o de logística de almacén puede conllevar costes económicos o reputacionales difíciles de salvar. Así que, como en tantas decisiones importantes para tu producción, migrar de plataforma o de aplicación debe hacerse como un salto con red, y asumir los menores riesgos posibles. En ese sentido, conservar todo lo que se pueda de lo actual, respetando el legacy, es una buena estrategia.

Conservar, arreglar o empezar de cero

Cuando los sistemas empiezan a quedarse anticuados y dar señales de que necesitan actualizarse profundamente, muchos desarrolladores toman la decisión drástica de empezar de cero cambiando de arriba abajo todo el código, que consideran inservible.

Lo mismo ocurre cuando se contrata a un desarrollador nuevo que no es quién creó ese código. Se pone a escarbar y no entiende muchas de las cosas que allí encuentra, o descubre tantos parches que es casi imposible reconocer la fuente original. Otros, simplemente lo usan como excusa para inflar el presupuesto, que de todo hay.

Pero frente a esa reacción instintiva, y que es cierto que a veces es la más recomendable o la única, hay studios de especialistas que coinciden en que cerca del 70% de las reescrituras completas desde cero (Big Bang rewrites) fracasan, se cancelan o sufren desviaciones masivas en costes y plazos.

Ya dijimos que no era una decisión fácil ni exenta de riesgos. Por eso, lo más importante es saber exactamente qué es lo que falla en tu sistema actual, qué necesidades no está cubriendo y dónde está su carencia. A partir de ahí, decidir qué hacer con la aplicación Legacy actual, si mantenerla, rediseñarla o cambiarla por otra nueva. Vamos a ver algunas pautas de cómo elegir entre esos tres caminos.

¿Qué hacer con la aplicación legacy?  Tres caminos para la migración

Vamos al grano. Existen numerosas propuestas de análisis de la idoneidad de la migración defendidos pos grandes empresas como AWS o consultoras como Gartner. A veces, esas guías son más una complicación que un mapa claro. Nosotros hemos reducido la hoja de ruta a tres pasos: Migrar, Refactorizar y Reconstruir.

A. Migrar

Sería cuando necesitas mover una aplicación actual a una nueva plataforma, por ejemplo, otro proveedor cloud, o un nuevo servidor. Este proceso, que técnicamente se denomina Rehost o Replatform, debería ser sencillo y requerir ajustes mínimos, o ninguno, en el código fuente de esa aplicación.

• Cuándo responde bien: Cuando el problema principal no es tu aplicación sino la infraestructura, como la escalabilidad del hardware o costes de alojamiento, pero tu   aplicación sigue funcionando bien.
• El límite: Si el problema no es solo de la plataforma sobre la que corre tu aplicación, o si el código ha quedado obsoleto para la nueva plataforma, no será suficiente con moverla de un sitio a otro.

B. Refactorizar 

Podemos considerarlo casi como una tarea de mantenimiento. Una puesta al día más o menos profunda que modifica la estructura interna de la aplicación y su arquitectura pero no altera su funcinamiento ni interrumpe el servicio. A esto se llama Re-architect o Incremental Modernization.

Una explicación de una de las estrategias más comunes es el conocido como Strangler Fig Pattern o Patrón de la Higuera Estranguladora. Este concepto lo introdujo Martin Fowler inspirado en una planta que crece alrededor de un árbol huésped hasta sustituirlo gradualmente. Por ejemplo, aplicado a tus sistemas, colocar un proxy o API Gateway en el perímetro del sistema antiguo. A partir de ahí, las nuevas funcionalidades o módulos refactorizados se desarrollan como servicios independientes, desviando el tráfico paulatinamente del código legacy al nuevo hasta que el monolito original puede apagarse sin impacto.

• Cuándo responde bien: Cuando la experiencia acumulada, las actaulizaciones ya realizadas,  y su rendimiento en el modelo de negocio actual es valiosa y compleja, pero el sistema necesita modernizar sus tripas, mejorar el rendimiento o integrar componentes nuevos que antes no había como Inteligencia Artificial.
• El beneficio: Al ser retoques sobre lo que ya funciona y conoces, reduce drásticamente el riesgo de parones operativos, permite validar el código en paralelo a la producción cada módulo y, en definitiva, mantiene el negocio en marcha.

C. Reconstruir

Aquí, el término en inglés es mucho más explícito: Rebuild o Full Rewrite. Cuando no hay nada que aprovechar o hacerlo no garantiza que resuelva los problemas que han surgido con el código legacy, lo más práctico es escribir el código desde cero y desarrollar un producto totalmente nuevo, desechando el anterior.

• Cuándo responde bien: Cuando tu sotware está absolutamente obsoleto o descatalogado, el lenguaje de programación ya no tiene soporte en la industria, o el modelo de negocio ha cambiado tanto que el sistema original resulta inservible.
• El riesgo: Como es la solución más drástica y profunda, no está exenta de riesgos. El más común es lo que llamamos La Trampa de la Paridad. Consiste en que mientras el equipo trabaja en el sistema nuevo (que puede tardar entre 12 y 24 meses), el sistema antiguo sigue vivo y acumulando cambios y el nuevo desarrollo trata de alcanzar la "paridad de funcionalidades" (feature parity), provocando frustración, cuando no agotamiento del presupuesto. Es decir, o se realiza de forma ágil o se duplica el trabajo y el tiempo de migración.

Si ya has decidido migrar tu sistema, estas son las precauciones básicas que debes tomar

Si crees que la decisión aún puede esperar, entonces probablemente sea así y puedas estudiarlo todo con calma con ayuda de algún experto que analice tu situación real y te indique el mejor camino a seguir. Pero, si tu continuidad operativa está en jaque y sabes que no puedes seguir como hasta ahora, podemos darte tres consejos a modo de salvavidas:

1. Utiliza Sandboxes o Gemelos Digitales. Este tipo de soluciones te permiten poner a prueba los nuevos desarrollos en condiciones de uso real antes de que sea demasiado tarde. No cambies tu aplicación a ver qué pasa, sino prueba lo que puede pasar antes de cambiarla.
2. Estudia Estándares Abiertos. Anticípate a la próxima vez que necesites migrar o actualizar intentando elegir desarrollos que te garanticen que vas a conservar la gobernanza, el acceso a los códigos y datos, y su licencia de uso sin restricciones legales o quedando atado a tu proveedor (Vendor Lock).
3. Valora contratar In-Sorcing. Si necesitas ayuda externa existe la opción de que contratar equipos que se integran en tu organización como uno más y que comparten su conocimiento, dejando la propiedad del código y sus secretos en tus manos. Y puede ser una oportunidad de oro para transferir conocimiento senior a tu equipo.

Hay muchas más cuestiones a tener en cuenta, pero aquí se trata de resolver las dudas principales. En nuestro día a día hemos visto todo tipo de casos particulares y por eso nos gusta vernos como un médico internista que analiza el organismo de una organización en su conjunto y no solo como el especialista en determinadas tecnologías. Identificar cuál es el dolor, de dónde procede, y ver dónde hay que poner el remedio. Si compartes esa visión, habla con nosotros.