¿Cuándo significa algo la aceptación de un sistema heredado?

La aceptación no es una reunión, una firma ni una semana tranquila después del lanzamiento. Un sistema reescrito es aceptable cuando el comprador puede demostrar que conserva el comportamiento que necesita el negocio, explica cada diferencia financiera, supera una reversión ensayada y puede operarse sin el equipo de reescritura presente.

La norma parece severa hasta que una reescritura falla. Entonces aparecen juntas las pruebas que faltaban: nadie sabe si un resultado distinto es un defecto corregido o una regresión, los totales difieren unos céntimos entre miles de registros, la página de reversión describe órdenes que nadie ejecutó y los ingenieros receptores descubren una dependencia indocumentada de los autores. La aceptación debe revelar esos hechos mientras el proyecto aún pueda actuar.

La aceptación comienza con un contrato de pruebas

Defina la aceptación antes de implementar, porque el equipo debe saber qué afirmaciones tendrá que probar. Un requisito como «funciona igual que el sistema anterior» no se puede verificar. Sustitúyalo por reglas observables, conjuntos de datos identificados, tolerancias, responsables y pruebas que perduren después de la decisión.

El contrato debe separar cuatro decisiones que suelen mezclarse. La paridad funcional pregunta si una misma solicitud válida produce el mismo resultado de negocio. La conciliación financiera comprueba asientos, saldos, impuestos, redondeos y repartos al nivel exigido por contabilidad. La aceptación operativa comprueba si las personas responsables pueden desplegar, supervisar, restaurar y revertir el sistema. La aceptación de propiedad confirma si podrán cambiarlo con seguridad cuando se marche el equipo de reescritura.

Cada decisión necesita un responsable identificado. Producto u operaciones pueden aprobar cambios de comportamiento deliberados. Finanzas controla tolerancias y firma la conciliación. El propietario del servicio acepta procedimientos y riesgos residuales. Seguridad revisa límites de confianza y accesos modificados. Un comité puede recibir esas decisiones, pero no crearlas promediando opiniones.

Escriba el contrato como una matriz pequeña, no como un documento extenso. Para cada afirmación registre fuente, regla de aprobación, proceso de excepciones, aprobador y ubicación de conservación. «Coincide el 99 %» no es una regla si no explica qué uno por ciento puede diferir. Una discrepancia en un informe regulatorio puede importar más que diez mil diferencias de espacios.

Congele el contrato mediante el control normal de cambios. Un caso límite puede justificar una regla nueva, pero el equipo no debe relajar una tolerancia porque la reescritura la incumple. Registre quién cambió la regla, por qué y qué resultados anteriores quedaron invalidados. De otro modo, la meta se mueve cuando la implementación incomoda.

Defina también el entorno de aceptación: imágenes del sistema operativo, extensiones de base de datos, configuración regional, base de zonas horarias, ajustes del agente de mensajes, indicadores y datos de referencia. Un resultado de un entorno sin identificar no puede reproducirse. «Parecido a producción» no basta. Asigne un identificador e incluya el resumen criptográfico de la configuración en cada paquete.

El rendimiento entra en el contrato cuando el tiempo cambia el resultado empresarial. Especifique carga, concurrencia, volumen, calentamiento y percentiles en el límite real. Un proceso nocturno que entrega cifras correctas después del corte matinal ha fallado. También falla una interacción tan lenta que provoca reintentos y trabajo duplicado. Mantenga rendimiento y paridad funcional separados, pues uno no disculpa al otro.

El contrato necesita un objetivo negativo explícito: la nueva arquitectura no tiene que parecerse a la antigua. Paridad de comportamiento y de implementación son afirmaciones distintas. Reproducir un lote COBOL dentro de un servicio Go puede conservar estructura accidental y dificultar la propiedad. Acepte el comportamiento observable en límites estables y evalúe los componentes internos con criterios actuales.

El tráfico grabado es una prueba, no una suite completa

El tráfico de producción grabado ofrece la mejor muestra de lo que hacen los consumidores, pero solo prueba lo ocurrido durante la ventana de captura. Úselo como corpus de caracterización y añada rutas raras, destructivas, estacionales y legalmente sensibles que no aparecieron.

Michael Feathers presentó en Working Effectively with Legacy Code las pruebas de caracterización como pruebas que describen lo que hace un sistema. La idea encaja porque la implementación antigua suele ser la última especificación precisa. Hay una salvedad: una salida grabada demuestra el comportamiento actual, no que sea correcto.

Capture solicitudes en un límite con significado empresarial. Puede ser una puerta HTTP, un tema de mensajes, entrada por lotes, transacción de terminal, depósito de archivos, procedimiento almacenado o invocación de control de trabajos. Guarde contexto para reproducir enrutamiento, clase de autorización, configuración regional, fecha efectiva y estado funcional. No recoja secretos por estar disponibles. Tokenice cuentas, elimine credenciales y conserve una correspondencia controlada solo si necesita identidad estable.

Cada caso necesita un identificador inmutable y procedencia. Conserve versión del origen, hora, forma de solicitud, instantánea de estado, salidas esperadas y transformación de saneamiento. Calcule la huella de captura original y fixture normalizado. Así un revisor sabe si cambió la prueba o el sistema.

Un sobre útil tiene esta forma:

{
  "case_id": "close-004812",
  "captured_at": "2026-03-31T23:58:14Z",
  "business_date": "2026-03-31",
  "request": {"operation": "post_invoice", "invoice_ref": "TKN-8821"},
  "state_snapshot": "sha256:7d3f...",
  "expected": {
    "status": "posted",
    "ledger_delta_minor": 18425,
    "events": ["invoice.posted"]
  }
}

El fixture guarda dinero en unidades menores porque el punto flotante binario es un mal límite. Nombra el evento, pero no exige idénticos identificador y marca temporal. Esos campos volátiles pertenecen a la política de comparación.

Las muestras tienen puntos ciegos previsibles. Quizá no incluyan cierres mensuales o anuales. Los reintentos pueden ocultar errores. Los administradores hacen correcciones raras en otra interfaz. Puede faltar un día bisiesto, archivo vacío, longitud máxima, mensaje duplicado, anulación, espera agotada tras confirmar o lote parcial. Añada casos de procedimientos, incidentes, soporte y restricciones del esquema. Pregunte a quienes cierran los libros qué entradas les preocupan. Suelen saber dónde miente el código.

La reproducción no debe repetir efectos externos. Envíe correos, pagos, archivos y mensajes a dobles deterministas o extremos aislados. Si una solicitud no puede hacerse inocua, compárela en una ruta sombra sin confirmaciones. Un arnés que puede cobrar a un cliente no es una herramienta de aceptación.

La paridad exige una política explícita

Dos salidas rara vez merecen comparación byte a byte. Defina qué diferencias tienen significado antes de ejecutar el corpus. La política debe normalizar campos volátiles, comparar exactamente los importantes y clasificar cada discrepancia restante.

Empiece por el resultado observable completo: respuesta, cambios en base de datos, mensajes, archivos, registros de auditoría y tiempo visible. Una reescritura puede devolver el mismo JSON y omitir un asiento. Puede escribir las filas correctas y emitir eventos en un orden que rompa un consumidor. Comparar solo la superficie fácil crea confianza falsa.

La normalización debe ser estrecha y revisable. Sustituya identificadores generados solo si la identidad no importa aguas abajo. Reduzca precisión temporal solo si el orden inferior es irrelevante. Ordene colecciones solo si el contrato declara el orden no observable. Nunca elimine un campo porque cambia mucho. Averigüe si alguien depende de él y documente la regla.

El arnés debe producir un resultado legible sin conocer su código:

{
  "case_id": "close-004812",
  "result": "FAIL",
  "comparisons": [
    {"path": "$.status", "expected": "posted", "actual": "posted", "rule": "exact"},
    {"path": "$.ledger_delta_minor", "expected": 18425, "actual": 18424, "rule": "exact"},
    {"path": "$.processed_at", "expected": "<timestamp>", "actual": "<timestamp>", "rule": "normalized"}
  ]
}

Conserve cuatro resultados: aprobado, cambio esperado, defecto conocido y discrepancia sin explicar. «Casi igual» no es un resultado. Un cambio esperado remite a una decisión y prueba aprobadas. Un defecto conocido tiene responsable y tratamiento. Una discrepancia sin explicar bloquea la afirmación.

Mida cobertura por dimensiones empresariales, no por cantidad. Etiquete operación, clase de cuenta o cliente, canal, autorización, moneda, límite de fecha, clase de error y efecto cuando proceda. Informe de intersecciones vacías. Diez mil consultas de factura no compensan cero anulaciones de crédito.

Ejecute ambos sistemas desde un estado inicial controlado. Si comparten estado mutable, la primera ejecución altera la segunda. Restaure una instantánea o use copias aisladas. Congele relojes, semillas, cambios y configuración. Si el sistema antiguo consulta una fuente mutable, capture su respuesta.

No use la nueva implementación para generar sus propios resultados esperados. He visto equipos reproducir tráfico, aprobar visualmente la salida y guardarla como referencia. Eso prueba repetibilidad, no paridad. El oráculo debe ser el sistema antiguo, una regla aprobada de forma independiente o unos libros conciliados.

Concilie el dinero en el límite contable

La aceptación financiera exige igualdad exacta en el límite contable y explicación documentada de cada diferencia deliberada. Los totales agregados no revelan errores compensados, duplicados, fechas incorrectas ni importes correctos en cuentas erróneas.

Compare dinero con la representación de la regla. Si el origen guarda céntimos enteros, compare enteros. Si usa decimales fijos con escalas por moneda, consérvelas. No pase cálculos por hojas que convierten tipos o muestran redondeos mientras guardan otra cifra.

Concilie por capas. Compare recuentos e identificadores únicos. Después compare cada asiento por entidad, cuenta, moneda, fecha, debe o haber e importe. Luego compare totales de control por las dimensiones de Finanzas y, finalmente, saldos e informes. Cada capa detecta otro fallo y reduce la búsqueda.

Una antiunión revela asientos ausentes o extra; una agrupación revela importes distintos. Adapte esta consulta Postgres a la identidad empresarial real:

WITH old_totals AS (
  SELECT entity_id, account_code, currency, effective_date,
         SUM(amount_minor) AS amount_minor, COUNT(*) AS line_count
  FROM old_postings
  GROUP BY entity_id, account_code, currency, effective_date
),
new_totals AS (
  SELECT entity_id, account_code, currency, effective_date,
         SUM(amount_minor) AS amount_minor, COUNT(*) AS line_count
  FROM new_postings
  GROUP BY entity_id, account_code, currency, effective_date
)
SELECT COALESCE(o.entity_id, n.entity_id) AS entity_id,
       COALESCE(o.account_code, n.account_code) AS account_code,
       COALESCE(o.currency, n.currency) AS currency,
       COALESCE(o.effective_date, n.effective_date) AS effective_date,
       o.amount_minor AS old_amount, n.amount_minor AS new_amount,
       o.line_count AS old_lines, n.line_count AS new_lines
FROM old_totals o
FULL OUTER JOIN new_totals n USING (entity_id, account_code, currency, effective_date)
WHERE o.amount_minor IS DISTINCT FROM n.amount_minor
   OR o.line_count IS DISTINCT FROM n.line_count;

La salida debe tener cero filas en dimensiones exactas. Si Finanzas permite tolerancia en un reparto derivado, codifíquela por regla y clase de cuenta. Nunca aplique tolerancia global. Un céntimo en cada uno de un millón de asientos no es poco, y diferencia neta cero puede ocultar pares en cuentas equivocadas.

El redondeo requiere casos propios. Especifique método y momento: mitad arriba, mitad par, truncamiento o regla monetaria. round(sum(x), 2) puede diferir de sum(round(x, 2)). El programa antiguo quizá conserva fracciones y asigna el resto a una línea. La reescritura debe reproducirlo salvo nueva política aprobada.

La prueba debe incluir instantánea de entrada, versión de consulta, recuentos, filas sin pareja, diferencias agrupadas, totales, ejecutor y aprobación. Guarde las excepciones reales, no una captura verde. Finanzas debe rastrear un total hasta los asientos sin pedir reconstruir la ejecución.

La paridad no da ciudadanía a todos los defectos

Un resultado antiguo sorprendente necesita clasificación, no conservación automática. Distinga comportamiento requerido, tolerado, accidental y prohibido, y asocie una decisión a cada desviación.

Lo requerido incluye cálculos contractuales, formatos consumidos, procesos aprobados y controles. Lo tolerado puede ser extraño pero tener usuarios, como aceptar un identificador con espacios iniciales. Lo accidental no tiene consumidor conocido y contradice la regla. Lo prohibido infringe políticas o crea riesgo inaceptable.

Se suele recomendar aprovechar la reescritura para limpiarlo todo. Es popular porque los defectos están visibles y el código parece fácil de cambiar. Es mala estrategia de aceptación. Mezclar cambios funcionales y de plataforma vuelve ambigua cada diferencia y agranda la reversión. Preserve lo requerido, aísle correcciones aprobadas y posponga limpiezas ajenas hasta tener una base operativa estable.

Para cada cambio deliberado conserve el caso anterior, marque su salida, cite al aprobador y añada el resultado nuevo. El informe dirá «cambio esperado» sin fingir aprobación. Los responsables aguas abajo deben aceptar el contrato. Corregir un impuesto sigue siendo incompatible si un importador espera campos antiguos.

Las correcciones de seguridad a veces no pueden esperar. Si el sistema expone datos o admite entradas peligrosas, no lo reproduzca para poner verde el informe. Registre el cambio de control, pruebe rechazo y acceso permitido, y evite que la reversión restaure la exposición sin decisión de riesgo.

La clasificación evita también la transliteración. Se puede conservar comportamiento externo mientras se sustituyen tablas de preparación por colas duraderas, se divide un monolito por responsabilidad o se llevan cálculos a Rust. La aceptación observa contratos y efectos estables, no obliga a copiar estructuras muertas.

El registro de decisiones debe poder leerse. Una fila por diferencia significativa supera a un documento por caso. Incluya casos, conductas anterior y nueva, motivo, aprobador, impacto, tratamiento de reversión y fecha. Cientos de entradas sin explicar no quedan aceptadas por llamarlas «diferencias conocidas».

Un ensayo de reversión debe cambiar estado real

La reversión solo es creíble tras ejecutarla en un despliegue similar a producción, restaurar estado autoritativo y demostrar que el proceso continúa sin pérdida ni duplicación. Leer un manual no prueba permisos, artefactos, relojes, colas ni coordinación.

Elija la unidad antes del lanzamiento: servicio, porción de tráfico, cohorte, familia de procesos o lectura. Defina el último punto seguro y la transición al volver. La pregunta difícil son los datos: tras escrituras nuevas, ¿puede leerlas el sistema antiguo, reproducirlas o hay que parar antes?

La escritura doble se propone como seguro. Puede ayudar, pero añade otro comportamiento: qué ocurre si una escritura funciona y otra falla. Sin orden, reintentos e idempotencia claros, aumenta la ambigüedad. Un diario duradero con reproducción probada suele entenderse mejor que dos confirmaciones que fingen una transacción.

Ensaye con identidades y controles de producción. Debe iniciarlo el ingeniero de guardia, no el autor. Seguridad no debe conceder acceso amplio temporal. Recupere el artefacto fijado del registro real, cambie el enrutamiento, restaure o reproduzca estado y ejecute transacciones de humo.

Un registro útil contiene cinco hechos:

1. Activador y persona autorizada.
2. Identificadores exactos desplegado y restaurado.
3. Última transacción antes y primera después.
4. Conciliación del intervalo.
5. Tiempo de recuperación e intervención manual.

Inyecte una complicación realista: mensaje en vuelo, dependencia lenta, cambio de turno o escritura que deba deshacerse. No es teatro. Prueba el límite donde suelen fallar los manuales ordenados.

Después pruebe más que la salud del extremo. Compare colas, tareas, totales, autorizaciones y confirmaciones. Verifique que no hubo duplicados y que las cachés no sirven datos nuevos a la ruta restaurada. Guarde horas de los sistemas, no un relato posterior.

Si la reversión completa es imposible, llámelo recuperación hacia delante. Defina cómo desactivar la ruta, reparar estado y desplegar la corrección. La aprobación puede ser racional, pero nadie debe firmar una capacidad que el modelo impide.

La entrega prueba propiedad mediante acción independiente

Los ingenieros poseen el sistema cuando pueden explicarlo, operarlo, diagnosticarlo, cambiarlo, desplegarlo y recuperarlo sin ayuda privilegiada. Una carpeta documental es material, no prueba.

El equipo receptor debe ejecutar las tareas. Debe seguir una solicitud por servicio, cola, base y evento; diagnosticar un fallo sembrado; cambiar una regla pequeña y su prueba; compilar, desplegar y revertir; después ensayar recuperación y conciliar transacciones.

Los ejercicios descubren lagunas. Si no explica una normalización, no posee la política. Si solo el proveedor regenera un cliente o rota un secreto, no posee la compilación. Si el despliegue usa una cuenta no inventariada, no posee la operación.

El paquete debe contener artefactos ejecutables:

• Repositorios, archivos de compilación, bloqueos, instrucciones de código generado y propiedad.
• Decisiones, contratos, modelos de datos, supuestos de amenazas y diferencias.
• Manuales exactos de despliegue, reversión, copia, restauración, migración, conciliación e incidentes.
• Paneles, alertas, objetivos, campos de registro y consultas diagnósticas.
• Accesos, rotación de secretos, licencias, límites de soporte y riesgos.

Fije versiones y pruebe una compilación limpia en un entorno del receptor. Archive compiladores y generadores cuando la licencia lo permita. Una compilación que solo funciona en el equipo del autor está incompleta. El equipo debe conocer qué artefactos generados se versionan y cómo recrear los demás.

CodeHero vincula el comportamiento al original con un arnés de paridad sobre tráfico grabado mientras moderniza la arquitectura; ese arnés debe quedarse como suite de regresión del cliente. En entornos regulados, una instalación aislada dentro del perímetro cambia el inventario: modelos, hardware, actualizaciones, accesos y exportación de pruebas necesitan responsables.

La propiedad también tiene lado comercial. Enumere dependencias del equipo: compilación alojada, paquete privado, licencia, credencial, destino de alerta, modelo o aprobación oculta. Elimínela, transfiérala o acéptela. «Llámenos si falla» puede ser soporte, no propiedad técnica.

Termine con una explicación inversa. Los receptores explican arquitectura, riesgos, límite de reversión, excepciones y primeras acciones. Los malentendidos aparecen al enseñar el sistema de vuelta. Registre lagunas con responsables y fechas.

La firma debe ser una decisión reproducible

La firma final identifica versión, pruebas, excepciones, riesgos y decisores. Una persona ausente debe reconstruir por qué se aceptó y repetir controles relevantes.

Cree un índice inmutable con commits, huellas de artefactos, versión del corpus y política, informe de paridad, conciliación, revisión de seguridad, rendimiento, ensayo, entrega, decisiones y riesgos. Fírmelo o calcule su huella y consérvelo según la política.

No deje que un porcentaje decida. Informe por afirmación y dimensión. Dé casos aprobados, cambios aprobados, defectos conocidos y discrepancias, junto con el conjunto real. Finanzas necesita filas e importes. Operaciones, el ensayo y desviaciones. Propiedad, tareas ejecutadas y lagunas.

El riesgo residual pertenece al registro, no a las actas. Describa condición, impacto, detección, contención, responsable y revisión. Un riesgo aceptado tiene dueño y respuesta. Una reserva sin asignar es trabajo pendiente.

Establezca caducidad. Una versión, normalización, esquema, canal o política contable nueva puede invalidar pruebas. El índice dice qué repetir. La aceptación se aplica a un sistema y condiciones identificados, no a cualquier versión futura.

Mantenga estrecha la puerta de lanzamiento. Ninguna discrepancia inexplicada puede afectar conducta requerida. Finanzas debe aprobar la conciliación. La recuperación debe haberse ejecutado. El receptor debe completar los ejercicios. Toda excepción requiere autoridad responsable.

Rechazaría una reescritura de código hermoso con pruebas débiles. Aceptaría una con una lista breve de defectos si coincide la conducta necesaria, cuadran los libros, funciona la recuperación y los ingenieros de guardia pueden cambiarla solos. La firma registra entonces algo ya probado por máquinas, cuentas y práctica humana.