Qué es un sistema legado (y por qué la edad no es el criterio)
Un sistema legado es un sistema que el negocio todavía usa y del que depende, pero que se volvió difícil de cambiar con seguridad. La edad ayuda a explicar cómo llegó a ese punto, pero no define nada: hay sistemas de diez años en excelente estado y sistemas de tres años que nadie se atreve a tocar.
Lo que caracteriza al legado es la combinación de tres cosas: el conocimiento de cómo funciona está en pocas cabezas (o en ninguna), no hay pruebas automáticas que digan si un cambio rompió algo, y la tecnología de base perdió soporte o es difícil contratar gente para trabajar en ella.
Por eso la pregunta útil no es “¿este sistema es viejo?”, sino “¿puedo cambiar este sistema con seguridad, al ritmo que el negocio necesita?”. Si la respuesta es no, usted tiene un legado, y la modernización pasa a ser una decisión de negocio, no solo de TI.
Señales de que la modernización de sistemas legados ya no puede esperar
Las señales más confiables no aparecen en ninguna herramienta. Aparecen en el día a día de la operación:
- Los cambios pequeños tardan semanas, porque nadie sabe qué más se va a romper.
- El sistema depende de una o dos personas. Cuando una se va o toma vacaciones, la empresa contiene la respiración.
- El sistema se cae, se traba o se vuelve lento en los horarios pico, y la solución siempre es un parche.
- No se puede integrar con herramientas nuevas (pagos, correo, mensajería, BI) sin trucos.
- El proveedor del lenguaje, de la base de datos o del servidor dejó de dar soporte, y las actualizaciones de seguridad no llegan.
- Cada corrección abre dos defectos nuevos y nadie puede probar todo antes de publicar.
- El costo de mantenimiento sube cada año y la lista de pedidos del negocio solo crece.
El costo de no hacer nada
Mantener el legado como está parece la opción barata porque no hay propuesta ni inversión visible. Pero el costo existe y aparece en otros lugares: en el tiempo del equipo gastado en parches, en oportunidades que el sistema no deja explorar, en riesgo de seguridad y en dependencia de personas clave.
Un ejercicio simple: sume las horas mensuales gastadas en correcciones y retrabajo, anote lo que el negocio dejó de hacer porque el sistema no lo permite, y compárelo con lo que costaría un proyecto incremental. No necesita ser exacto, necesita ser honesto. En muchos casos, el costo de esperar ya es mayor que el de empezar por una parte.
Está también el riesgo de cola: el día en que falla el servidor, la base de datos o la única persona que conoce el sistema. Ese costo no entra en la planilla hasta que ocurre, y entonces suele ser el más caro.
Tres o más elementos de la lista anterior ya justifican un diagnóstico. Uno o dos pueden resolverse con ajustes puntuales, y está bien: no toda molestia requiere un proyecto de modernización.
Las cinco estrategias de modernización, de la menos a la más invasiva
Modernizar no es sinónimo de reescribir. Hay cinco caminos, y elegir el correcto para cada parte del sistema es la mitad del trabajo:
- Mantener y rodear de cuidado: no tocar el código, pero agregar monitoreo, copias de seguridad probadas y documentación. Sirve para sistemas estables y de bajo valor estratégico.
- Encapsular: poner una capa (una API, por ejemplo) delante del legado para que los sistemas nuevos se comuniquen con él sin depender de su código interno.
- Refactorizar: reorganizar el código por dentro, sin cambiar el comportamiento, para que quede legible, testeable y actualizable.
- Migrar por etapas: construir la versión nueva junto a la antigua y pasar una funcionalidad a la vez, hasta apagar el legado.
- Reescribir desde cero: construir todo de nuevo y cambiar de una vez. Es la opción más riesgosa y la más tentadora.
Refactorizar o reescribir: por qué preferimos empezar por la refactorización
La reescritura completa atrae porque promete un comienzo limpio. El problema es que el código antiguo, por malo que parezca, lleva años de reglas de negocio y correcciones que nadie documentó. Joel Spolsky lo describió en 2000 en el texto que se volvió referencia sobre el tema (“Things You Should Never Do”), al argumentar que reescribir desde cero suele tirar a la basura el conocimiento acumulado.
Eso no significa que reescribir sea siempre un error. Tiene sentido cuando la tecnología no tiene salida, cuando la arquitectura impide que el negocio crezca o cuando el sistema es lo bastante pequeño para que el riesgo sea bajo. El punto es decidir con criterio, y no por cansancio del código antiguo. Detallamos esos criterios en refactorizar o reescribir: cómo decidir sin arrepentirse.
Si lo que usted necesita, en realidad, es una aplicación nueva (y no la modernización de algo que ya existe), conviene ver cómo funciona un prototipo navegable gratuito antes de decidir cualquier cosa.
Migración incremental: cómo modernizar sin detener la operación
La migración incremental es la forma de modernizar sin detener el negocio. La idea es simple: el sistema nuevo crece junto al antiguo, y el tráfico y las funcionalidades pasan de uno a otro poco a poco. Este patrón se conoce como strangler fig (higuera estranguladora), descrito por Martin Fowler: la aplicación nueva “envuelve” a la antigua, parte por parte, hasta que el legado pueda apagarse.
La hoja de ruta que seguimos, a grandes rasgos:
- Inventario: mapear módulos, base de datos, integraciones, tareas programadas y quién usa qué.
- Pruebas de caracterización: antes de cambiar cualquier cosa, registrar el comportamiento actual (entradas y salidas), para saber después si algo cambió sin querer.
- Capa de convivencia: un punto de entrada (proxy o enrutador) que decide, por ruta o funcionalidad, si la solicitud va al sistema antiguo o al nuevo.
- Datos: decidir si la base se comparte durante la transición o se migra antes que las funciones. En general, mantener una única base al comienzo evita tener dos fuentes de la verdad que sincronizar.
- Rebanadas pequeñas: empezar por un módulo de riesgo bajo y valor visible, publicar, medir y solo entonces pasar al siguiente.
- Plan de vuelta: cada etapa debe poder deshacerse rápidamente (feature flag o cambio de ruta).
- Apagar el antiguo: solo cuando nada pasa ya por él, con copia de seguridad y un período de observación.
Qué cambia (y qué no) la IA en la modernización de código
La IA se volvió parte de nuestro proceso y acelera etapas específicas: leer y explicar código desconocido, mapear dependencias, generar una primera versión de la documentación, sugerir pruebas de caracterización y traducir fragmentos repetitivos de un framework a otro.
Lo que no hace: decidir la arquitectura, descubrir reglas de negocio que nunca se escribieron en ningún lugar, garantizar que el comportamiento sigue igual ni asumir la responsabilidad por el resultado. El código generado en lote, sin pruebas y sin revisión, solo cambia un legado por otro, más nuevo e igual de difícil de entender.
Por eso nuestra regla es: pasos pequeños, pruebas primero, revisión humana en cada entrega y comparación del comportamiento antiguo con el nuevo. La IA reduce el esfuerzo; la responsabilidad sigue siendo de la ingeniería. Lo que funciona y lo que no funciona, en la práctica, está en IA en la refactorización de código.
Cuánto cuesta modernizar: qué pesa en el presupuesto
No existe un precio de góndola, y conviene desconfiar de quien da un número sin mirar el sistema. El costo depende principalmente del tamaño y del estado del código, de la existencia de documentación y de pruebas, de la cantidad de integraciones, de la complejidad de la base de datos, del número de perfiles de usuario y de módulos, y del riesgo de la operación (cuánto le cuesta al negocio una hora detenido).
El enfoque incremental ayuda porque distribuye la inversión: en lugar de un único proyecto grande, hay etapas con entrega y costo propios, y se puede ajustar el rumbo en cada una. Antes de cualquier propuesta, un diagnóstico del legado (código, base de datos, integraciones y puntos críticos) convierte la incertidumbre en un alcance que se puede presupuestar.
Los factores en detalle están en cuánto cuesta modernizar un sistema legado, y el razonamiento general de presupuesto en cuánto cuesta un software a medida.
Por dónde empezar: un criterio simple
Si el sistema tiene veinte módulos, no se pueden atacar todos a la vez. Priorice cruzando dos ejes: cuánto duele (incidentes, lentitud, retrabajo) y cuánto vale (ingresos, clientes, decisiones que dependen de él). El módulo que duele mucho y vale mucho va primero. El que duele poco y vale poco puede esperar, o nunca modernizarse.
Funciona bien elegir una rebanada piloto: lo bastante pequeña para terminar rápido, lo bastante importante para que el resultado se note. Valida el enfoque, el equipo y la capa de convivencia antes de invertir en el resto.
Y defina de antemano cómo va a medir: tiempo para publicar un cambio, cantidad de incidentes, tiempo de respuesta, horas de mantenimiento. Sin métrica, nadie sabe si la modernización funcionó.
Después de la migración: mantenimiento continuo
Modernizar sin mantener solo posterga el problema. Un sistema nuevo envejece igual: dependencias desactualizadas, correcciones de seguridad acumuladas, módulos que nadie revisa. El mantenimiento continuo (actualizaciones, monitoreo, correcciones y evolución en pequeños pasos) es lo que evita que el sistema nuevo se convierta en el legado de dentro de cinco años.
Un código organizado, con pruebas y un framework actual, también hace el mantenimiento más liviano y previsible. Es una de las ganancias que más se notan después de la refactorización, y es lo que un contrato de mantenimiento bien diseñado debe reflejar, como explicamos en mantenimiento de software: qué incluye y cómo contratarlo.
De nuestra experiencia
En SKAD refactorizamos con apoyo de IA cinco sistemas que están en producción: SyncStop, 4Car, KaraokeApp, The Bee App y DEM (inspección de equipos). Todos eran PHP puro con jQuery y Bootstrap, y las aplicaciones eran en Cordova. Hoy funcionan con PHP 8.3 y Slim 4 en la API, React con Vite en la web y React Native con Expo en la app. Mantuvimos PHP a propósito: lo que cambió fue el framework y la arquitectura, no el lenguaje.
En otro frente, reconstruimos una plataforma de gestión y cuidado animal que era PHP 7 con Azure SQL. Mantuvimos la base de datos, migramos los datos primero y las funciones después, con un desarrollador implementando a partir de un documento de plan y nosotros siguiendo el avance con listas macro por perfil de usuario. También hay dos clientes antiguos en camino a la misma refactorización hacia el stack nuevo: Inspefire, un sistema de inspección de seguridad contra incendios que atendemos hace 10 años, y The Horus, una app que mantenemos y alojamos.
Preguntas frecuentes
¿Cuánto tarda la modernización de un sistema legado?
Depende del tamaño y del estado del sistema, y por eso no damos plazos sin un diagnóstico. En la migración incremental, la ganancia aparece por etapas: la primera rebanada queda lista mucho antes que el proyecto completo, y el sistema sigue funcionando durante todo el proceso.
¿Tengo que detener el sistema durante la modernización?
No. En la migración incremental, el sistema antiguo sigue funcionando mientras el nuevo se construye a su lado, y cada funcionalidad solo pasa a la versión nueva después de validada, con un plan de vuelta por si algo sale mal.
¿Conviene más reescribir todo desde cero?
En general, no. La reescritura completa tiene el mayor riesgo, porque descarta reglas de negocio incrustadas en el código antiguo y congela la evolución del producto durante el proyecto. Tiene sentido en casos específicos: tecnología sin salida, arquitectura que bloquea el negocio o sistema pequeño.
¿La IA puede modernizar el sistema por sí sola?
No. Acelera la lectura, la documentación, las pruebas y las tareas repetitivas, pero el diagnóstico, las decisiones de arquitectura y la revisión siguen siendo humanos. El código migrado en lote, sin pruebas y sin revisión, tiende a esconder errores en lugar de resolverlos.
¿Tengo que cambiar la base de datos?
No siempre. La base puede mantenerse y migrarse después, o nunca. Empezar con una única base compartida entre el sistema antiguo y el nuevo evita mantener dos fuentes de la verdad durante la transición.
¿Cómo empiezo a modernizar mi sistema?
Con un diagnóstico del legado: mapa de módulos, base de datos, integraciones y puntos críticos. De él sale un plan de migración por etapas, con prioridades, riesgos y un primer módulo piloto. Vea cómo es la modernización de sistemas legados en SKAD.
Conclusión
Si llegó hasta aquí con un sistema específico en mente, la recomendación es la misma que daríamos en una primera conversación: no empiece por la tecnología, empiece por el diagnóstico. Liste los módulos, marque dónde duele y dónde hay más valor, elija una rebanada pequeña y planifique el camino de vuelta. Modernizar es una secuencia de decisiones pequeñas y reversibles, no un salto. Si quiere ayuda para hacer ese diagnóstico, conversamos sin compromiso sobre la modernización de su sistema.