Modernización de sistemas legacy: cuándo, por qué y cómo migrar el software heredado de tu empresa

Hay un patrón que se repite en empresas que llevan años funcionando: el software que las sostiene es más viejo de lo que muchos en la organización llevan trabajando allí. Funciona. La gente lo conoce. Nadie quiere tocarlo. Y, al mismo tiempo, frena el negocio cada vez más: integraciones imposibles, cambios que tardan meses, costes que crecen sin que mejore nada. La modernización de sistemas legacy no es un capricho técnico, es una decisión estratégica que aparece tarde o temprano en cualquier empresa con cierto recorrido.

En este artículo explicamos qué es realmente un sistema legacy, cuándo tiene sentido modernizarlo, qué estrategias existen, qué riesgos no se cuentan en los kick-offs y cómo abordar el proceso sin romper la operación. Si tu empresa carga con un sistema antiguo que pesa más de lo que aporta, te interesa.

Qué es un sistema legacy (y qué no lo es)

Un sistema legacy es software que sigue dando servicio crítico a un negocio pero cuyo diseño, tecnologías o procesos de desarrollo se han quedado por detrás del estado del arte hasta el punto de ralentizar al negocio. La palabra clave es “ralentizar”. Un sistema antiguo que cumple, evoluciona y no genera coste excesivo no es legacy: es un sistema maduro. Legacy es otra cosa.

Una herramienta acaba siendo legacy cuando se cumplen, normalmente al mismo tiempo, varias de estas condiciones:

• La tecnología base ya no recibe soporte oficial o tiene comunidad mínima.
• El conocimiento del sistema vive en pocas personas, y algunas ya no están.
• Cambiar algo pequeño exige semanas y rezos.
• No hay tests, no hay despliegue automatizado o el entorno de desarrollo solo lo replica una persona.
• Integrar nuevos canales, productos o partners es prácticamente imposible.
• Cualquier auditoría de seguridad genera más hallazgos que tickets cierra el equipo en un trimestre.

Si reconoces tres o más de estos puntos en tu organización, no estás ante “un software un poco viejo”. Estás ante un riesgo de negocio.

Por qué modernizar: la pregunta correcta no es “cuánto cuesta migrar”

La pregunta que casi siempre se hace mal es “¿cuánto cuesta migrar este sistema?”. Esa pregunta, sola, no se puede responder con honestidad. La pregunta útil es: “¿cuánto nos cuesta seguir como estamos?”.

El coste de mantener un legacy no se ve en una factura, se ve en oportunidades que no se persiguen, lanzamientos que se posponen, talento que no quiere trabajar en eso y riesgos que se acumulan sin que nadie los firme.

Algunos costes reales del statu quo que rara vez se contabilizan:

1. Velocidad de negocio. Cada nueva idea pasa por un cuello de botella técnico. Funcionalidades de cuatro semanas tardan cuatro meses. Eso es revenue que no llega.
2. Riesgo de continuidad. Personas clave, hardware obsoleto, dependencias sin parches de seguridad. La probabilidad de incidente no es cero, y el impacto puede ser parar la operación.
3. Coste de talento. Pocos ingenieros con experiencia quieren trabajar de forma indefinida en stacks de hace quince años. El recambio es caro y la curva de productividad larga.
4. Imposibilidad de integrar. La empresa quiere conectar su sistema con un nuevo CRM, una plataforma de IA o un partner, y no se puede. Cada bloqueo es un negocio que no se hace.
5. Coste de infraestructura. Servidores que no se pueden virtualizar bien, licencias antiguas, contratos cerrados. La factura es alta y se justifica mal.

La decisión de modernizar no es ideológica. Es un cálculo de coste de oportunidad frente a coste de cambio. Cuando el primero supera al segundo, modernizar deja de ser opcional.

Señales claras de que tu sistema legacy ha cruzado el umbral

Hay momentos típicos en los que una empresa pasa de tolerar a actuar. Si reconoces alguno de estos, probablemente ya estás tarde:

• Un competidor lanza una funcionalidad que tú no puedes ofrecer porque tu sistema no la soporta.
• El equipo de producto pide algo “imposible” cada trimestre y se acostumbra a no pedir más.
• El proveedor de hosting o de licencias avisa de fin de soporte en X meses.
• La compañía afronta una auditoría regulatoria (RGPD, ENS, ISO 27001) y los hallazgos técnicos son inasumibles.
• La empresa va a entrar en una operación corporativa (M&A, ronda, venta) y la due diligence técnica es el cuello de botella.
• El CFO pide un plan plurianual de reducción de OPEX en TI.
• Cualquier persona dice, en una reunión, “no tocamos eso porque si se rompe no sabemos arreglarlo”.

Cuando aparecen estas señales, la conversación deja de ser “si modernizar” y pasa a ser “cómo modernizar”.

Estrategias reales de modernización

Hay un error muy común: pensar que modernizar significa, sí o sí, reescribir el sistema desde cero. No es la única opción. De hecho, suele ser la peor cuando no se han evaluado el resto. Estas son las estrategias más usadas en proyectos serios de migración.

1. Encapsular y aislar (la base previa a casi todo)

Antes de migrar, encapsular. Se rodea el sistema legacy con APIs claras y se deja de tocar su interior salvo para incidencias. Toda funcionalidad nueva se construye fuera, llamando al legacy como si fuera una caja negra. Es la base de patrones como Strangler Fig: el sistema nuevo “estrangula” al viejo poco a poco.

Ventaja: bajo riesgo, despliegue continuo, valor desde la primera semana. Inconveniente: requiere disciplina; si no se respeta el contrato, la nueva capa se contagia de las miserias del legacy.

2. Replatform (mudanza inteligente)

Mover el sistema a una plataforma más moderna sin reescribirlo: pasar a contenedores, llevarlo a la nube, cambiar la base de datos por una versión soportada, automatizar el despliegue. El código sigue siendo el mismo, pero el entorno alrededor mejora radicalmente.

Ventaja: gana tiempo, reduce coste de infraestructura, prepara el terreno. Inconveniente: si el problema es el código, replatform no lo resuelve; lo aplaza.

3. Refactorización progresiva

Tocar el código existente, en partes acotadas, con tests y métricas, para reducir deuda técnica sin cambiar el sistema entero. Funciona muy bien cuando la arquitectura tiene buen hueso y solo está sucia por dentro.

Ventaja: mantiene continuidad, mejora velocidad sin grandes interrupciones. Inconveniente: si la arquitectura es el problema, refactorizar pieza a pieza no llega.

4. Reescritura por dominios (la “gran migración” hecha bien)

Reescribir, sí, pero no todo a la vez. Se identifican dominios funcionales (catálogo, facturación, contratación, etc.) y se reescribe uno por uno detrás de la capa de APIs del paso 1. Cada dominio nuevo entra en producción cuando está listo y reemplaza al legacy en su parcela.

Ventaja: foco, riesgo controlado, ROI por iteración. Inconveniente: requiere disciplina de gestión y un equipo con experiencia real en migraciones.

5. Reemplazo por SaaS (cuando la lógica no es diferencial)

Si el sistema legacy hace algo que ya hace bien un SaaS estándar (un ERP, un CRM, un PMS, una facturación), la mejor migración es no migrar: comprar, configurar y conectar. Se reescribe solo la parte que sí es diferencial para el negocio.

Ventaja: time-to-value enorme. Inconveniente: solo aplica cuando la lógica es commodity. En sistemas que son el corazón competitivo de la empresa, esta vía no existe.

6. Reescritura completa (big bang)

Reescribir todo de cero y migrar de golpe. La estrategia con peor relación esfuerzo/riesgo del catálogo. Solo tiene sentido en sistemas pequeños, con alcance muy acotado, o cuando el sistema actual está literalmente roto y no admite estrategia más quirúrgica.

No existe el proyecto de “reescribir todo en seis meses” que termine en seis meses. Existe el proyecto de big bang que termina costando tres veces lo previsto y dejando al negocio con dos sistemas en paralelo durante años.

Riesgos típicos y cómo controlarlos

Los proyectos de modernización fracasan, casi siempre, por las mismas razones. Si conoces los antipatrones, los puedes evitar.

• Reescribir antes de entender. Empezar a picar código nuevo sin haber documentado el comportamiento real del legacy garantiza que el sistema nuevo nazca con bugs sutiles y reglas de negocio perdidas. Antes de reescribir, hay que descubrir.
• Subestimar la integración. El 60% del esfuerzo real de una migración no es construir el sistema nuevo, es reconectar con todo lo que lo rodea (ERP, CRM, BI, partners, ficheros de proveedores). Si el plan no contempla esto desde el principio, fallará.
• No medir el “antes”. Si no tienes métricas del sistema actual (tiempos de respuesta, tasa de error, throughput, coste por transacción), no podrás demostrar que el nuevo es mejor. Y sin esa demostración, perderás apoyo político.
• Romper la operación durante la migración. El negocio no puede pararse. Cualquier estrategia seria garantiza coexistencia controlada entre sistema nuevo y viejo, con planes de rollback claros.
• Dejar el “pequeño rincón” del legacy. Ese módulo “no estratégico” que nadie quiere tocar y se queda fuera del scope. Diez años después sigue ahí, igual de inmantenible, contagiando todo lo que lo rodea.
• Confundir migración con rediseño funcional. Si el equipo de producto aprovecha la migración para cambiar las reglas de negocio “ya que estamos”, el proyecto deja de ser migración y se convierte en producto nuevo. El plazo se duplica y la deuda nueva se acumula a toda velocidad.

Una migración bien gestionada distingue dos fases con claridad: primero, paridad funcional con el sistema viejo. Después, evolución. Mezclarlas es la receta más fiable para encadenar retrasos.

Cómo abordar el proyecto: pasos prácticos

Una manera concreta de empezar, válida para la mayoría de empresas medianas que afrontan modernización por primera vez:

1. Diagnóstico técnico. Auditoría del sistema actual: arquitectura, dependencias, calidad, integraciones, equipo, riesgos. Sin diagnóstico, cualquier plan es ficción.
2. Mapa de dominios y prioridades. Identificar qué partes del sistema dan más dolor y cuáles más valor. Modernizar primero por donde el ROI es claro.
3. Definición de la estrategia. Elegir entre las opciones del apartado anterior, normalmente combinándolas. La pregunta no es “qué patrón”, sino “qué patrón para cada dominio”.
4. Diseño del modelo de coexistencia. APIs, mensajería, sincronización de datos, gobierno de la fuente de verdad. Antes de reescribir nada, decidir cómo van a convivir lo viejo y lo nuevo.
5. Equipo dedicado, no compartido. La modernización no es una tarea de “huecos del sprint”. Necesita un squad estable, con foco y con autoridad técnica para tomar decisiones.
6. Roadmap por dominios con entregas reales. Iteraciones cortas, cada una con un dominio que pasa al sistema nuevo, con métricas y rollback. Lo contrario es un waterfall disfrazado de ágil.
7. Comunicación con el negocio. Cada hito traduce avance técnico en valor para el negocio. Sin esa traducción, la migración se queda sin presupuesto antes de terminar.
8. Plan de retirada del legacy. Suena obvio y casi nadie lo escribe: cómo, cuándo y bajo qué condiciones se apaga el sistema antiguo. Un legacy “casi apagado” durante años es una factura permanente.

Por qué Everglow encaja en proyectos de modernización legacy

Los proyectos de modernización son donde más se nota la diferencia entre una agencia que vende horas y un equipo que entiende el negocio. En Everglow trabajamos con un modelo de squads dedicados precisamente porque las migraciones serias no se hacen con freelancers rotativos ni con perfiles juniors aprendiendo sobre el sistema legacy del cliente.

Algunas cosas que aplicamos siempre que un cliente entra con un sistema heredado:

• Diagnóstico antes de propuesta. No proponemos plazos ni alcance hasta haber visto el código y hablado con quien lo mantiene.
• Estrategia mixta por dominio. Casi nunca recomendamos reescritura total. Cada dominio recibe el patrón que mejor le encaja.
• Coexistencia y rollback como ciudadanos de primera. Diseñamos el plan de migración asumiendo que el negocio no puede pararse y que cualquier paso debe poder revertirse.
• Foco en valor entregado, no en líneas de código. Cada release tiene que mover una métrica del negocio, no solo una métrica del backlog.
• Equipo estable durante todo el proyecto. La gente que diagnostica es la que migra y la que se queda hasta apagar el legacy.

Si tu empresa convive con un sistema legacy que ya está limitando el negocio (o lo va a hacer pronto), lo más valioso suele ser una conversación corta con quien ha hecho esto antes en empresas parecidas. Si quieres explorarlo con nosotros, este es el contacto directo con el equipo.

Conclusión: legacy no es un problema técnico, es un problema estratégico

La modernización de sistemas legacy se decide en el comité de dirección, no en el comité técnico. Cuando se trata como un proyecto de IT aislado, fracasa. Cuando se trata como una palanca estratégica del negocio, financiada en consecuencia y ejecutada con un equipo serio, transforma a la empresa. La pregunta correcta no es “¿podemos seguir un año más así?”. La pregunta correcta es “¿cuánto negocio estamos dejando sobre la mesa por no haber modernizado todavía?”.