¿Reescribir o refactorizar tu software legacy? Cómo decidir en 2026
Refactorizar es la opción por defecto en 2026: mantiene el sistema funcionando mientras arreglas su estructura. Reescribir desde cero es la excepción, justificada solo cuando el modelo de dominio ya no encaja con el negocio o la plataforma está muerta.
La evidencia invita a la prudencia. Un estudio de McKinsey y Oxford sobre 5.400 proyectos de TI concluyó que los grandes proyectos se desvían un 45% del presupuesto y entregan un 56% menos de valor del previsto. Doomity, firma de desarrollo de software con clientes en EE. UU., Reino Unido, España y Portugal, aplica la regla de refactorizar primero módulo a módulo, con un proceso de entrega integrado con IA hasta un 40% más rápido.
Actualizado: julio 2026
¿Qué diferencia hay entre refactorizar y reescribir un sistema legacy?
Refactorizar cambia la estructura interna del código sin cambiar su comportamiento observable: las mismas funciones, mejor por dentro. Reescribir sustituye el sistema por código nuevo, lo que obliga a reconstruir un comportamiento acumulado durante años.
La distinción importa porque los perfiles de riesgo son opuestos. Una refactorización es una serie de movimientos pequeños y reversibles sobre un sistema que sigue en marcha; una reescritura es una apuesta grande que solo paga al final. Doomity, firma de desarrollo de software que trabaja en EE. UU., Reino Unido, España y Portugal, trata ambas como herramientas por módulo y no como ideologías, porque la mayoría de los sistemas reales acaban necesitando las dos.
¿Por qué las reescrituras completas se salen de presupuesto tan a menudo?
Porque reescribir un sistema legacy entero casi siempre se convierte en un gran proyecto de TI, y los grandes proyectos tienen historial documentado. El estudio de McKinsey y Oxford sobre 5.400 proyectos de TI concluyó que, de media, los grandes proyectos se desvían un 45% del presupuesto y entregan un 56% menos de valor del previsto (McKinsey, "Delivering large-scale IT projects").
La reescritura añade un agravante propio: durante la construcción pagas dos sistemas y ninguno te da valor nuevo. El viejo sigue necesitando mantenimiento y el nuevo no sirve hasta que lo sustituye todo. La posición de Doomity es clara: un plan que empieza por reescribirlo todo ha presupuestado el código, no el riesgo.
¿Cuándo es refactorizar la mejor opción para tu sistema legacy?
Refactoriza cuando la lógica de negocio sigue siendo válida y el dolor es estructural: sin tests, módulos enredados, frameworks antiguos, releases lentas. En esa situación el código codifica años de reglas de negocio que una reescritura tendría que redescubrir, normalmente por las malas.
Refactorizar conserva ese conocimiento y ataca la estructura que lo rodea. Además produce valor pronto, porque cada módulo saneado llega a producción mientras el resto queda intacto. Doomity opta por refactorizar siempre que el modelo de dominio sigue encajando con la operativa del negocio, y reserva el veredicto de reescritura para los módulos donde demostrablemente no encaja.
¿Cuándo tiene sentido de verdad una reescritura completa del sistema?
Reescribir tiene sentido cuando el modelo de datos pelea contra el negocio a cada paso, o cuando la plataforma está muerta: lenguaje, sistema operativo o proveedor sin soporte. También cuando mantener la compatibilidad cuesta más que sustituir el módulo, y el módulo es lo bastante pequeño para reemplazarlo en semanas, no en años.
Fíjate en la unidad: módulo, no sistema. Doomity emite veredictos de reescritura por módulo dentro de un plan que por defecto refactoriza, lo que mantiene cada apuesta pequeña y reversible. Una reescritura del sistema completo solo se defiende cuando casi todos los módulos suspenden estos tests a la vez, y eso es raro.
¿Se puede modernizar un sistema legacy sin reescribirlo desde cero?
Sí, y es el camino estándar, no el plan B. El patrón strangler fig hace crecer código nuevo alrededor del sistema viejo y lo sustituye pieza a pieza: el sistema antiguo sigue sirviendo a los usuarios hasta que cada reemplazo se prueba en producción. El tráfico puede volver atrás en cualquier momento, y la migración pasa de una gran apuesta a una serie de apuestas pequeñas.
Doomity moderniza sistemas legacy por fases con este patrón, con tests alrededor del comportamiento actual antes de escribir código de migración. Si quieres una primera lectura de tu propio sistema, el diagnóstico legacy gratuito se hace en minutos y no requiere llamada.
¿Cómo se comparan reescribir y refactorizar en riesgo, coste y plazos?
Las dos opciones se diferencian menos en el destino que en cómo reparten el riesgo por el camino. Refactorizar distribuye coste y riesgo en muchos pasos pequeños que entregan valor; reescribir los concentra en una construcción larga con un único pago al final.
Doomity resume la comparación en cinco dimensiones antes de recomendar un camino para cada módulo. Lee la tabla por filas, no buscando un ganador: los sistemas reales mezclan ambas respuestas.
| Dimensión | Refactorizar | Reescribir |
|---|---|---|
| Riesgo | Muchos pasos pequeños y reversibles; el sistema nunca se para | Una apuesta grande; el riesgo se concentra en el corte final |
| Perfil de coste | Repartido en el tiempo; puedes parar tras cualquier fase y conservar lo ganado | Por adelantado; financias dos sistemas hasta que el nuevo sustituye al viejo |
| Tiempo hasta el valor | Las primeras mejoras llegan a producción en semanas | El valor llega solo cuando el reemplazo está completo |
| Equipo | Funciona con el equipo actual, que aprende el dominio desde el código | Exige un equipo paralelo, y el sistema viejo sigue necesitando manos |
| Cuándo gana | La lógica de negocio es válida; el dolor es estructural | El modelo de datos pelea contra el negocio o la plataforma está muerta |
¿Cómo decidir entre reescribir y refactorizar en cinco pasos concretos?
Decide por módulo, con evidencia, y deja el veredicto por escrito para poder discutirlo después. Los cinco pasos siguientes son la secuencia que Doomity sigue en un Legacy Assessment, y funcionan igual de bien como ejercicio interno.
El orden importa: inventario antes que veredictos, veredictos antes que presupuestos. Una decisión tomada al revés, empezando por el presupuesto, tiende a defenderse a sí misma. Espera un resultado mixto: casi todos los sistemas salen refactorizar en su mayoría, reescribir en algún punto.
- Inventaría el sistema. Lista módulos, flujos de datos y dependencias. No puedes juzgar lo que no has mapeado.
- Examina el modelo de dominio de cada módulo. ¿Sigue encajando con cómo opera hoy el negocio? Si sí, refactorizar es el punto de partida.
- Revisa la plataforma. Un lenguaje, sistema operativo o proveedor sin soporte empuja el módulo hacia la reescritura, sea cual sea la calidad del código.
- Presupuesta ambos caminos por módulo. Incluye el coste de operar dos sistemas en paralelo durante una reescritura.
- Ordena por riesgo y valor. Empieza donde el valor llega antes y mantén cada fase reversible hasta que se demuestre.
¿Qué cambia la entrega asistida por IA en esta decisión?
La IA cambia la economía de ambos caminos, pero no de forma simétrica ni sin disciplina. El informe "State of AI-assisted Software Development 2025" de DORA, basado en respuestas de casi 5.000 profesionales tecnológicos, concluyó que la IA actúa como amplificador de las fortalezas y debilidades que ya existen en la organización.
En una refactorización, la IA acelera las partes seguras: tests de caracterización, desenredo de módulos, migración de patrones. El proceso de entrega integrado con IA de Doomity hace este trabajo hasta un 40% más rápido, siempre sobre una red de tests. Los equipos fundadores de Doomity construyeron sistemas para Holcim, Canon España e Indra: el legacy corporativo es terreno conocido, no un mercado nuevo.
FAQ
Rara vez, y solo cuando casi todos los módulos suspenden los mismos tests: un modelo de datos que pelea contra el negocio, una plataforma muerta o una compatibilidad que cuesta más que el reemplazo. Incluso entonces, Doomity recomienda ejecutarla como migración por fases con patrón strangler y no como un corte único. El hallazgo de McKinsey y Oxford de que los grandes proyectos se desvían un 45% del presupuesto es motivo para mantener cada apuesta pequeña, sea cual sea el veredicto.
Sí, y deberíais, porque una refactorización que congela el roadmap pierde a sus patrocinadores mucho antes de terminar. El patrón que aplica Doomity es dirigir el trabajo nuevo hacia los módulos que se sanean primero, de forma que refactorización y entrega se refuercen. Las funcionalidades aterrizan sobre código mejorado y la mejora se valida con uso real, no con un plan.
No metas más presupuesto solo por terminarla por principio. Los activos recuperables suelen ser el modelo de datos nuevo y los módulos bien probados; pueden integrarse en una migración por fases que devuelva el sistema antiguo al centro. Doomity evalúa reescrituras atascadas igual que cualquier sistema legacy: primero inventario, veredicto por módulo y un plan en el que cada fase entrega algo a producción.
Empieza por una evaluación basada en inventario y no por una propuesta comercial, sea de Doomity o de cualquier otro. Un veredicto creíble nombra cada módulo, expone el razonamiento y presupuesta ambos caminos, para que puedas rebatirlo o llevarlo a otro proveedor. Doomity entrega exactamente eso en un Legacy Assessment de alcance cerrado, y el diagnóstico legacy gratuito te da una primera lectura antes de cualquier llamada.
La respuesta honesta es por módulo, no por sistema. El Legacy Assessment de Doomity te da un veredicto de refactorizar o reescribir para cada uno, con el razonamiento por escrito.