¿Cómo paso al nuevo sistema sin detener el trabajo?

Se cambia de sistema sin detener el trabajo si no apaga el antiguo hasta que el nuevo haya demostrado lo que vale: ejecute ambos con las mismas transacciones reales y compare sus resultados, pruebe los casos poco frecuentes que señalan los responsables de los procesos, exija una aprobación humana de cada módulo antes de ponerlo en marcha y mantenga el sistema antiguo listo para volver a él. En su guía de ejecución de la migración, Microsoft recomienda vigilar el nuevo sistema durante las primeras 24 a 48 horas tras el cambio y conservar el entorno de origen como respaldo durante la estabilización.

En la parte 5 eligió un camino para cada sistema. Esta parte no repite el método general de cambio que explicamos en Modernizar sistemas heredados sin interrupciones. Se centra en lo nuevo: qué probar cuando la IA escribió o convirtió el nuevo código.

Por qué el código convertido por IA necesita otras pruebas

El código que producen las herramientas de conversión parece ordenado y funciona al primer intento, y eso es justo lo que hace difícil ver sus errores. El error no aparece en los casos cotidianos; aparece en el caso que ocurre una vez al mes o una vez al año. Amazon explica en su guía de transformación de aplicaciones mainframe que la conversión inicial de COBOL a Java conserva el mismo comportamiento, y que después un paso llamado Reforge usa grandes modelos de lenguaje para reestructurar el código al estilo moderno de Java. COBOL es un lenguaje de programación antiguo que todavía mueve muchos sistemas bancarios y mainframe; un mainframe es el gran servidor central en el que funcionan los sistemas clave de las grandes organizaciones.

Cada paso que reescribe el código puede cambiar algún detalle. Por eso no basta con que un desarrollador lea el nuevo código y diga que parece correcto. La dirección tiene una sola pregunta: ¿da el nuevo sistema el mismo resultado que el antiguo con los mismos datos? La respuesta sale de comparar resultados, no de leer código.

Compare los resultados con las mismas transacciones reales

Tome un periodo cerrado de su negocio, como un mes con las cuentas ya cerradas, pase sus transacciones por el nuevo sistema y compare lo que sale con lo que produjo el antiguo. Qué comparar:

• Cifras finales: totales de facturación, saldos e inventario al final del periodo.
• Informes: los informes mensuales en los que se apoya la dirección, línea por línea.
• Lo que va a otros sistemas: los archivos y mensajes que se envían al banco, a contabilidad o a los portales públicos.
• Rechazos y errores: una transacción que el sistema antiguo rechaza debe rechazarla también el nuevo, por el mismo motivo.

Algunas herramientas ayudan a preparar, no a juzgar. AWS Transform para mainframe, por ejemplo, crea un plan de pruebas a partir de los atributos del código, la complejidad de los trabajos y las rutas del planificador en 3 fases (configuración, delimitación y revisión), y luego genera scripts para recoger datos de prueba del mainframe en 4 fases. Pero Amazon advierte en la misma guía que esos scripts deben ejecutarse en su propio mainframe, con los permisos de su equipo. La herramienta prepara; su equipo ejecuta y decide. Para comprobar los propios datos, Microsoft sugiere comparar el número de filas como control rápido y después sumas de verificación como control más profundo: una suma de verificación es un número calculado a partir de los datos que cambia si cambia un solo carácter.

Los casos poco frecuentes: pregunte a quien los conoce

Un mes de transacciones reales no lo contiene todo. Los casos que rompen los sistemas los conocen los responsables de los procesos, no los desarrolladores: el cierre de fin de ejercicio, una devolución parcial sobre una factura antigua, un cliente con precios especiales, una factura anulada después de contabilizarse, el salario de alguien que se incorporó a mitad de mes. Pida a cada responsable de proceso la lista de casos que le preocupan y convierta cada uno en una prueba con un resultado esperado escrito antes de ejecutarla.

Aquí vuelven las reglas que confirmó en la parte 4: cada regla confirmada se convierte en al menos un caso de prueba. Una regla sin prueba es una regla de la que no puede decir que sobrevivió a la conversión. Sobre los tipos de prueba en sí, consulte nuestra guía de pruebas de software y control de calidad.

Una aprobación humana para cada módulo

El ejemplo publicado más claro de este principio es el proceso de migración bancaria que Thought Machine anunció con Amazon el 29 de septiembre de 2026. Tiene 4 etapas: extraer la lógica de negocio de las aplicaciones heredadas con AWS Transform, consolidar las variantes redundantes en especificaciones unificadas, generar los nuevos productos financieros y sus conjuntos de pruebas con agentes de IA, y una etapa de validación que da a los equipos de ingeniería y de riesgos del banco autoridad explícita de aprobación antes de aceptar nada. Incluso después de la aprobación, el resultado pasa a un entorno aislado de pruebas para una evaluación adicional, no directamente a producción.

La lección para su empresa no necesita ni un banco ni Amazon: cada módulo del sistema, como facturación, nóminas o inventario, recibe dos firmas antes de ponerse en marcha. Una técnica, que confirma que se ejecutaron todas las pruebas, y otra del responsable del proceso, que confirma que los resultados son correctos en términos de negocio. Microsoft pide lo mismo tras el cambio: que los responsables de la aplicación confirmen que todas las funciones principales funcionan correctamente.

Funcionamiento en paralelo y plan de reversión

Funcionar en paralelo significa que ambos sistemas trabajan a la vez durante un periodo definido, y el antiguo sigue siendo la referencia oficial. Decida antes de empezar cuándo termina ese periodo y qué condición permite cerrarlo, por ejemplo que los resultados coincidan durante un ciclo completo de su negocio. Después organice el cambio así:

Un plan de reversión no es una admisión de fracaso; es un seguro. Escriba de antemano qué le haría volver atrás, como un error en las facturas o la parada de un proceso clave, quién toma esa decisión y cómo vuelven los usuarios al sistema antiguo. No apague el sistema antiguo de forma definitiva hasta que termine el periodo de estabilización. Lo que suele fallar en las primeras semanas tras un cambio lo tratamos en Los primeros treinta días tras la migración.

La visión de Origami

Tratamos el cambio como una decisión de dirección, no como un evento técnico. Por eso construimos la comparación entre los dos sistemas antes de construir el nuevo sistema, y acordamos pronto con los responsables de los procesos los casos poco frecuentes y sus resultados esperados, para que la definición de éxito quede escrita antes de que nadie vea los resultados.

Usamos la IA para acelerar la conversión y generar pruebas, pero la aprobación de cada módulo queda en manos de personas concretas de su equipo. Para ver cómo trabajamos, eche un vistazo a nuestros servicios.

El ejercicio de esta semana: una hoja de cambio por módulo

Para cada sistema que decidió convertir o reconstruir en la parte 5, rellene esta hoja con los responsables de los procesos antes de fijar cualquier fecha de cambio:

Son ejemplos ilustrativos; su hoja será distinta. Lo importante es que no se fije ninguna fecha de cambio hasta que cada módulo tenga dos firmantes con nombre y un motivo de reversión por escrito.

Lo que viene

Queda una pregunta que todo directivo se hace antes de enviar código y datos a una herramienta de IA: ¿adónde van mis datos durante la modernización? La parte 7, la última, la responde y reúne los ejercicios de toda la serie en un plan de 90 días.

Fuentes

• Microsoft: Ejecutar la migración, Cloud Adoption Framework — reunión sobre criterios de reversión, congelación de cambios, validación de datos, 24 a 48 horas de vigilancia y conservación del entorno de origen como respaldo.
• Amazon: Transformación de aplicaciones mainframe en AWS Transform — planes de prueba, scripts de recogida de datos de prueba y el paso Reforge.
• Amazon: anuncio de Thought Machine y AWS sobre migraciones bancarias heredadas — las cuatro etapas y la aprobación de los equipos de ingeniería y de riesgos.
• AWS Transform: página oficial.