La empresa hereda un proyecto de software: tras una adquisición, después de un cambio de equipo técnico, al asumir el mantenimiento de algo construido por un proveedor externo. Lo abre y descubre lo habitual: código sin tests, arquitectura confusa, librerías obsoletas, decisiones técnicas que solo tenían sentido cuando se tomaron.
La pregunta inevitable es refactorizar o reescribir. La respuesta común suele estar equivocada en una dirección u otra: o se intenta refactorizar lo irrefactorizable, o se reescribe lo que se podría haber arreglado.
Este artículo da los criterios para decidir bien sin sesgos.
Qué es deuda técnica y por qué importa
Deuda técnica es el coste de mantener código que se construyó tomando atajos. Cada atajo ahorra tiempo en el momento y cuesta más después. Como toda deuda, acumula intereses: cada nuevo cambio sobre código endeudado introduce más deuda si no se sanea.
Hay dos tipos de deuda relevantes para decidir.
Deuda técnica recuperable. Código mal organizado, naming inconsistente, falta de tests, librerías ligeramente desactualizadas, documentación pobre. Mal pero arreglable con esfuerzo proporcional.
Deuda técnica estructural. Arquitectura fundamental incorrecta para la escala actual, decisiones tecnológicas obsoletas sin soporte, código tan acoplado que cambiar una parte rompe diez. Arreglar costaría más que reescribir.
Refactorizar tiene sentido para la primera. Reescribir tiene sentido para la segunda. Confundirlas es lo que cuesta caro.
Los 6 criterios para refactorizar
Si la mayoría de estos se cumplen, el refactor es la opción correcta.
Criterio 1 — La arquitectura fundamental encaja con la necesidad actual. Monolito vs microservicios, base de datos relacional vs NoSQL, frontend SPA vs server-rendered: si la decisión fundamental sigue siendo la correcta para el caso, la deuda es de capa superior y se puede sanear sin tocar fundamentos.
Criterio 2 — Las tecnologías base siguen activamente mantenidas. El framework, el lenguaje, las librerías core no están descontinuados ni en final de vida. Actualizar versiones es viable.
Criterio 3 — Hay tests, aunque sean parciales. Si existe suite de tests aunque cubra solo el 30%, refactorizar es razonablemente seguro. Sin ningún test, cada cambio es ciego y refactorizar se vuelve apuesta.
Criterio 4 — El equipo que va a refactorizar conoce el dominio. El refactor depende de entender qué hace el código y por qué. Un equipo nuevo en el dominio refactoriza mal.
Criterio 5 — El cambio organizativo es bajo. El refactor es invisible para el usuario final; mismo software, mejor por dentro. Si no hay presión por entregar funcionalidad nueva mientras se refactoriza, encaja.
Criterio 6 — El coste estimado del refactor es menor que el 50-60% del coste de reescribir. Estimación honesta con margen para sorpresas técnicas que aparezcan al avanzar.
Los 6 criterios para reescribir
Si la mayoría de estos se cumplen, reescribir es la opción correcta.
Criterio 1 — La arquitectura fundamental ya no encaja. Monolito que no soporta el volumen actual, stack que no permite las features que se necesitan, base de datos diseñada para un uso completamente distinto al actual.
Criterio 2 — Tecnologías obsoletas o sin soporte. Frameworks descontinuados, lenguajes en declive, librerías sin mantenimiento. Cada año aumenta el riesgo de seguridad y la dificultad de contratar talento.
Criterio 3 — Cero o casi cero documentación, sin tests, sin convención. El equipo que hereda no puede entender qué hace el código sin reverse-engineering completo. El reverse-engineering cuesta lo mismo que reescribir bien.
Criterio 4 — La empresa quiere aprovechar para introducir capacidades nuevas que el código actual no soporta. Si la necesidad es modernizar + extender, reescribir permite hacer ambas simultáneamente.
Criterio 5 — Equipo nuevo sin transferencia del original. Sin acceso a quien construyó, refactorizar exige aprender por ósmosis. Reescribir con claridad de qué se quiere lograr es más eficiente.
Criterio 6 — El coste estimado del refactor supera el 70% del coste de reescribir. Cuando la cuenta se acerca a «es igual de caro arreglar que rehacer», rehacer es mejor decisión (queda código limpio en vez de código parcheado).
El caso intermedio: refactor por bloques con reescritura selectiva
Muchas situaciones no encajan claramente en ninguno de los dos extremos. Para estas, la estrategia óptima es híbrida.
Mantener la arquitectura general y el stack principal. Refactorizar los módulos donde la deuda es recuperable. Reescribir los módulos donde la deuda es estructural. Hacerlo por fases, cada una con valor entregable y sin romper la operación.
Este enfoque es habitualmente el más caro a corto plazo (un poco más que el refactor puro) y el más barato a 3 años porque mantiene continuidad operativa mientras moderniza progresivamente.
El error del «Big Rewrite» sin planificación
Joel Spolsky escribió en 2000 un artículo famoso («Things You Should Never Do, Part I») argumentando que reescribir un producto desde cero es habitualmente el peor error que una empresa de software puede cometer. El argumento sigue siendo válido en 2026 con matices: reescribir sin planificación de transición, con todo el equipo enfocado en el rewrite y sin entregar valor durante 12-18 meses, es receta de fracaso.
Reescribir bien implica: equipo dividido (un grupo mantiene el legacy, otro construye lo nuevo), entrega incremental por módulos (no big-bang final), fecha de corte clara en el tiempo, plan de migración de datos sólido. Sin estos elementos, las reescrituras grandes superan el plazo 2-3x y muchas se cancelan antes de terminar.
Coste y plazo orientativos
Para un proyecto B2B mid-market con deuda técnica media:
- Refactor por bloques: 30-60% del coste original del proyecto. Plazo: 16-32 semanas en fases sin interrumpir la operación.
- Reescritura completa: 100-150% del coste original. Plazo: 6-12 meses con equipo dedicado.
- Híbrido (refactor + reescritura selectiva): 60-90% del coste original. Plazo: 6-10 meses.
Estas cifras requieren una auditoría técnica previa que las confirme. Sin auditoría, son estimaciones genéricas.
Cómo se decide bien
Una semana de auditoría técnica profunda con dos seniors técnicos cruza los 6+6 criterios anteriores y devuelve una recomendación con argumentación cuantitativa. Sin esa auditoría, la decisión refactor vs reescribir suele tomarse por preferencia del nuevo equipo (más cómodo con reescribir lo que no construyó, o ahorrando esfuerzo refactorizando malamente).
En Nexus, un rescate de proyecto arranca siempre con esta auditoría como fase 1: recibes un diagnóstico técnico con una recomendación honesta antes de cualquier compromiso de implementación.
Preguntas frecuentes
¿Qué es la deuda técnica en un proyecto heredado?
Es el coste de mantener código construido con atajos: cada atajo ahorra tiempo en el momento y cuesta más después, y acumula intereses porque cada cambio sobre código endeudado puede añadir más deuda. Este análisis distingue la deuda recuperable, arreglable con esfuerzo proporcional, de la estructural, donde arreglar cuesta más que reescribir.
¿Cuándo conviene refactorizar un software heredado en lugar de reescribirlo?
Conviene cuando la arquitectura fundamental sigue encajando, las tecnologías base están activamente mantenidas, existen tests aunque sean parciales, el equipo conoce el dominio y el cambio organizativo es bajo. También cuando el coste estimado del refactor es menor que el 50-60% del coste de reescribir.
¿Cuándo es mejor reescribir un proyecto desde cero?
Es mejor cuando la arquitectura ya no encaja, las tecnologías están obsoletas o sin soporte, no hay documentación ni tests, se quieren introducir capacidades nuevas o el equipo no recibe transferencia del original. También cuando el coste del refactor supera el 70% del coste de reescribir.
¿Cuánto cuesta y cuánto tarda refactorizar o reescribir un proyecto?
Para un proyecto B2B mid-market con deuda media, el refactor por bloques cuesta el 30-60% del proyecto original y tarda 16-32 semanas. La reescritura completa cuesta el 100-150% y tarda 6-12 meses. El híbrido cuesta el 60-90% y tarda 6-10 meses. Son cifras orientativas que requieren una auditoría técnica previa.
Sigue leyendo
- Cómo Evaluar la Viabilidad Real de un Proyecto IA que Lleva Meses Sin Avanzar
- Heredar un stack técnico tras una M&A: guía de supervivencia para el nuevo CTO
- Migración Inacabada de ERP/CRM: Cómo Retomarla Sin Romper el Negocio Mientras Opera
- Guía de rescate de proyectos
- Rescate de proyectos parados
- Software a medida con IA