Por qué fracasan las migraciones: duplicar el pasado y llamarlo modernización

Las migraciones rara vez fracasan por la tecnología. Fracasan por un mandato contradictorio: duplicar el sistema viejo exactamente y, al mismo tiempo, no repetir sus errores. No se pueden hacer las dos cosas. Copiar el sistema tal cual también copia sus defectos, ahora sobre una plataforma nueva y con el presupuesto agotado.

¿Por qué se bloquea una migración?

Casi toda migración arranca con dos instrucciones que, por separado, suenan sensatas:

1. «Que funcione exactamente igual. No cambien nada.»
2. «Aprovechemos para no arrastrar los errores del pasado.»

Juntas se anulan. La paridad exacta con el sistema viejo es, por definición, la conservación de sus defectos. El lift and shift traslada la deuda técnica intacta: los mismos supuestos, los mismos cuellos de botella, los mismos parches.

El proyecto no muere por la plataforma nueva. Muere por la contradicción.

¿Por qué cuesta tanto soltar el código viejo?

Debajo del mandato hay algo más honesto: el código viejo es un monumento. Ese módulo costó ocho meses. Lleva el criterio de personas que ya no están. Resolvió incendios que hoy nadie recuerda.

La psicología ya lo tiene nombrado: el efecto IKEA (Norton, Mochon y Ariely) —sobrevaloramos lo que construimos con nuestro propio esfuerzo— y el costo hundido —lo defendemos precisamente porque ya invertimos demasiado. Los dos se potencian.

Por eso, cuando alguien sugiere que una herramienta podría reescribir en días lo que costó años de trabajo humano, la primera reacción no es curiosidad. Es rechazo. Y no es irracional: si esa sugerencia resulta cierta, obliga a mirar de frente una pregunta incómoda sobre el valor de todo ese tiempo.

Es más cómodo prohibir que se toque cualquier pieza, exigir copia idéntica y —cuando el proyecto se traba— culpar a la migración.

¿No era que nunca hay que reescribir?

Es el mejor argumento en contra, y merece respeto. En el año 2000, Joel Spolsky escribió que tirar el código y empezar de nuevo es el peor error estratégico que puede cometer una empresa de software. Netscape lo hizo y pasó cerca de tres años sin lanzar. Su razón de fondo sigue siendo la mejor descripción del problema:

El código legado se ve feo porque es exhaustivo. Ese condicional extraño está ahí porque un cliente reportó un caso borde hace cinco años. Al tirar el código, se borran las soluciones a problemas que ya nadie recuerda que existen.

Es verdad. Y es exactamente por eso que no se debe reescribir a ciegas.

¿Qué cambió?

El patrón. En 2004, Martin Fowler describió el strangler fig: el sistema nuevo crece al lado del viejo y lo reemplaza pieza por pieza, sin detener el negocio, y cada paso se puede revertir. Las reescrituras big bang que persiguen paridad total suelen fracasar; los reemplazos incrementales suelen funcionar.

El costo de reescribir. En 2025, Google publicó cómo usa LLMs en sus migraciones internas (ICSE 2025): cerca de 50% menos tiempo total, con alrededor del 74% de los cambios de código generados por el modelo, y migraciones que llevaban años trabadas completadas con un puñado de ingenieros. El mismo estudio trae la advertencia que le da credibilidad: un LLM con prompts simples no alcanza.

El activo nunca fue el código

Spolsky nunca defendió el código. Defendió lo que el código recuerda.

En el año 2000, el código era el único lugar donde ese conocimiento vivía. Hoy no lo es. Un modelo puede leer el sistema viejo y extraer ese saber —los casos borde, las reglas que nunca se documentaron— y convertirlo en pruebas y criterios explícitos.

El activo nunca fue el código. Era el conocimiento. Una migración que conserva el código pero pierde el conocimiento ya fracasó. Una que conserva el conocimiento y descarta el código, funcionó.

Los años de trabajo humano no se pierden: se cobran. Quedan convertidos en reglas y en pruebas que el sistema nuevo tiene que pasar. Eso los honra mucho más que dejarlos congelados en un archivo que nadie se atreve a abrir.

Duplicar el código o preservar el conocimiento

	Migración que duplica el código	Migración que preserva el conocimiento
Qué se copia	La implementación, tal cual	Las reglas, los casos borde, el criterio
Los errores del pasado	Viajan intactos	Se ven, se discuten, se deciden
La paridad	Acto de fe	Pruebas que el sistema nuevo debe pasar
El equipo que lo construyó	Custodia el código	Es la fuente del conocimiento
Desenlace típico	Sobrecosto, y la culpa es de «la migración»	Un sistema nuevo que el negocio entiende

¿Cómo se migra sin un big bang?

1. Extraer el conocimiento antes de tocar nada. Las reglas del sistema viejo: casos borde, excepciones, decisiones. Un LLM es especialmente bueno en esto, a un costo que antes no existía.
2. Convertirlo en pruebas de caracterización. Si el sistema nuevo pasa las pruebas que describen el comportamiento real del viejo, la paridad deja de ser fe y pasa a ser verificación.
3. Reemplazar por partes. El sistema nuevo crece al lado y se corta pieza por pieza. Cada corte, reversible.
4. Que el modelo proponga y un humano decida. Autonomía gradual, con rastro auditable.

La señal de alarma

Cuando en una migración conviven «esto tiene que quedar exactamente igual» y «aprovechemos para arreglar lo que estaba mal», el proyecto ya tiene escrita su causa de fracaso. No lo va a matar la tecnología: lo mata la contradicción. Y después la culpa va a ser de la migración.

Migrar no es mudar código. Es mudar conocimiento. El código viejo fue el vehículo, nunca la carga.

Si tienes un sistema que nadie quiere tocar y una migración que no arranca, escríbenos por WhatsApp. Empezamos siempre por lo mismo: entender qué sabe tu sistema viejo, antes de decidir qué se conserva.