Cuando un sistema crítico se vuelve difícil de cambiar, el instinto suele ser reescribirlo. Es un instinto comprensible, y también es donde muchos esfuerzos de modernización se descarrilan. Un camino más seguro es modernizar en pasos pequeños y reversibles mientras el sistema actual sigue funcionando. Este artículo explica la idea y cómo aplicarla.
Por qué las reescrituras totales son riesgosas
Martin Fowler, en su texto sobre el enfoque del "strangler fig", resume por qué los proyectos de reemplazo suelen fallar. Tardan mucho mientras los usuarios esperan nuevas funciones, los detalles del comportamiento actual son difíciles de descubrir y buena parte de ese comportamiento quizá no se quiere en la versión nueva. A nuestro juicio, una reescritura apuesta todo a un solo corte y el valor llega hasta el final.
La idea del strangler fig
El nombre viene de una enredadera que crece alrededor de un árbol y poco a poco lo reemplaza. En software, construyes funcionalidad nueva junto al sistema legacy y mueves el comportamiento pieza por pieza hasta que el sistema viejo ya no hace falta. Fowler describe cuatro actividades, tomadas del trabajo de Cartwright, Horn y Lewis: entender los resultados que se buscan, decidir cómo dividir el problema en partes, entregar esas partes con éxito y cambiar la organización para que esto pueda continuar.
Una secuencia práctica
- Alinea el resultado. Decide qué debe lograr la modernización: entregar más rápido, reducir riesgo operativo, mover a la nube, integrar sistemas o dejar de depender de un proveedor. Sin un resultado claro, todas las opciones parecen igual de buenas.
- Entiende lo que tienes. Mapea arquitectura, dependencias, flujos de datos, pruebas y las reglas de negocio escondidas en el código. Documenta la incertidumbre en lugar de ocultarla.
- Encuentra las costuras. Busca lugares donde puedas separar una capacidad del resto, como una frontera de API, un módulo con pocas dependencias o un flujo con entrada y salida claras.
- Elige el primer paso seguro más pequeño. Escoge una pieza valiosa, acotada y fácil de verificar.
- Reemplaza y verifica. Construye la pieza nueva, córrela junto a la anterior cuando sea posible, compara resultados y cambia solo cuando haya confianza. Conserva una forma de regresar a la versión anterior.
- Repite y cambia cómo trabajas. Actualiza pruebas, documentación y prácticas de liberación para que el sistema nuevo no acumule los mismos problemas.
Dónde ayuda la IA y dónde no
Los agentes de IA pueden acelerar el análisis: leer una base de código grande, resumir módulos, mapear dependencias, redactar documentación, proponer pruebas e implementar cambios bien definidos. No eliminan la necesidad de contexto de negocio, criterio de arquitectura, revisión de seguridad ni controles de producción. Las personas deciden qué conservar, qué cambiar y qué llega a producción.
Señales de que es momento de modernizar
- La entrega se frena porque los módulos, las integraciones y los responsables no están claros.
- Se está considerando una migración o un movimiento a la nube.
- La deuda técnica compite con el trabajo del roadmap.
- El conocimiento crítico vive en unas pocas personas.
Preguntas para un proveedor de modernización
- ¿Cómo decidirán qué conservar, cambiar o reemplazar? Busca un diagnóstico basado en evidencia antes de cualquier ruta de migración.
- ¿Cuál es el primer paso más pequeño? Una primera pieza acotada muestra cómo trabaja el equipo.
- ¿Cómo protegen producción? Pregunta por pruebas, ejecución en paralelo, puntos de revisión y cómo volver a la versión anterior.
- ¿Qué tendremos al final de cada paso? Documentación, pruebas y una mejora funcionando.
- ¿Cómo se define el alcance? Empieza con un sistema, una decisión y criterios de aceptación por escrito.
Si estás evaluando una modernización, conoce cómo abordamos la modernización de software legacy. Para entender el modelo de entrega que usamos, lee qué es un Pod de IA.