Modernización de sistemas legacy: cuándo migrar, cuándo refactorizar, cuándo reescribir (con costos reales)

"Tenemos un sistema que arrancó en 2008 y ya no aguanta". O en VB6. O un AS/400. O un Cobol que nadie en el equipo actual sabe leer. O un PHP 5.4 con frameworks que dejaron de mantenerse. Si tu empresa tiene más de 10 años, casi seguro tiene al menos un sistema así. Y la pregunta que llega tarde o temprano al directorio es: ¿qué hacemos con esto?

La respuesta correcta puede valer entre USD 30.000 y USD 2.000.000. La incorrecta puede costar la operación del negocio durante meses. Después de modernizar sistemas para empresas grandes (donde la complejidad es alta y los riesgos también), te paso el marco que usamos para decidir, las cinco estrategias posibles, y los errores que vemos repetirse.

Por qué la decisión es tan difícil

Un sistema legacy típico tiene tres características que lo hacen peligroso de tocar:

• Funciona. Eso es lo más importante. No funciona perfecto, pero funciona, y la empresa depende de él. Cualquier reemplazo tiene que mantener esa continuidad operativa.
• Tiene 10-20 años de reglas de negocio acumuladas, muchas no documentadas, que aparecieron porque "el cliente X lo pidió en 2014". Mucha de esa lógica está en el código y no en la cabeza de nadie hoy.
• Está conectado con otros sistemas. ERP, RRHH, facturación, reporting. Cambiar uno afecta a todos los demás.

Por eso "vamos a reescribirlo de cero" es la estrategia que más fracasa: subestima la complejidad oculta del sistema actual.

Las cinco estrategias (de menor a mayor cambio)

1. Encapsular y dejar quieto

El sistema legacy sigue funcionando como está. Lo único que se hace es ponerle una capa de APIs por encima para que sistemas modernos puedan interactuar con él sin tener que entender su lógica interna.

Conviene: cuando el sistema funciona bien para lo que hace, pero necesitás integrarlo con cosas nuevas. La lógica de negocio no cambia, solo se "moderniza" la forma de hablarle.

Costo típico: USD 20.000 a USD 80.000 según complejidad de las APIs nuevas. Riesgo: muy bajo. No se toca el core.

Caso real: empresa con un sistema de gestión en VB6 que funciona bien. Necesitaban exponer datos a una app móvil nueva para vendedores. En vez de migrar el sistema, le pusimos una API REST por encima (un servicio .NET Core que consultaba la base SQL Server del legacy). 9 semanas, USD 35.000. El sistema viejo sigue corriendo y la app nueva funciona sin tocar el legacy.

2. Refactorizar in-place

Modernizar partes del sistema sin tirarlo abajo. Actualizar dependencias, mejorar performance crítica, agregar tests, sustituir librerías deprecadas, modernizar la UI manteniendo el backend.

Conviene: cuando el sistema en general anda bien pero tiene problemas puntuales (lentitud, código frágil en áreas críticas, UI horrible, dependencia de tecnologías obsoletas).

Costo típico: USD 40.000 a USD 200.000 según alcance. Riesgo: medio. Cada refactor puede romper algo si no hay tests, pero el cambio es incremental y reversible.

Caso real: sistema PHP 5.6 con Symfony 2 (sin soporte). Lo migramos a PHP 8.2 con Symfony 6 manteniendo la estructura general. 16 semanas, USD 95.000. Beneficios: parches de seguridad al día, performance 3x mejor, equipo de developers que existe en el mercado.

3. Strangler Fig (estrangulación gradual)

El patrón inventado por Martin Fowler. Construir un sistema nuevo al lado del legacy. Ir migrando funcionalidades una por una al nuevo sistema. Cuando todas las funciones críticas migraron, apagar el legacy.

Conviene: para sistemas grandes con muchas funcionalidades, donde un big-bang sería suicida. Permite migrar con riesgo controlado y volver atrás si algo falla.

Costo típico: USD 150.000 a USD 800.000 según tamaño del sistema. Riesgo: bajo si se hace bien, pero requiere disciplina. Tiempo: 12-36 meses típicos.

Caso real: ERP custom de una empresa industrial con 300 usuarios. Tenía 14 años, ~600.000 líneas de código, lógica compleja de costeo y producción. La estrategia: construir un sistema nuevo en .NET Core + React, y migrar de a un módulo por trimestre. Primero el módulo de RRHH (más aislado), después facturación, después órdenes de compra, etc. Cada módulo migrado dejaba de usar el legacy y empezaba a usar el nuevo. 28 meses, USD 480.000. Cero downtime durante la migración.

4. Rebuild parcial (replatform de áreas críticas)

Reescribir las partes del sistema que más duelen (lo que está más roto, lo que más bloquea evolución, lo que más cuesta mantener), dejando el resto del legacy intacto. A diferencia del strangler, no se planifica migrar todo — se decide explícitamente qué se reemplaza y qué no.

Conviene: cuando el 20% del sistema causa el 80% de los problemas, y el resto está OK.

Costo típico: USD 80.000 a USD 400.000. Riesgo: medio. El sistema queda en estado híbrido, lo que requiere claridad sobre quién es responsable de cada parte.

Caso real: empresa con sistema legacy en Cobol (AS/400) que funcionaba bien para lo administrativo, pero la atención al cliente era una pesadilla (terminal verde, sin búsqueda, lento). Solución: dejar el AS/400 para todo lo administrativo y construir un CRM web moderno que se conecta al AS/400 vía middleware. 18 semanas, USD 140.000. El equipo de atención dejó de odiar su trabajo y la empresa no tuvo que tocar el core administrativo que ya funciona.

5. Reescribir desde cero (big-bang rewrite)

Tirar el sistema viejo abajo y empezar de cero con un sistema nuevo. La estrategia que parece más limpia y casi siempre es la más cara y la más riesgosa.

Conviene: cuando el sistema actual es tan malo que no se puede salvar (arquitectura fundamentalmente rota, lenguaje sin developers disponibles en el mercado, lógica de negocio que ya no aplica al negocio actual).

NO conviene: en la gran mayoría de los casos. Joel Spolsky escribió hace 20 años que "rewriting a system from scratch" es el peor error estratégico que puede cometer una empresa de software, y sigue siendo cierto.

Costo típico: USD 300.000 a USD 2.000.000+ y 18-48 meses. Riesgo: alto. Sobrecostos del 50-200% son normales. Cancelaciones a mitad de camino, comunes.

Caso real (de los que salieron bien): empresa con sistema en FoxPro abandonado por Microsoft hace 15 años. No había developers de FoxPro en el mercado. La empresa decidió reescribir todo en .NET y SQL Server, manteniendo el modelo de datos pero modernizando la arquitectura. 22 meses, USD 580.000. Funcionó porque la empresa tenía claro qué iba a perder (algunas features marginales) y porque el equipo nuevo trabajó con el equipo viejo durante 8 meses entendiendo la lógica.

Caso real (de los que salieron mal): empresa con sistema en VB6 que decidió migrar a una "arquitectura moderna" sin un análisis riguroso. Presupuesto: USD 250.000, 12 meses. Realidad: USD 600.000 a los 22 meses, y a esa altura el sistema nuevo todavía no podía reemplazar al viejo. La empresa terminó pausando el proyecto, manteniendo el VB6 con parches, y replanteando una estrategia híbrida.

Cómo decidir

Las cinco preguntas para decidir bien

1. ¿La tecnología actual todavía tiene developers en el mercado? Si es un .NET 4.8 o un Java 8, sí — refactor o strangler. Si es Cobol, Delphi 7 o FoxPro, probablemente rewrite o replatform.
2. ¿La lógica de negocio actual sigue siendo correcta? Si el sistema modela bien el negocio actual, refactor. Si el negocio cambió radicalmente, parte del sistema hay que repensar.
3. ¿Cuántos usuarios diarios depende del sistema? 5 usuarios internos, podés hacer big-bang con riesgo controlado. 200 usuarios externos que generan transacciones, strangler o rebuild parcial obligatorio.
4. ¿Cuánto runway financiero tenés? Reescribir un sistema grande son 18-36 meses. Si la empresa no aguanta ese horizonte sin retorno, no es el momento.
5. ¿Quién va a hacer el proyecto? Equipo interno solo, partner externo solo, o mixto. Cada combinación tiene tradeoffs en velocidad, conocimiento del dominio y costo.

Los errores más caros que vemos

1. Subestimar la complejidad oculta

El sistema viejo tiene años de "edge cases" implementados. El cliente X que tiene una regla especial, el reporte que solo necesita gerencia, la integración con el cliente que se hace una vez al mes. Si no relevás todo eso, el sistema nuevo va a salir y se va a romper en los casos que no contemplaste. Mínimo: 4-8 semanas de relevamiento serio antes de empezar a desarrollar.

2. Big-bang con equipo nuevo

Reescribir desde cero con un equipo que no conoce el dominio es la receta del fracaso. El equipo nuevo va a aprender en el camino y eso es lo que duplica los costos. Si vas a rewrite, mantené durante todo el proyecto al menos una persona del equipo legacy involucrada para responder preguntas del dominio.

3. No tener plan de coexistencia

Mientras el sistema nuevo se construye, el viejo sigue corriendo y los usuarios siguen pidiendo cambios. Si no planificás la coexistencia, terminás con dos sistemas evolucionando en paralelo y el delta entre ellos se vuelve imposible de cerrar.

4. No invertir en tests

Modernizar sin tests es modernizar a ciegas. Cada cambio puede romper algo que no sabés. Antes de empezar cualquier estrategia, invertí en tests del comportamiento actual. Aunque sea un set mínimo de tests E2E sobre los flujos críticos. Después, cada refactor o módulo nuevo se valida contra esos tests.

5. No medir progreso ni valor entregado

Los proyectos de modernización pueden volverse "eternos" porque nadie sabe si están en buen camino. Definí milestones cada 6-8 semanas con valor concreto entregado al negocio: "Para fin de Q1 los usuarios pueden facturar desde el sistema nuevo". Si no hay milestones medibles, el proyecto deriva.

El factor humano

Hay un patrón que se repite y que casi nadie habla: la persona que conoce el sistema legacy en profundidad suele estar cerca del retiro o ya muy frustrada. Esa persona tiene en la cabeza el 60-80% del conocimiento crítico del sistema. Si se va antes de que documenten o transfieran ese conocimiento, el proyecto de modernización se vuelve mucho más caro y riesgoso.

Lo que recomendamos siempre: antes de arrancar cualquier estrategia, invertí 4-8 semanas en sentarte con esa persona, grabar reuniones, documentar las reglas no escritas, hacer un mapa del sistema. Esa inversión paga 10x durante el proyecto.

Plan en 6 pasos

1. Diagnóstico honesto del sistema actual. Qué funciona bien, qué duele, qué es irrecuperable. 2-4 semanas.
2. Relevamiento de reglas de negocio. Sentarse con los usuarios y el equipo legacy, documentar todo. 4-8 semanas.
3. Decisión de estrategia. Con los datos del diagnóstico, elegir entre las cinco estrategias. Documentar por qué.
4. Plan con milestones cada 6-8 semanas. Cada milestone entrega valor concreto al negocio.
5. Implementación con disciplina. Tests, code review, demos al negocio cada milestone, ajustar plan según realidad.
6. Cutover planificado. Cuando el sistema nuevo está listo, hay un período de coexistencia donde los dos corren en paralelo. Después, apagado del viejo con plan de rollback en caso de fallas.

Costos y plazos honestos

• Encapsular con APIs: 6-14 semanas, USD 20.000-80.000.
• Refactorizar in-place: 12-32 semanas, USD 40.000-200.000.
• Strangler Fig: 18-36 meses, USD 150.000-800.000.
• Rebuild parcial: 14-28 semanas, USD 80.000-400.000.
• Rewrite completo: 18-48 meses, USD 300.000-2.000.000+. Sobrecosto promedio 50-100% sobre lo planeado.

Después de cualquier modernización, hay un período de estabilización de 3-6 meses donde aparecen los casos límite no contemplados. Presupuestar 15-25% adicional para eso.

En síntesis

Modernizar un sistema legacy es una de las decisiones más caras y más complejas que toma una empresa. La estrategia correcta no es "reescribir todo" — en la mayoría de los casos es alguna combinación de encapsular, refactorizar, strangler o rebuild parcial. Reescribir desde cero es la última opción y solo cuando se justifica con evidencia, runway y tolerancia al riesgo. El factor que más predice el éxito no es la tecnología elegida sino la disciplina del proceso: diagnóstico honesto, relevamiento riguroso, milestones medibles, y respeto por el conocimiento del equipo legacy.

En Pisol acompañamos modernizaciones de sistemas en empresas grandes y medianas: diagnóstico, definición de estrategia, implementación. Si tenés un sistema legacy y estás evaluando qué hacer, contanos qué tecnología es, qué duele, y cuántos usuarios dependen — armamos juntos el análisis antes de proponer arquitectura.