---
title: "Un sistema legacy es código sin dueño"
description: "Un sistema se vuelve legacy cuando nadie responde de él, tenga la edad que tenga. Qué hacer primero y por qué reescribir de cero casi nunca sale a cuenta."
canonical: https://caricalia.com/notas/sistema-legacy-codigo-sin-dueno
last-updated: 2026-09-29
---

# Un sistema legacy es código sin dueño

> La edad del código importa poco. Un sistema es legacy cuando nadie puede explicar por qué está así ni cambiarlo sin miedo.

Publicado: 2026-09-08 · Actualizado: 2026-09-29

Autor: carlos

Temas: legacy, arquitectura

---

## Cómo se moderniza un sistema legacy en una pyme

Un sistema legacy se moderniza por partes y con el sistema en marcha: se consigue
acceso real, se lee por donde duele el negocio, se rodea la parte más cara de
comprobaciones que se ejecutan solas y se sustituye por dentro, una parte cada
vez. Casi nunca se reescribe entero. Las fases, los riesgos y de qué depende el
coste están más abajo; la visión general de este tipo de trabajo, en
[software a medida](/software-a-medida).

## Qué convierte un sistema en legacy

Un sistema es legacy cuando ya no hay nadie que responda de él. La edad del
código apenas cuenta: hay sistemas con muchos años encima que se tocan sin
sobresaltos, y aplicaciones del año pasado que ya da miedo mirar.

La diferencia está en si queda alguien que sepa contestar, delante de un cambio,
por qué el sistema está hecho así y qué se rompe al tocarlo. Y si hay manera de
enterarse de que se ha roto algo sin esperar a que llame un cliente. Cuando esas
respuestas viven solo en la memoria de una persona, el sistema depende de que
esa persona siga disponible.

El síntoma que buscamos es que haya partes que el equipo evita tocar y que esa
decisión no la discuta nadie.

## Las cinco situaciones, contadas desde dentro

**Hay una parte que nadie toca desde hace meses.** Suele ser la que calcula algo
con dinero. El equipo ha aprendido a trabajar alrededor: se añaden funciones
nuevas por fuera, se copian datos a otra tabla, se hace un ajuste manual al
cierre de mes. Cada rodeo añade un sitio más donde el mismo número puede salir
distinto.

**Todo depende de una persona o de un proveedor.** El proveedor contesta, hace el
cambio y factura. El problema aparece el día que quieres pedir presupuesto a
otro: nadie más tiene acceso al servidor, o el repositorio está en la cuenta de
la agencia. Ahí el precio deja de negociarse.

**Alguien de fuera va a mirar por dentro.** Un cliente grande manda su
cuestionario de seguridad, o entra un inversor, o toca una auditoría. Piden
cosas que existen o no existen, sin término medio: quién tiene acceso a qué, qué
se guarda de los usuarios, qué pasa si se pierde la base de datos. Preparar eso
con dos semanas de aviso sale mal.

**Hay muchos más clientes que cuando se hizo.** Ningún proceso se volvió manual por decisión: algo empezó a fallar de vez en cuando y se montó una hoja de cálculo para repasarlo. Con el tiempo esa hoja es parte del sistema y no está documentada en ninguna parte.

**Quien lo escribió ya no está.** El código funciona, hace lo que tiene que
hacer, y nadie sabe por qué toma buena parte de sus decisiones. Cada cambio
empieza por averiguar por qué está así.

## Lo primero: acceso, lectura y reproducir el fallo

El trabajo empieza consiguiendo acceso real, no una demo. Repositorio, base de
datos de un entorno que no sea el de producción, registros de errores, y la
lista de servicios externos con los que habla el sistema. Cuando conseguir eso
cuesta más de una semana, ya sabemos algo del proyecto.

Después se lee, y se lee por donde el negocio duele. Si el problema es la
facturación, se sigue el camino de una factura desde que alguien pulsa el botón
hasta que el cliente la recibe, anotando cada sitio donde el sistema toma una
decisión que nadie ha documentado.

Lo tercero es reproducir el fallo. Mientras un error solo pasa en producción y
de vez en cuando, no se puede arreglar con criterio. Buena parte de las primeras
semanas se va en conseguir que ocurra a voluntad en una máquina que no es la del
cliente. Es también cuando aparecen los errores que nadie había reportado,
porque el equipo había dejado de contarlos.

Operamos [BeeL](/casos/beel), nuestra plataforma de facturación, así que los
fallos raros de un sistema en producción los recibimos nosotros.

## Por qué reescribir de cero casi nunca es la respuesta

El sistema que quieres tirar contiene años de reglas de negocio que nadie
escribió en ningún sitio. La única copia de esas reglas es el código que quieres
borrar.

Mientras se escribe el sistema nuevo, el viejo tiene que seguir funcionando y
recibiendo cambios. Durante meses hay dos sistemas que mantener con el mismo
equipo, y el viejo gana siempre, porque es el que tiene clientes dentro.

A eso se suman las reglas raras, las que se pusieron porque un cliente concreto
lo pidió hace años. Van apareciendo de una en una, cuando alguien se queja de
que el sistema nuevo ha dejado de hacer algo. Y una reescritura no entrega nada
hasta el final, así que a mitad de camino alguien se plantea cancelarla.

La alternativa que usamos: se elige la parte que más duele, se rodea de
comprobaciones que se ejecutan solas, se sustituye por dentro y se entrega. El
sistema sigue en producción todo el tiempo. Si el presupuesto se acaba a mitad,
lo entregado ya está funcionando.

Reescribir de cero tiene sentido cuando lo que el negocio necesita ahora se
parece poco a lo que el sistema hace. Si un [ERP](/glosario/erp) montado para
gestionar almacén tiene que pasar a vender por internet, el problema deja de ser
el código y la conversación es de producto.

## Las fases de una modernización

Cada fase acaba con algo que se puede enseñar y que ya funciona, y cada una tiene
su precio antes de empezar. Así, si el proyecto se para al final de cualquiera,
lo entregado sigue en producción.

| Fase | Qué se hace | Con qué sales |
|---|---|---|
| Leer | Acceso real al código, a un entorno de pruebas y a los registros de errores. Se sigue el camino del dinero y se reproducen los fallos | Un informe con qué se rompe primero, qué cuesta arreglarlo y en qué orden |
| Rodear | Se escriben comprobaciones sobre la parte elegida que describen lo que hace hoy, rarezas incluidas | Una red que avisa si un cambio rompe algo, sin esperar a un cliente |
| Sustituir | Se cambia la parte por dentro, en pasos pequeños que se pueden deshacer | La parte funcionando en producción, con sus comprobaciones |
| Comprobar el relevo | Alguien que no ha visto el proyecto hace un cambio real con solo el repositorio | La prueba de que el sistema ya no depende de quien lo hizo |
| Repetir | Se elige la siguiente parte por lo que cuesta tocarla | Un sistema cada vez más fácil de cambiar, sin haber parado nunca |

La primera fase es el diagnóstico: tres semanas y un informe que es tuyo aunque no
sigas. Las siguientes se cierran por fases, con demostración en vivo del software
funcionando antes de facturar cada hito. Es lo que Martin Fowler describió como
[Strangler Fig](https://martinfowler.com/bliki/StranglerFigApplication.html): un
sistema nuevo que crece alrededor del viejo hasta que el viejo sobra.

## Los riesgos de modernizar, y cómo se controlan

Modernizar tiene riesgos propios. Nombrarlos antes es lo que permite controlarlos.

| Riesgo | Cómo aparece | Cómo se controla |
|---|---|---|
| Perder reglas que nadie escribió | Después del cambio, el sistema deja de hacer algo y un cliente lo nota | Antes de tocar una parte se escriben comprobaciones que describen lo que hace hoy |
| Parar el negocio | Un despliegue que falla y no se puede deshacer | Pasos pequeños que se pueden deshacer, y el fallo se provoca delante de ti en la demostración |
| Migrar datos mal | Cifras que dejan de cuadrar, históricos incompletos | Se comparan los resultados del sistema viejo y del nuevo con los mismos datos antes de cambiar |
| Depender de una persona durante el proceso | Quien lleva la modernización es la única que entiende el estado intermedio | Decisiones escritas junto al código y la prueba de relevo en cada fase |
| Que el alcance crezca | Cada semana aparece una parte más que «ya que estamos» | Precio y alcance cerrados por fase, y lo nuevo entra en la siguiente |
| Rehacer lo que no hacía falta | Se moderniza una parte que nadie toca | Se elige por lo que cuesta cada cambio, no por lo antigua que sea |

Cuando pasa dinero por la parte que se cambia, se añade una condición: una
operación que falla a medias se deshace entera o se completa entera, y el fallo
se provoca delante de ti.

## De qué depende lo que cuesta modernizar un sistema legacy

Sin euros, porque los euros dependen del sistema. Lo que sí se puede decir es qué
factores suben o bajan el coste, por orden de peso.

| Factor | Sube el coste | Baja el coste |
|---|---|---|
| Documentación | Nadie sabe por qué está así | Hay decisiones escritas y reglas convertidas en pruebas |
| Comprobaciones automáticas | No hay ninguna: cada cambio se prueba a mano | Hay pruebas que se ejecutan solas |
| Integraciones | Hay sistemas de terceros con contratos sin escribir | Todo vive dentro del propio sistema |
| Dinero y normas | Un fallo incumple una norma o para la operación | Un fallo se corrige a mano ese día |
| Datos históricos | Hay que migrarlos y cuadran mal | Se arranca con datos nuevos |
| Personas | Quien lo escribió no está | Quien lo escribió está y contesta |
| Alcance | Se define sobre la marcha | Se define en un diagnóstico previo |

Lo más caro suele ser lo primero: averiguar qué hace el sistema. Por eso una parte
importante del presupuesto se va en la fase de leer, y por eso separamos y
cobramos el diagnóstico. Los rangos de precio que hay publicados en España, con su
fuente y sus límites, están en
[cuánto cuesta desarrollar una aplicación](/notas/cuanto-cuesta-desarrollar-una-aplicacion).

## Cuándo no modernizar

A veces la respuesta correcta es no tocarlo:

- **Si el sistema se va a retirar pronto.** Un año de vida restante no justifica
  una modernización.
- **Si lo que duele es una parte pequeña.** Se arregla esa parte, sin más.
- **Si nadie lo usa ya.** Se apaga.
- **Si el negocio ha cambiado tanto que el sistema ya no se le parece.** Entonces la
  conversación es de producto, y a veces la salida es reescribir; los criterios
  están en [reescribir o refactorizar](/notas/reescribir-o-refactorizar).

Poner un número a esto antes de decidir es lo que hace el diagnóstico, y si sale que
este año no toca, sale escrito.

## Qué puede hacer tu equipo antes de empezar

Sin necesidad de ayuda externa, tres cosas bajan el coste de cualquier
modernización. Pasar los accesos a nombre de la empresa, con una lista de quién
tiene cuáles. Anotar los fallos que el equipo ha dejado de contar, porque ahí
están las partes que duelen. Y escribir el nombre de la persona que responde de
cada parte del sistema. Si esa persona es una sola, está tratado en
[software que depende de una sola persona](/notas/software-depende-de-una-persona), y
si el sistema lo llevó un proveedor,
en [cambiar de proveedor de software sin perder el sistema](/notas/cambiar-de-proveedor-de-software).

## Cómo se recupera un dueño

Un sistema deja de ser legacy cuando alguien que no lo ha escrito puede
cambiarlo. Esa es la prueba, y se puede hacer en directo.

Nuestra cuarta condición de entrega dice justo eso y va en el contrato. Antes de
cerrar, una persona que no ha visto nunca el proyecto hace un cambio real que
elige el cliente, con el repositorio y nada más. Tiene que poder encontrar la
decisión que explica por qué está así, hacer el cambio sin preguntarle a nadie y
saber por las pruebas si ha roto algo. Si no sale, falta documentación y se
escribe antes de facturar el último hito.

Eso cambia qué se entiende por documentación. Sirve lo que permite a un extraño
hacer un cambio concreto: las decisiones escritas junto al código, con su fecha
y lo que se descartó, y las reglas de negocio convertidas en comprobaciones que
se ejecutan en cada cambio y se leen sin ser programador.

Al equipo del cliente le sirve el mismo día que se va el proveedor, y le sirve
con la herramienta que use cada uno para programar. Lo que un modelo necesita
para tocar un sistema sin romperlo es lo mismo que necesita una persona nueva:
encontrar el porqué y tener algo que le avise del error.

## Por dónde se empieza

Si al leer las cinco situaciones has reconocido tu sistema en dos o más, lo que
falta antes de decidir nada es un número: cuánto cuesta arreglarlo, qué se rompe
primero, y qué pasa si no se hace este año.

Para eso existe [el diagnóstico](/diagnostico). Si sale pequeño, lo decimos y no
hay proyecto.

## Preguntas frecuentes

### ¿Qué es un sistema legacy?

Un sistema en producción del que ya no responde nadie: no hay quien explique por
qué está hecho así ni quien pueda cambiarlo sin miedo. No depende de la edad del
código. Hay sistemas con muchos años que se tocan sin sobresaltos y aplicaciones
del año pasado que ya nadie se atreve a mirar.

### ¿Cómo se moderniza un sistema legacy sin parar la empresa?

Por partes y con el sistema en marcha. Se elige la parte que más cuesta tocar, se
rodea de comprobaciones que se ejecutan solas, se sustituye por dentro y se
entrega. Después se elige la siguiente. Si el proyecto se para a mitad, lo
entregado ya está funcionando.

### ¿Cuánto cuesta modernizar un sistema legacy?

Depende de factores que se pueden nombrar: si hay documentación, si hay
comprobaciones automáticas, cuántas integraciones tiene, si pasa dinero por él,
si hay datos históricos que migrar y si queda alguien que lo escribió. No hay una
cifra pública fiable, y por eso empezamos con un diagnóstico que pone un número a
tu caso. Las referencias de mercado publicadas están en la nota de coste.

### ¿Es mejor reescribirlo desde cero?

Casi nunca. Reescribir tira las reglas de negocio que solo existen en el código y
no entrega nada hasta el final. Tiene sentido cuando el negocio ha cambiado tanto
que el sistema ya no se le parece, o cuando es pequeño y puede pararse.

### ¿Cuánto tarda una modernización?

Depende del tamaño y de cuántas partes haya que sustituir. El diagnóstico previo
dura tres semanas y cada fase posterior tiene su plazo y su precio por escrito
antes de empezar, así que el plazo total se va cerrando con lo que ya se ha
aprendido.

### ¿Qué pasa si quien lo escribió ya no está?

Es la situación más común. Se empieza por conseguir acceso real y por reproducir
los fallos fuera de producción. La documentación que falta se escribe leyendo el
código, y se comprueba con una prueba de relevo: alguien que no lo ha visto hace
un cambio real con solo el repositorio.