Tu sistema lleva años funcionando y alguien en tu equipo propone reescribirlo. Puede que tenga razón. Antes de decir que sí, haz una pregunta sencilla: ¿alguien sabe con precisión cómo se comporta hoy? Qué devuelve cada operación, qué valida, qué error muestra cuando algo falta. Casi siempre la respuesta es «más o menos». Y «más o menos» es la razón por la que tantas reescrituras terminan con usuarios descubriendo diferencias en producción.
Esta guía sale de una migración concreta: la plataforma de un club de bienestar que vivía en un proveedor externo y se reconstruyó por partes. El caso completo ya está contado. Aquí va la etapa cero con detalle, porque es la que más se salta y la que más errores evita.
Reescribir sin red es migrar a ciegas
Cuando reconstruyes un sistema, el nuevo tiene que hacer lo mismo que el viejo. Suena obvio. El problema es que «lo mismo» no está escrito en ningún lado. Está en el código, en la cabeza de quien lo usa y en años de casos raros que alguien corrigió a mano y ya nadie recuerda.
Si empiezas a escribir el sistema nuevo desde el primer día, las diferencias aparecen tarde y de la peor manera: un cliente que no puede completar una venta, un reporte que da otro total, una validación que antes existía y ahora no. Cada una se investiga por separado y en cada una hay que decidir si es un error nuevo, un error viejo o un cambio que alguien pidió. Sin una referencia, esa discusión no tiene fin.
Congelar el comportamiento resuelve eso antes de que empiece. Escribes pruebas que describen lo que el sistema hace hoy, tal cual, sin juzgar si está bien. Después, el sistema nuevo tiene que pasar esas mismas pruebas. Cuando las pasa, está listo. Cuando no, sabes exactamente qué cambió.
Qué se congela
Tres capas, en este orden:
| Capa | Qué capturas | Qué te da |
|---|---|---|
| Operaciones del sistema | Para cada llamada: qué entra, qué sale, con qué código de estado y qué mensaje de error | El contrato que el sistema nuevo tiene que cumplir |
| Validaciones y errores | Los casos donde el sistema rechaza algo: campo vacío, formato inválido, permiso insuficiente | Las reglas de negocio que nadie documentó |
| Recorridos de interfaz | Un recorrido automatizado por las pantallas principales: entrar, buscar, crear, guardar | La prueba de que el conjunto sigue funcionando para una persona |
La primera capa es la más valiosa y la más mecánica. En el caso del club, quedaron quince instantáneas de petición y respuesta que cubrían clientes, ventas, inventario, cotizaciones y reportes. Cada una guarda la respuesta exacta, con las mismas claves y el mismo orden.
La segunda capa es la que sorprende. Vas a encontrar validaciones que no aparecen en ningún manual: un campo que acepta vacío en una pantalla y no en otra, un error que devuelve texto en vez de código. No las arregles. Cópialas tal cual al contrato. Por incómodas que sean, son el comportamiento con el que tu equipo trabaja hoy, y cambiarlas es una decisión aparte.
La tercera capa es corta. No hace falta automatizar cada pantalla; con los recorridos que la gente hace todos los días alcanza. Su función es distinta a la de las otras dos: detecta cuando una parte funciona en aislamiento y el conjunto no.
Cómo se hace, paso a paso
- Corre el sistema actual en un ambiente propio, fuera de producción, con una copia de los datos. Si nunca se hizo, este paso solo ya te dice mucho: cuántas cosas dependen del proveedor, qué configuración nadie tiene escrita, qué servicio externo hace falta.
- Lista las operaciones. Todas, incluidas las que «nadie usa». Si están en el sistema, alguien las va a extrañar.
- Para cada operación, ejecuta y guarda: entrada, salida, código de estado. Después repite con entradas inválidas y guarda también esos errores.
- Graba un recorrido automatizado por las pantallas principales.
- Marca lo que no existe. Si una operación está en la documentación y no en el código, se anota como pendiente y sus pruebas se marcan como falla esperada, para que nadie las confunda con un problema del sistema nuevo.
¿Cuánto toma? Menos de lo que parece. En el club, del primer día de trabajo al contrato completo pasaron pocos días. Lo que más pesó fue el paso uno, porque el sistema nunca había corrido fuera del proveedor.
Regla de la etapa cero: ningún error del sistema viejo se corrige. Se anota con su severidad y se deja para después del cambio.
La regla incómoda
Esa regla es la que más cuesta cumplir. Vas a encontrar errores, algunos serios, y vas a tener el código abierto delante. La tentación de arreglarlos «ya que estamos» es enorme.
No lo hagas. Si corriges a mitad de la migración, cada diferencia entre viejo y nuevo pasa a tener dos explicaciones posibles: una regresión o una corrección. A partir de ahí, cada comparación se vuelve una conversación en lugar de una prueba. Con el comportamiento congelado, la explicación es una sola.
En el caso del club se anotaron dieciséis hallazgos, dos de ellos críticos. Quedaron en una lista con su severidad y se atendieron después del cambio, como mejoras con su propio alcance. Ningún usuario notó la diferencia, porque durante la migración el sistema nuevo se comportó exactamente como el viejo, errores incluidos.
Hay una excepción, y conviene decirla: si un error impide operar o expone datos, se corrige en el sistema viejo y en el nuevo a la vez, y se documenta como cambio intencional. La regla evita mezclar sin querer; no prohíbe decidir.
Lo que aparece cuando auditas
Congelar el comportamiento tiene un efecto secundario que vale por sí solo: te obliga a mirar lo que el sistema dice tener contra lo que tiene.
En el club, un módulo de créditos y referidos que se daba por construido no estaba en el código entregado. La propuesta lo había tratado como trabajo de migración. Era trabajo nuevo. Descubrirlo en la etapa cero cambió el alcance antes de que alguien contara con ese módulo para el lanzamiento. Sus pruebas quedaron marcadas como fallas esperadas, y así siguieron hasta el final: el contrato terminó con sesenta y un pruebas en verde y tres esperadas en rojo, las de ese módulo.
También aparecen las dependencias silenciosas. Un servicio externo que solo funciona con una clave que nadie sabe dónde está. Una tarea nocturna que corre en el servidor del proveedor y no en el código. Cada una se anota, porque el sistema nuevo tiene que reemplazarla o decidir a propósito que no.
El contrato describe el sistema tal como se comporta hoy, con sus errores. Lo que debería hacer se discute después del cambio.
Cuándo se toca el contrato
Un contrato congelado no es intocable para siempre. Hay un momento legítimo para cambiarlo, y conviene reconocerlo para no usarlo de excusa.
Las instantáneas se capturan con datos de prueba. Cuando el sistema nuevo empieza a trabajar con entidades reales persistidas, algunas respuestas cambian de forma sin cambiar de significado: un identificador distinto, una fecha real donde había una fija. En ese caso se regenera la instantánea, se revisa el cambio y se deja escrito por qué. En el club pasó, y quedó documentado como una decisión, no como un ajuste silencioso.
Lo que nunca se hace es «corregir» una prueba porque el sistema nuevo no la pasa. Si la prueba describe el comportamiento viejo y el nuevo hace otra cosa, el que está mal es el nuevo. O es un cambio que alguien pidió, y entonces se anota como tal.
Cómo saber que terminaste
El sistema nuevo está listo cuando pasa el contrato completo, con las fallas esperadas marcadas y ninguna sorpresa. Ahí termina la migración y empieza otra cosa: las correcciones de la lista de hallazgos, el módulo que nunca existió, las mejoras que el negocio venía pidiendo. Cada una con su propio alcance y su propia prueba.
Si tu sistema muestra señales de que llegó a su techo, el orden es este: primero congelar, después cotizar, al final reescribir. Cuándo conviene migrar y cómo hacerlo por etapas está en la guía sobre modernizar un sistema legacy. Y si no sabes por dónde empezar con el tuyo, cuéntanos cómo se comporta hoy; esa primera conversación no necesita código.
Preguntas frecuentes.
¿Qué es una prueba de caracterización?
Una prueba que describe lo que el sistema hace hoy, sin juzgar si está bien. Para cada operación guarda la entrada y la salida observadas, incluidos los errores y las validaciones. Sirve para detectar cualquier cambio de comportamiento cuando el sistema se reescribe.
¿Cuánto tiempo toma congelar el comportamiento de un sistema?
Para un sistema de tamaño mediano, días. En el caso que sirve de base a esta guía, correr el sistema viejo en un ambiente propio, auditarlo y escribir la suite tomó pocos días, con los recorridos de interfaz incluidos. Lo que más pesa es correr el sistema fuera de producción por primera vez.
¿Y si el sistema actual tiene errores evidentes?
Se anotan con su severidad y se dejan para después de la migración. Si los corriges a mitad de camino, ya no puedes distinguir una regresión de un cambio intencional. Con el comportamiento congelado, cada diferencia entre viejo y nuevo tiene una sola explicación posible.
¿Necesito acceso al código del sistema viejo para hacer esto?
Ayuda, pero no es indispensable. Las pruebas capturan el comportamiento desde afuera: llamadas y respuestas, pantallas y clics. Lo que sí necesitas es poder correr una copia del sistema fuera de producción, con datos de prueba.
