Cómo modernizar software legacy sin parar el negocio
Publicado:
Por Goiko, Founder & AI Solutions CTO de GUGŌ Creative
Cómo modernizar software legacy por fases sin parar el negocio: diagnóstico, tests, patrón strangler fig, migración de datos y cómo presupuestar cada etapa.
Casi todas las empresas con unos años de actividad tienen un sistema que nadie quiere tocar: un ERP propio, una intranet de pedidos, una aplicación de facturación o un backoffice escrito hace una década. Sigue funcionando y sostiene ingresos reales, pero cada cambio cuesta más, depende de una o dos personas y bloquea integraciones que el negocio ya necesita.
Modernizar software legacy no significa necesariamente reescribirlo desde cero. La reescritura completa suele ser la primera opción que se plantea y, a menudo, la más arriesgada: congela la evolución durante meses, obliga a redescubrir reglas de negocio que nadie documentó y concentra todo el riesgo en un único día de corte. La alternativa habitual es aislar el sistema, entenderlo, protegerlo con pruebas y sustituirlo por partes mientras la operación continúa.
Esta guía explica cómo decidir entre mantener, sustituir o modernizar por fases, qué técnicas permiten hacerlo sin parar el negocio, cómo tratar los datos y la seguridad, y cómo presupuestar una modernización de forma que cada etapa tenga un alcance y un resultado verificables.
Qué es software legacy y cuándo se convierte en un problema
«Legacy» no es sinónimo de antiguo. Un sistema de hace quince años puede estar bien documentado, probado y con soporte, y no requerir más que mantenimiento. Lo que convierte un sistema en legacy es que cambiarlo se ha vuelto caro, lento o peligroso respecto al valor que sostiene.
Las señales más habituales son estas:
- Cada cambio exige miedo, muchas pruebas manuales y una ventana de despliegue fuera de horario.
- El lenguaje, el framework, el sistema operativo o la base de datos ya no tienen soporte cómodo o han dejado de recibir parches de seguridad.
- No hay API ni forma limpia de integrarlo con CRM, ecommerce, BI o herramientas de IA, y todo pasa por exportaciones manuales.
- El conocimiento está concentrado en una persona o en un proveedor del que la empresa depende sin alternativa.
- Los errores se detectan cuando un cliente o el equipo de administración los sufren, no antes.
- Las reglas de negocio importantes viven en procedimientos almacenados, macros o código que nadie se atreve a leer.
Una sola señal no justifica un proyecto. Varias a la vez, sobre un sistema que factura, opera o atiende clientes, sí justifican al menos un diagnóstico.
Las opciones reales: mantener, sustituir, migrar o modernizar por fases
Antes de hablar de arquitectura conviene poner todas las opciones sobre la mesa. La guía de estrategias de migración de AWS las agrupa en siete «R» (retirar, retener, realojar, reubicar, recomprar, replataformar y refactorizar) y recuerda que refactorizar es la más compleja y costosa. Para una empresa mediana, la decisión suele reducirse a cinco caminos:
| Opción | Encaja cuando | Riesgo principal |
|---|---|---|
| Mantener y estabilizar | El sistema cumple, cambia poco y el problema es de soporte, copias o seguridad básica | Aplazar una decisión que se encarece cada año |
| Migrar la infraestructura sin tocar la lógica | El cuello de botella son servidores, sistema operativo o hosting, no el código | Trasladar la deuda técnica intacta a otro entorno |
| Sustituir por un producto estándar o SaaS | El proceso no es diferencial y un producto de mercado lo cubre bien | Adaptar la operación al producto y migrar datos sin pérdida |
| Modernizar por fases | El sistema es crítico, encierra reglas propias y debe seguir operando | Gestionar durante un tiempo la convivencia de dos sistemas |
| Reescritura completa | El sistema es pequeño, bien entendido y su sustitución es sencilla | Retrasos, reglas olvidadas y un corte único de alto impacto |
La reescritura completa no está prohibida: para un sistema pequeño y bien conocido puede ser lo más rápido. El problema aparece cuando se aplica a un sistema grande y crítico. Martin Fowler describe en su texto sobre la aplicación Strangler Fig por qué la sustitución gradual reduce el riesgo: cada pieza es más pequeña, el negocio recibe valor antes y cada etapa enseña algo sobre el comportamiento real del sistema que corrige la siguiente.
Si el debate de fondo es si el proceso merece software propio o un producto de mercado, la comparación está desarrollada en cuándo desarrollar software a medida y cuándo no.
Antes de tocar código: diagnóstico del sistema legacy
La fase que más riesgo reduce suele ser la primera, y es la que más tienta recortar. Sin diagnóstico, cualquier estimación es una apuesta.
Mapear módulos, dependencias y reglas ocultas
El objetivo es un mapa útil, no una documentación exhaustiva: qué módulos existen, qué procesos de negocio sostiene cada uno, qué sistemas se conectan, qué tareas programadas se ejecutan y dónde está la lógica. En sistemas centrados en la base de datos, buena parte de las reglas vive en procedimientos almacenados, disparadores o vistas, y es ahí donde suelen esconderse los casos especiales que una reescritura olvida.
Conviene complementarlo con entrevistas cortas a quienes usan el sistema cada día. Las excepciones que el equipo resuelve «a mano» son reglas de negocio aunque no estén en el código.
Medir antes de cambiar
Muchos sistemas legacy no tienen observabilidad: no se sabe qué pantallas se usan, qué procesos fallan ni cuánto tardan. Añadir logs estructurados, métricas básicas y alertas sobre el sistema actual permite dos cosas: saber qué partes se usan de verdad (y cuáles se pueden retirar) y tener una línea base para comprobar que la versión nueva no empeora nada.
Tests de caracterización: fijar lo que el sistema hace hoy
Antes de cambiar comportamiento hay que poder detectar cambios no deseados. Los tests de caracterización registran lo que el sistema hace actualmente con entradas reales —el cálculo de una factura, una tarifa, un descuento por volumen—, aunque ese comportamiento sea discutible. No validan que el resultado sea correcto; garantizan que la versión nueva produce el mismo resultado hasta que alguien decida cambiarlo a propósito.
Los asistentes de código con IA pueden acelerar la lectura de código antiguo, proponer resúmenes o sugerir casos de prueba. Son una ayuda, no una garantía: sus conclusiones deben contrastarse con tests y con las personas que conocen el proceso.
Cómo modernizar software legacy por fases sin parar la operación
Las técnicas que siguen no son exclusivas de grandes empresas: sirven para el backoffice de una pyme y para una plataforma corporativa; cambia la escala.
Una fachada que decide qué atiende cada sistema
El patrón Strangler Fig, documentado en el Azure Architecture Center, introduce una fachada o proxy delante del sistema antiguo. Al principio casi todas las peticiones siguen yendo al legacy; a medida que se construyen piezas nuevas, la fachada desvía hacia ellas las funciones migradas. Los usuarios siguen usando la misma entrada y la migración avanza sin un corte global.
La propia documentación de Microsoft señala sus límites: la fachada no debe convertirse en un punto único de fallo ni en un cuello de botella, y el patrón no encaja si las peticiones no se pueden interceptar, si no hay acceso al código ni a otro punto de integración, o si el sistema es tan pequeño que sustituirlo entero es sencillo.
Una capa anticorrupción entre lo nuevo y lo antiguo
Durante la convivencia, el sistema nuevo necesitará datos o funciones que siguen en el antiguo. Si se conecta directamente, acaba heredando sus nombres, formatos y rarezas. La capa anticorrupción traduce entre ambos modelos para que el diseño nuevo no se contamine. Tiene un coste: añade latencia y es un componente más que mantener, monitorizar y, cuando termine la migración, retirar o conservar de forma deliberada.
Cambiar por dentro sin ramas eternas
Cuando la sustitución afecta a un componente interno —el motor de cálculo de precios, la generación de documentos—, la técnica branch by abstraction crea una abstracción delante de la implementación actual, migra a ella el código que la usa y construye la nueva implementación detrás, conviviendo con la anterior. Combinada con feature toggles, permite desplegar código nuevo desactivado y activarlo por usuario, cliente o porcentaje. El riesgo conocido es acumular interruptores: cada uno añade lógica condicional y pruebas, así que deben tener propietario y fecha de retirada.
Migrar los datos por dominios, no de golpe
Los datos suelen ser la parte más delicada. El ejemplo de base de datos del mismo patrón de Microsoft describe una secuencia prudente: carga inicial del dominio a una base nueva, sincronización continua de cambios (change data capture), validación de consistencia entre ambas y, solo después, conversión de la nueva base en sistema de registro. Mientras las tablas antiguas sigan existiendo, volver atrás es viable; eliminarlas es un paso final y deliberado.
- Define qué sistema es fuente de verdad para cada entidad en cada fase: cliente, pedido, factura, stock.
- Prueba la migración con copias reales anonimizadas cuando sea posible, incluidos datos antiguos y mal formados.
- Compara totales, recuentos y casos críticos entre sistema antiguo y nuevo antes de cada corte.
- Documenta cómo se revierte cada paso y quién decide hacerlo.
La disciplina de contratos, idempotencia y fuentes de verdad es la misma que en cualquier integración seria; está desarrollada en integrar ERP, CRM e IA y en las buenas prácticas de diseño de APIs.
Una modernización bien planteada se nota en que el negocio apenas se entera de que está ocurriendo.
Seguridad: dependencias sin soporte y superficie expuesta
Con frecuencia, la urgencia real no es funcional sino de seguridad. La categoría de fallos en la cadena de suministro de software del OWASP Top 10:2025 considera vulnerable el software desactualizado o sin soporte, lo que incluye sistema operativo, servidores, gestores de base de datos, frameworks y librerías. Entre sus recomendaciones están mantener un inventario de componentes (SBOM), eliminar dependencias y funciones que no se usan y vigilar de forma continua las vulnerabilidades publicadas.
En la práctica, esto da una primera fase con valor inmediato aunque la modernización funcional tarde: inventario de versiones, identificación de lo que ya no recibe parches, reducción de la superficie expuesta (por ejemplo, retirar pantallas o servicios que nadie usa) y un plan de actualización priorizado por riesgo. Cuando hay datos personales o requisitos sectoriales, el alcance concreto debe revisarse con quien asesore a la empresa en cumplimiento; este artículo no sustituye ese análisis.
Cuánto cuesta modernizar software legacy
No existe un precio único, y conviene desconfiar de quien lo dé sin ver el sistema. El coste depende del tamaño y la criticidad, de la calidad del código y los datos, del número de integraciones, de cuánto conocimiento está documentado y de la estrategia elegida. Sí hay referencias para ordenar la conversación.
En el informe de precios de software e IA en España 2026 que publicamos, una plataforma interna con varios roles, flujos, permisos e integraciones se sitúa entre 35.000 y 70.000 €, y un sistema empresarial complejo con integraciones legacy, trazabilidad y alta disponibilidad parte de 70.000 € (rango orientativo de 70.000 a 120.000 € o más). Un MVP operativo con un módulo core empieza en 15.000 €. El desglose por tipo de proyecto está en cuánto cuesta desarrollar software a medida.
Una modernización por fases cambia la forma de presupuestar más que el total: en lugar de un único precio para «el sistema nuevo», cada fase tiene su alcance, su entregable y su criterio de éxito, y la siguiente se estima con lo aprendido. Hay que contar también con costes que una reescritura no muestra en la primera oferta:
- Diagnóstico inicial, observabilidad y tests de caracterización.
- Arquitectura de transición: fachada, capa anticorrupción y sincronización de datos mientras conviven ambos sistemas.
- Migración y validación de datos, incluida la limpieza de históricos.
- Formación y acompañamiento en cada corte.
- Mantenimiento del sistema nuevo: como referencia, entre el 15 y el 25 % del coste inicial al año, según criticidad y nivel de servicio.
Para recibir propuestas comparables, la guía sobre cómo pedir presupuesto de desarrollo de software detalla qué información preparar. Y para no subestimar lo que viene después, conviene leer el coste real de mantener software a medida.
Ejemplo hipotético: un backoffice de pedidos y facturación
El siguiente escenario es ilustrativo, no un caso de cliente. Una distribuidora usa un backoffice propio de hace doce años para pedidos, tarifas por cliente y facturación. Funciona, pero no tiene API, el servidor usa una versión sin soporte y solo un desarrollador externo conoce el módulo de tarifas. Una secuencia razonable sería:
- Diagnóstico y estabilización. Mapa de módulos, inventario de versiones, copias verificadas, logs y alertas. Se retiran dos informes que nadie usa.
- Tests de caracterización del cálculo de tarifas y facturas con pedidos reales anonimizados, para fijar el comportamiento actual.
- Fachada y primera API de solo lectura sobre clientes y pedidos, que permite conectar el CRM sin tocar el núcleo.
- Primer módulo nuevo: el portal de pedidos para clientes, que lee y escribe a través de la capa anticorrupción mientras el legacy sigue facturando.
- Migración del dominio de tarifas con branch by abstraction: el cálculo nuevo convive con el antiguo y se comparan resultados antes de activarlo por grupos de clientes.
- Facturación y retirada progresiva de las tablas antiguas, solo cuando la consistencia está validada y existe plan de vuelta atrás.
En cada paso la empresa obtiene algo útil —menos riesgo de seguridad, integración con el CRM, un portal nuevo— y puede detenerse o cambiar prioridades sin haber perdido la inversión. Esa es la diferencia práctica con una reescritura que solo entrega valor al final.
Errores frecuentes al modernizar sistemas legacy
- Reescribir todo sin retorno intermedio. Meses de trabajo sin nada en producción y un corte final de alto riesgo.
- Subestimar las reglas de negocio ocultas. Descuentos, redondeos, excepciones fiscales o acuerdos con clientes concretos que solo estaban en el código.
- Copiar el sistema antiguo pantalla por pantalla. Se replican también los comportamientos que nadie quería conservar.
- Migrar los datos al final. Los problemas de calidad de datos aparecen tarde y bloquean el corte.
- Dejar la arquitectura de transición sin dueño. Fachadas, sincronizaciones y toggles que nadie retira se convierten en el nuevo legacy.
- Parar la operación por ambición. Planificar grandes cortes en temporada alta o sin plan de reversión.
Cómo empezar
El primer paso no es elegir lenguaje ni nube. Es acotar qué parte del sistema genera más riesgo o bloquea más negocio, entenderla y protegerla. A partir de ahí, la hoja de ruta se construye por fases cortas, cada una con su resultado.
Si estás valorando modernizar un sistema crítico, un diagnóstico de IA y software permite revisar arquitectura, dependencias, datos y riesgos antes de comprometer un presupuesto grande. Lo que más suele mover la estimación final no es la tecnología elegida, sino lo que aparece al revisar datos y reglas de negocio.
Preguntas frecuentes
¿Es mejor reescribir un sistema legacy o modernizarlo por fases?
Para sistemas grandes y críticos, modernizar por fases suele ser más seguro porque entrega valor antes y permite corregir el rumbo. La reescritura completa puede tener sentido si el sistema es pequeño, está bien entendido y sustituirlo entero es sencillo.
¿Qué es el patrón strangler fig?
Es una técnica de migración gradual: una fachada se coloca delante del sistema antiguo y desvía hacia componentes nuevos las funciones que se van sustituyendo, hasta que el sistema original puede retirarse sin un corte global.
¿Cuánto cuesta modernizar un software legacy?
Depende del tamaño, la criticidad, las integraciones y la calidad de los datos. Como referencia de nuestra web, una plataforma interna se sitúa entre 35.000 y 70.000 € y un sistema complejo con integraciones legacy parte de 70.000 €. Lo recomendable es presupuestar por fases, empezando por un diagnóstico.
¿Se puede modernizar sin parar la operación?
En la mayoría de los casos sí, si se usan técnicas de convivencia —fachada, capa anticorrupción, feature toggles y sincronización de datos— y cada corte tiene validación previa y plan de reversión. Algunas tareas, como el cambio final de sistema de registro, pueden requerir una ventana planificada.
¿Cuánto cuesta mantener el sistema después de modernizarlo?
Como referencia, el mantenimiento correctivo y evolutivo de un software a medida se sitúa entre el 15 y el 25 % del coste inicial al año, según criticidad, integraciones y nivel de servicio pactado.