---
title: "Reescribir o refactorizar: cómo decidir"
description: "Reescribir o refactorizar un sistema en producción: ocho criterios en una tabla, qué cuesta cada camino y la tercera vía, sustituir por partes."
canonical: https://caricalia.com/notas/reescribir-o-refactorizar
last-updated: 2026-09-29
---

# Reescribir o refactorizar: cómo decidir

> Casi siempre se refactoriza por partes y se reescribe solo cuando el negocio ya no se parece al sistema. Ocho criterios para decidirlo con el sistema en marcha.

Publicado: 2026-09-29

Autor: carlos

Temas: legacy, arquitectura, decisión

---

## Reescribir o refactorizar: cómo decidir

Refactoriza cuando el sistema todavía hace lo que tu negocio necesita y el problema
es que cambiarlo cuesta demasiado: se mejora por partes, con el sistema en
marcha. Reescribe solo cuando lo que el negocio necesita ya no se parece a lo que
el sistema hace, o cuando el sistema es pequeño y puede pararse. Para decidir,
mira ocho criterios y el estado de tus pruebas, no la edad del código.

Esta decisión aparece siempre que un sistema en producción se ha vuelto caro de
tocar, y es central en el trabajo de [software a medida](/software-a-medida) sobre
sistemas que ya tienen clientes dentro. Aquí va la tabla, lo que cuesta cada
camino y una tercera vía que suele ser la buena.

## Qué significa cada palabra

**Refactorizar** es cambiar cómo está hecho el código por dentro sin cambiar lo
que hace por fuera. Se hace en pasos pequeños, cada uno comprobado, y el sistema
sigue en producción todo el tiempo.

**Reescribir** es construir un sistema nuevo que sustituya al viejo. Mientras se
construye, el viejo tiene que seguir funcionando, y el nuevo no entrega nada
hasta que está entero.

Entre las dos hay una tercera opción, que es la que solemos usar: sustituir el
sistema por partes, de modo que el nuevo va creciendo alrededor del viejo hasta
que el viejo sobra. Martin Fowler la describió con el nombre de
[Strangler Fig](https://martinfowler.com/bliki/StranglerFigApplication.html), una
aproximación gradual a la modernización de sistemas heredados.

## La tabla de criterios

Marca cada fila con lo que ocurre en tu sistema. Si la mayoría cae en la columna
de refactorizar, refactoriza. Si cae en la de reescribir, se puede plantear, pero
antes lee la sección siguiente.

| Criterio | Apunta a refactorizar | Apunta a reescribir |
|---|---|---|
| ¿Hace lo que el negocio necesita hoy? | Sí, y el problema es cambiarlo | No: el negocio ha cambiado y el sistema no se parece a lo que hace falta |
| Dónde está el dolor | En partes concretas, que se conocen | En todas partes, sin un foco |
| ¿Se puede comprobar que no se rompe algo? | Se pueden añadir comprobaciones alrededor de cada parte | Es imposible aislar una parte para probarla |
| Dónde están las reglas de negocio | Solo en el código: es la única copia, y hay que conservarla | Escritas y probadas aparte: se pueden llevar a un sistema nuevo |
| ¿Puede parar el negocio? | No: hay clientes usándolo cada día | Sí: es una herramienta interna con pocos usuarios |
| ¿Se puede mantener la tecnología? | Todavía hay soporte y gente que la conoce | Sin soporte, sin actualizaciones de seguridad y sin nadie que la conozca |
| Tamaño | Grande: una reescritura tardaría años | Pequeño: se reconstruye en unas semanas |
| ¿Pasa dinero por aquí? | Sí: cada cambio tiene que poder deshacerse | No: un fallo cuesta repetir una tarea |

Lee la cuarta fila con cuidado. En un sistema con años encima, las reglas que nadie
escribió viven solo en el código, y el código que quieres tirar es la única copia.
En esa situación, una reescritura obliga a redescubrirlas una a una, cuando alguien
se queja de que el sistema nuevo ha dejado de hacer algo.

## Qué cuesta cada camino

Sin euros, porque los euros dependen de tu sistema. Lo que cambia entre caminos es
cuándo llega el primer resultado y quién asume el riesgo.

| | Refactorizar por partes | Reescribir entero |
|---|---|---|
| Cuándo llega el primer resultado | En las primeras fases: cada parte entregada ya funciona | Al final: no entrega nada hasta que está entero |
| Qué pasa con el sistema viejo | Sigue en producción y se sustituye por dentro | Sigue recibiendo cambios mientras se construye el nuevo, con el mismo equipo |
| Si se acaba el presupuesto a mitad | Lo entregado ya está funcionando | Hay dos sistemas a medias |
| Dónde suele estar el sobrecoste | En averiguar qué hace una parte antes de tocarla | En las reglas raras que aparecen tras la puesta en marcha |
| Qué riesgo asume quien paga | Acotado por fase, con precio antes de empezar cada una | Abierto hasta el final |

## Por qué reescribir de cero sale mal tan a menudo

El texto más citado sobre esto es de 2000. Joel Spolsky, en
[Things You Should Never Do, Part I](https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/),
cuenta que Netscape decidió reescribir su navegador desde cero, pasaron tres años
sin una versión nueva mientras su cuota de mercado caía, y lo califica como el
peor error estratégico que puede cometer una empresa de software. Añade dos casos
más, Borland y un intento de Microsoft con Word que se canceló, y la razón de
fondo: el código viejo parece un desastre porque tiene años de correcciones que
nadie recuerda, y tirarlo es tirar esas correcciones.

Que un texto sea antiguo no lo invalida: lo que describe es una decisión, no una
tecnología, y la parte cara sigue siendo la misma, entender qué hace el sistema
viejo.

## Cuándo sí se reescribe

Se reescribe en tres casos, y los tres se reconocen con la tabla:

- **El negocio ha cambiado.** Un sistema montado para gestionar almacén que tiene
  que pasar a vender por internet ya no es un problema de código, es de producto.
- **Es pequeño y puede parar.** Una herramienta interna con pocos usuarios se
  reconstruye en semanas, y la parada es aceptable.
- **La tecnología ya no se puede mantener.** Si no hay soporte, ni actualizaciones
  de seguridad, ni nadie que la conozca, la deuda no se paga refactorizando.

Aun así, incluso en esos casos conviene reescribir por partes y con el viejo
funcionando al lado, y llevarse antes las reglas de negocio convertidas en
comprobaciones.

## Cómo se refactoriza sin romper nada

Refactorizar no es «limpiar el código». Es una secuencia con un orden, y saltarse
el orden es como se rompen sistemas que funcionaban.

1. **Elegir la parte por sus intereses.** No por lo fea que sea, sino por lo que
   cuesta cada vez que alguien la toca o la evita. Un módulo horrible que nadie
   toca puede esperar. Uno mediocre que se toca cada semana no.
2. **Fijar lo que hace hoy.** Antes de cambiar nada, se escriben comprobaciones
   que describen el comportamiento actual, incluidas las rarezas. Si una regla
   extraña existe porque un cliente la pidió hace años, la comprobación la deja
   por escrito. Es la única forma de saber que el cambio no ha roto nada.
3. **Cambiar en pasos pequeños.** Cada paso se comprueba y puede deshacerse. Un
   cambio que no se puede deshacer no es un paso, es una apuesta.
4. **Entregar y medir.** Cada parte terminada se pone en producción y se mira si el
   siguiente cambio en esa zona cuesta menos que antes. Si no baja, se para y se
   revisa el criterio.

Cuando pasa dinero por esa parte, se añade una condición: el fallo se provoca a
propósito, delante de quien paga, en la demostración de cada fase. Lo que nunca
se ha visto fallar no está comprobado.

## Señales de que una reescritura ya se ha torcido

Si has empezado una reescritura, hay tres señales que dicen que conviene parar y
revisar:

- **Hay dos sistemas y el viejo sigue ganando.** Cada cambio urgente entra en el
  viejo, y el nuevo se retrasa. Es lo normal mientras el viejo tenga clientes.
- **Aparecen reglas que nadie recordaba.** Cada vez que un cliente se queja de que
  el nuevo ha dejado de hacer algo, se añade una regla al nuevo. Si pasa cada
  semana, el nuevo no se parece todavía a lo que hace el viejo.
- **No hay nada que enseñar en producción.** Una reescritura sin entregas
  parciales es una promesa que se juzga al final, y a mitad de camino alguien
  se plantea cancelarla.

Lo que se puede hacer es partirla: elegir la parte más terminada, llevarla a
producción y decidir con ese dato si se sigue.

## La tercera vía: sustituir por partes

Es lo que hacemos en la mayoría de los sistemas en producción. Se elige la parte
que más duele, se rodea de comprobaciones que se ejecutan solas, se sustituye por
dentro y se entrega. Después se elige la siguiente. El sistema sigue en producción
todo el tiempo, y si el presupuesto se acaba a mitad, lo entregado ya funciona.

Fowler usa la metáfora de la [deuda técnica](https://martinfowler.com/bliki/TechnicalDebt.html)
para explicar por qué compensa ir pagándola: lo que no se arregla acumula intereses,
que son el esfuerzo extra de cada cambio posterior. Pagar por partes, empezando por
la que más intereses cobra, es la forma de bajar el coste de cada cambio sin parar
el negocio.

## Tres preguntas para decidir esta semana

1. **¿Qué parte cuesta más cada vez que la tocas?** Empieza por ahí, y solo ahí.
2. **¿Puedes escribir una comprobación que avise si esa parte se rompe?** Si sí,
   refactoriza. Si no, esa es la primera tarea, antes de decidir nada.
3. **¿Qué pasa si no se hace este año?** A veces la respuesta es «nada grave», y
   entonces la decisión es esperar.

Cuando el sistema además depende de una sola persona, conviene resolver antes eso:
está en [software que depende de una sola persona](/notas/software-depende-de-una-persona).
Y cuánto puede costar cada camino, con las fuentes que hay publicadas, en
[cuánto cuesta desarrollar una aplicación](/notas/cuanto-cuesta-desarrollar-una-aplicacion).

## Cuándo ayuda un diagnóstico

Si tu sistema cae a partes iguales en las dos columnas, lo que falta es un número:
qué parte se rompe primero, cuánto cuesta arreglarla y qué pasa si no se hace. Es
lo que entrega un [diagnóstico](/diagnostico), con la recomendación por escrito,
sea reescribir, refactorizar o esperar. Si sale pequeño, decimos que no hay
proyecto. La visión general de cómo abordamos un sistema heredado está en
[un sistema legacy es código sin dueño](/notas/sistema-legacy-codigo-sin-dueno).

## Preguntas frecuentes

### ¿Es mejor reescribir o refactorizar un sistema antiguo?

Casi siempre refactorizar por partes. Reescribir tiene sentido cuando el negocio
ha cambiado y el sistema ya no se le parece, cuando es pequeño y puede pararse, o
cuando la tecnología ya no se puede mantener.

### ¿Cuánto cuesta reescribir un software?

No hay una cifra pública fiable, porque depende de qué hace el sistema viejo,
que es lo que hay que averiguar. Lo que sí se sabe es que una reescritura no
entrega nada hasta el final y que un refactor por partes entrega en cada fase.

### ¿Se puede reescribir sin parar el negocio?

Sí, si se hace por partes y con el sistema viejo funcionando al lado: se sustituye
una parte, se comprueba y se pasa a la siguiente. Una reescritura completa en
paralelo obliga a mantener dos sistemas con el mismo equipo.

### ¿Qué es la deuda técnica?

Una metáfora de Ward Cunningham, explicada por Martin Fowler: las decisiones de
diseño que facilitan hoy entregar algo rápido cobran intereses después, en forma de
esfuerzo extra en cada cambio. Se paga arreglando la parte que más intereses cobra.

### ¿Qué hago primero si no me atrevo a tocar el sistema?

Escribe una comprobación que avise si se rompe la parte que más duele. Sin eso,
cualquier decisión, sea reescribir o refactorizar, es a ciegas.

Si quieres la recomendación con tu propio código delante, [pide un diagnóstico](/diagnostico).