La estabilidad es uno de los objetivos más importantes en el trabajo de infraestructura. Los sistemas predecibles son más fáciles de operar, más fáciles de razonar y más confiables cuando algo sale mal.
Pero dale suficiente tiempo, y esas mismas fuerzas que hacen a los sistemas confiables pueden transformarlos lentamente en otra cosa: sistemas que funcionan, pero que ya no pueden cambiar de forma segura.
Ahí es cuando la estabilidad deja de ser una fortaleza y silenciosamente se convierte en legacy.
Esta transición rara vez ocurre por negligencia o incompetencia. Ocurre porque los equipos toman decisiones racionales bajo presión: decisiones que tienen sentido en su momento y cuyo costo solo se vuelve evidente con el tiempo.
El legacy no está en la herramienta
En casi todos los equipos en los que he trabajado siempre ha existido algo considerado legacy.
He sido parte de equipos que migraron de Jenkins a GitHub Actions. Jenkins no se volvió legacy porque dejara de funcionar. Se volvió legacy porque:
- los pipelines estaban fuertemente acoplados a agentes específicos
- los cambios requerían conocimiento tribal
- las actualizaciones se sentían riesgosas
- experimentar era costoso
- había pipelines que nadie entendía por completo
Pero también he sido parte de equipos que migraron desde configuraciones legacy en GitHub Actions hacia setups más flexibles.
GitHub Actions suele empezar como un soplo de aire fresco: workflows simples, YAML en el repositorio, iteración rápida. Con el tiempo, las mismas fuerzas pueden aparecer: lógica copiada y pegada, supuestos implícitos, workflows y permisos que nadie revisa a fondo.
Eventualmente, empiezan a escucharse frases familiares:
- “No toques ese workflow.”
- “Solo una persona entiende cómo funciona.”
- “Funciona, mejor déjalo así.”
El legacy no es Jenkins. El legacy no es GitHub Actions. El legacy es el punto en el que cambiar se vuelve peligroso.
Por eso muchas organizaciones contratan gente nueva cuando enfrentan grandes migraciones de legacy: no porque los equipos actuales sean incapaces, sino porque el legacy carga con una deuda de contexto difícil de transferir.
Cómo identificarlo
En el papel, la solución suena sencilla: revisiones periódicas, refactors programados, actualizaciones regulares.
En la práctica, casi ningún equipo dedica tiempo (caro) de ingeniería a revisar sistemas que ya están corriendo y “funcionando bien”.
No hay una alerta que diga “esto se está volviendo legacy”. No hay incidente. No hay caída. No hay una falla visible.
Lo que sí es visible es:
- nuevas funcionalidades
- solicitudes de clientes u otros equipos
- parches de seguridad y vulnerabilidades
- problemas de producción
Reevaluar un sistema estable casi nunca gana frente a esas prioridades.
El legacy, en la mayoría de las organizaciones, no nace del abandono, nace de una priorización razonable.
Cada decisión es defendible:
- “No actualicemos ahorita, es riesgoso.”
- “Luego lo revisamos con más calma.”
- “Funciona, mejor no lo toquemos.”
Con el tiempo, esas decisiones se acumulan.
El sistema no se rompe, se endurece.
Cómo reducir los riesgos
Las actualizaciones por sí sola no salva sistemas. La estabilidad por sí sola tampoco.
Los sistemas sanos evolucionan de forma lenta y continua, generalmente a través de cambios localizados impulsados por fricción real.
Siempre existe el riesgo de que algo eventualmente se vuelva legacy. El objetivo es retrasarlo, contenerlo y reducir el riesgo que conlleva.
La estabilidad no es el enemigo. El legacy no es un fracaso.
El legacy es lo que ocurre cuando los sistemas sobreviven a las decisiones que los moldearon. No viene de la herramienta, sino de cómo los equipos de ingeniería toman decisiones a lo largo del tiempo.
Un buen equipo de ingeniería no elige entre estabilidad o cambio; sabe cuándo cada uno empieza a volverse peligroso.