Cuándo rehacer software heredado y cuándo evolucionarlo
Legacy · Refactorización · Deuda técnica
«¿Rehacemos todo desde cero o seguimos parcheando?» Es la pregunta que más escucho de empresas con software heredado. La respuesta casi nunca es blanco o negro, pero hay un marco claro para decidirlo. Después de años migrando sistemas legacy, comparto cuándo cada opción tiene sentido.
Cuándo la reescritura total está justificada
La reescritura completa es la opción más cara y más arriesgada. Solo la recomiendo cuando se cumplen varias de estas condiciones simultáneamente:
- El coste de mantener supera al de reconstruir: si cada cambio menor requiere semanas de trabajo y genera efectos secundarios impredecibles, el sistema ha llegado a su límite.
- Bloqueo estructural para nuevas funcionalidades: el negocio necesita evolucionar y la arquitectura actual lo impide. No es que sea difícil, es que es imposible sin cambios fundamentales.
- Tecnología en fin de vida (EOL): el framework, lenguaje o plataforma ya no recibe actualizaciones de seguridad. Cada día que pasa aumenta el riesgo.
- Deuda técnica acumulada insostenible: sin tests, sin documentación, dependencias abandonadas, código que nadie entiende del todo.
- Imposibilidad de contratar: si la tecnología es tan antigua que no encuentras desarrolladores, el sistema tiene fecha de caducidad.
Cuándo la evolución gradual es mejor (la mayoría de casos)
En mi experiencia, más del 70% de los casos se resuelven mejor con evolución progresiva que con reescritura total. Ventajas:
- Sin interrupción de operaciones: el negocio sigue funcionando mientras se moderniza el sistema.
- Riesgo controlado: cada cambio es pequeño, validable y reversible.
- Inversión distribuida: en lugar de un gasto grande y un riesgo grande, inversiones más pequeñas con retorno medible en cada fase.
- Aprendizaje continuo: cada módulo migrado enseña lecciones que mejoran los siguientes.
Enfoque de migración por fases
Este es el proceso que sigo cuando trabajo con software heredado:
Fase 1: Auditoría y mapa de deuda (1-2 semanas)
- Análisis del código existente: complejidad, cobertura de tests, dependencias.
- Mapeo de módulos: cuáles son críticos, cuáles están más deteriorados, cuáles tienen más dependencias.
- Entrevistas con el equipo: qué duele más en el día a día, dónde se pierde más tiempo.
- Entregable: mapa visual de deuda técnica con priorización por impacto de negocio.
Fase 2: Aislar la deuda (2-4 semanas)
- Crear interfaces claras entre módulos para que puedan evolucionar independientemente.
- Añadir tests en los puntos más críticos antes de tocar nada.
- Documentar el comportamiento actual (que muchas veces nadie recuerda por completo).
Fase 3: Refactorizar módulos críticos (4-12 semanas)
- Empezar por los módulos que más dolor causan y más valor de negocio tienen.
- Modernizar tecnología, mejorar rendimiento, añadir tests exhaustivos.
- Cada módulo refactorizado se despliega en producción y se valida antes de pasar al siguiente.
Fase 4: Migración sin parada (ongoing)
- Ir reemplazando componentes del sistema antiguo por los nuevos de forma progresiva.
- Patrón Strangler Fig: el sistema nuevo va «envolviendo» al antiguo hasta que el antiguo desaparece.
- En ningún momento se para la operación del negocio.
Señales de alarma del software heredado
Si reconoces tres o más de estos síntomas, es momento de actuar:
- Cada release genera bugs en partes que no se han tocado.
- Nadie se atreve a refactorizar por miedo a romper algo.
- El onboarding de nuevos desarrolladores tarda más de un mes.
- Hay partes del código que «solo entiende una persona» (y reza para que no se vaya).
- Los despliegues requieren procesos manuales y generan ansiedad.
- Los clientes piden funcionalidades que son técnicamente imposibles con la arquitectura actual.
Consideraciones de presupuesto
- Auditoría técnica completa: 3.000€-6.000€. Es la inversión más rentable porque evita tomar una decisión equivocada de decenas de miles de euros.
- Migración gradual por fases: 15.000€-50.000€ por fase, dependiendo del tamaño del sistema. Típicamente 3-6 fases a lo largo de 6-18 meses.
- Reescritura total: 40.000€-150.000€+ dependiendo de la complejidad. El rango es amplio porque una reescritura implica reconstruir toda la lógica de negocio acumulada durante años.
Mi recomendación es siempre empezar por la auditoría. Con 3.000€-6.000€ de inversión, tienes un diagnóstico claro que te permite presupuestar con precisión y elegir el camino correcto.
Evaluar software heredado Solicitar auditoría técnica
Artículos relacionados
Cuánto cuesta software a medida en 2026 · MVP de software a medida: fases y plazos · Arquitectura backend escalable para SaaS
Deadwood Studio