Cómo una migración de AS/400 mueve más que un ERP

Llamar ERP al AS/400 es un error de categoría que lleva a los equipos a definir mal el alcance del proyecto. Un ERP es una aplicación. IBM i es un entorno operativo que puede alojar paquetes comprados, aplicaciones RPG a medida, una base de datos, pantallas, colas, informes, reglas de seguridad y las rutinas que conectan todos esos elementos. Una empresa puede sustituir el paquete que reconoce y seguir atada a la máquina.

Una migración de AS/400 solo tiene éxito cuando el reemplazo reproduce los resultados de negocio que genera el entorno actual, incluidos los recorridos extraños que nadie documentó. Mover tablas y reescribir los programas visibles cubre una parte del trabajo. La tarea difícil consiste en encontrar dónde reside el comportamiento, decidir qué comportamiento merece conservarse y demostrar que el sistema nuevo coincide con producción antes de apagar el antiguo.

La unidad útil de análisis no es el nombre de una aplicación ni un miembro de código fuente. Es una transacción de negocio y cada objeto que toca. Siga la liberación de un pedido, un bloqueo de crédito, un ajuste de almacén o un asiento de cierre de mes a través de pantallas, programas, archivos, colas, salidas impresas e intervenciones del operador. Ese recorrido indica qué debe migrarse.

La etiqueta AS/400 oculta un entorno operativo completo

La máquina suele contener una red de aplicaciones y convenciones operativas, no un único bloque con forma de ERP. IBM cambió varias veces el nombre de la plataforma e IBM i ahora se ejecuta en hardware Power, pero muchas empresas todavía usan AS/400 como nombre práctico para todo lo que hay detrás de una pantalla verde. Esa abreviatura no causa problemas hasta que se convierte en el límite de la migración.

Empiece por el modelo de objetos. Los programas, archivos de base de datos, archivos de pantalla, archivos de impresora, comandos, áreas de datos, colas de datos, colas de trabajos, colas de salida, perfiles de usuario y listas de autorización son objetos del sistema con tipos y permisos. Las bibliotecas agrupan objetos, mientras que la lista de bibliotecas de un trabajo influye en qué objeto resuelve un nombre no cualificado durante la ejecución. Dos trabajos pueden invocar el mismo nombre de programa y llegar a objetos distintos porque sus listas de bibliotecas difieren. Una búsqueda en el repositorio no puede mostrarlo por sí sola.

El software comprado complica el panorama. Un paquete de proveedor puede controlar el núcleo contable mientras el código RPG a medida se encarga de precios, asignaciones, controles normativos, trabajo de almacén o intercambio de archivos. Los programas CL pueden preparar el entorno, redirigir archivos, enviar trabajos e invocar programas del proveedor y programas propios. Es posible que los operadores ejecuten comandos desde menús en un orden preciso porque una antigua ruta de excepción nunca recibió una interfaz adecuada. Nada de eso pasa a formar parte del ERP solo porque los usuarios accedan desde el mismo menú.

El primer límite debe separar plataforma, paquete, personalización e integración. Registre quién es responsable de cada componente, cómo se invoca y qué datos o efectos controla. Esta distinción cambia las opciones. Puede sustituir un paquete, conservar temporalmente una base de datos, reescribir flujos a medida y retirar un protocolo de transferencia con calendarios independientes. Tratar todo el entorno como un solo producto obliga a tomar una decisión arriesgada de una sola vez o deja dependencias ocultas hasta el corte.

Los diagramas de arquitectura suelen omitir objetos operativos porque no parecen código fuente. Es un error. Una descripción de trabajo puede elegir la lista de bibliotecas, la cola de salida, el nivel de registro y la identidad de usuario del trabajo enviado. Un área de datos puede guardar una fecha de proceso o un valor de secuencia. Una cola de mensajes puede ser el único lugar donde un operador descubre que se detuvo un lote. Si un proceso de negocio necesita un objeto, ese objeto pertenece al mapa de la aplicación.

Db2 for i forma parte del comportamiento de la aplicación

Una exportación de base de datos no captura la semántica de Db2 for i, porque los programas dependen de mucho más que filas y columnas. Db2 for i está integrado con IBM i. Las aplicaciones tradicionales suelen usar archivos físicos y lógicos creados con DDS mediante acceso nativo a registros, mientras que el código más reciente o revisado puede usar tablas, vistas, índices, procedimientos y disparadores SQL. Ambos estilos pueden coexistir en la misma transacción.

La documentación Database files de IBM establece una distinción precisa: un archivo físico almacena datos de la aplicación, mientras que un archivo lógico representa uno o varios archivos físicos sin almacenar otra copia de los registros. Desde la perspectiva de SQL, un archivo físico equivale a una tabla. Un archivo lógico puede parecerse a una vista, a un índice o a ambos. Este último detalle importa. Un archivo lógico puede definir una ruta de acceso por clave, seleccionar u omitir registros, reordenar campos, unir archivos físicos o presentar el formato de registro que espera un programa. Convertir cada archivo lógico en una vista de PostgreSQL puede eliminar una propiedad de ordenación o búsqueda de la que dependía el RPG nativo. Convertirlos todos en índices puede perder reglas de selección y proyección.

Los miembros crean otra diferencia. Un archivo físico puede contener varios miembros, cada uno con un conjunto separado de registros del mismo formato. Muchos sistemas solo usan el miembro predeterminado, pero algunos emplean miembros para periodos, sucursales, importaciones o conjuntos de trabajo. Una exportación plana que lee un solo miembro pierde datos sin avisar. El diseño de destino debe decidir si un miembro se convierte en una partición, una columna de inquilino o periodo, una tabla de preparación o una convención obsoleta. La decisión exige pruebas de uso, no una correspondencia general.

Los formatos de registro también contienen supuestos sobre los datos. Los decimales empaquetados, decimales zonificados, campos de caracteres de longitud fija, espacios en blanco, fechas cero, indicadores codificados y campos descritos externamente se comportan de manera distinta a unos tipos SQL elegidos deprisa. Un número de diez dígitos puede ser un identificador con el que nunca debe hacerse aritmética. Un espacio en blanco puede significar desconocido, mientras que cero significa explícitamente ninguno. Algunos archivos no tienen restricciones de base de datos porque cada escritor en RPG aplicó históricamente la regla. La migración debe recuperar esa regla antes de añadir una restricción en el destino o los registros antiguos válidos fallarán durante la carga.

El registro por diario y el control de compromiso requieren una inspección aparte. La documentación Commitment control de IBM explica que un grupo de cambios de base de datos puede confirmarse o revertirse como una unidad y que los archivos usados bajo ese control deben tener diario. Algunas rutas de la aplicación utilizan esos límites; otras realizan escrituras nativas independientes y dependen de una lógica de reinicio. Envolver toda una solicitud del reemplazo en una transacción puede cambiar la duración de los bloqueos y la recuperación ante fallos. No crear una transacción donde el trabajo antiguo tenía una puede exponer actualizaciones parciales. Reproduzca primero la unidad de trabajo observada y mejórela después de forma deliberada.

Por tanto, el descubrimiento de la base de datos necesita definiciones de archivos, miembros, rutas de acceso, restricciones, disparadores, diarios, recuentos de registros, permisos y rastros reales de acceso. El esquema es solo el principio.

El código RPG es solo una parte del grafo ejecutable

Los programas RPG muestran cálculos, pero el grafo ejecutable también incluye descripciones compiladas, convenciones de llamada, preparación en CL, procedimientos enlazados, redirecciones y resolución de objetos durante la ejecución. Incluso un inventario limpio de código puede omitir el código que producción ejecuta.

La documentación de RPG de IBM distingue los archivos descritos por programa de los descritos externamente. Con un archivo descrito externamente, el compilador obtiene las definiciones de campos y registros de DDS o SQL durante la compilación. Eso crea una dependencia fácil de pasar por alto: cambiar el formato de un archivo puede exigir recompilar los programas dependientes aunque no haya cambiado su código. Las comprobaciones de nivel pueden detectar un formato incompatible, pero desactivarlas no hace compatibles las estructuras. Solo elimina un mecanismo de aviso.

El RPG antiguo puede usar el ciclo, indicadores, estructuras de datos, subrutinas, indicadores de excepción y operaciones nativas como CHAIN, SETLL, READE, WRITE, UPDATE y DELETE. El RPG moderno puede usar sintaxis libre, procedimientos, programas de servicio y SQL incorporado. Ninguna sintaxis revela la importancia de negocio de un programa. Un envoltorio CL de treinta líneas que configura una lista de bibliotecas y redirige un archivo de base de datos puede cambiar el significado de un programa RPG de diez mil líneas.

Los enlaces en tiempo de ejecución merecen su propio mapa. Registre cada arista de llamada que pueda observar, incluidos los nombres dinámicos de programas construidos a partir de datos, comandos de menú, programas de salida, disparadores e invocaciones remotas. Registre los parámetros por posición, tipo, longitud y comportamiento de modificación. Los programas IBM i suelen pasar parámetros por referencia, de modo que el programa llamado puede devolver un estado modificando un campo de entrada. Una API de reemplazo que solo modele el valor de retorno visible puede descartar detalles de error o el estado de continuación.

Las redirecciones de archivos causan defectos de migración con frecuencia. Un comando OVRDBF puede redirigir el nombre de archivo de un programa a otro archivo o miembro sin editar el código RPG. Este mecanismo sirve para datos de prueba, empresas alternativas, miembros de archivo histórico y trabajo temporal. Si el descubrimiento solo lee especificaciones F y sentencias SQL, registra el destino declarado en lugar del objeto abierto durante la ejecución. Capture las redirecciones de CL y de los trabajos activos, y relaciónelas con las transacciones que las utilizan.

Haga lo mismo con las listas de bibliotecas y los permisos. Un programa puede ejecutarse bajo el perfil de quien lo invoca, adoptar los permisos de su propietario o depender de una lista de autorización. El servicio de destino necesita un modelo explícito de identidad y permisos. Copiar privilegios amplios de IBM i en una sola cuenta de base de datos puede hacer que pase la primera prueba, pero elimina la separación de la que producción dependía silenciosamente.

Una reescritura es segura cuando cada punto de entrada de producción tiene un camino trazado por este grafo. Traducir el código sin el grafo produce código convincente que llama al objeto equivocado.

Los archivos de pantalla contienen decisiones de negocio

Un archivo de pantalla es comportamiento ejecutable de interfaz, no una definición cosmética. Los archivos de pantalla DDS definen formatos de registro, campos, constantes, teclas de función, subarchivos, atributos, palabras clave de validación e indicadores que controlan lo que un usuario puede ver o introducir. RPG y el archivo de pantalla comparten la responsabilidad de la interacción. Migrar solo la mitad RPG cambia el flujo de trabajo.

Piense en una pantalla de aprobación de pedidos. RPG puede cargar el pedido y activar el indicador 31 cuando el cliente supera un límite de crédito. El archivo de pantalla puede usar ese indicador para mostrar una advertencia, proteger un campo de importe, colorear un estado o habilitar una tecla de función. Otro indicador puede marcar una entrada no válida y colocar el cursor en el campo erróneo. El código RPG muestra que cambia el indicador; DDS explica qué significa ese cambio para el operador. Sin ambos, una nueva pantalla web puede permitir una edición que la antigua bloqueaba.

Los subarchivos añaden comportamiento con estado. Un programa puede cargar una página, conservar un número relativo de registro, marcar filas modificadas y procesar solo registros cuyo campo de selección haya cambiado. Las teclas de función pueden tener significados distintos según el formato de registro. Los mensajes de error pueden proceder de archivos de mensajes y no de cadenas literales. Los archivos de referencia de campos pueden aportar longitudes y reglas de validación compartidas por muchas pantallas. Una captura muestra el aspecto de un estado, no las reglas que conectan estados.

Las reglas DDS de IBM indican que un indicador de opción o un nombre de condición puede condicionar una palabra clave, un campo o la ubicación de un campo. Esa frase breve explica por qué la conversión automática de pantallas suele decepcionar. La lógica de la interfaz está repartida entre el estado RPG y las condiciones DDS. Un analizador de pantallas debe producir un modelo de estados, no un formulario estático.

Recorra la ruta del fallo, no solo el caso correcto. Introduzca un cliente cerrado, un almacén no válido, una cantidad superior a la disponible y una tecla de función durante una actualización parcialmente completada. Registre el mensaje mostrado, la posición del cursor, los campos protegidos, las lecturas, escrituras y bloqueos de base de datos, y la pantalla siguiente. Repita después con dos sesiones que toquen el mismo registro. Los operadores suelen depender del comportamiento exacto de recuperación aunque nadie lo llame requisito.

El reemplazo no necesita imitar una pantalla verde píxel a píxel. Debe conservar las decisiones y controles, y expresarlos con un diseño de cliente claro. Separe la validación de campos de las reglas de dominio. Mantenga los recorridos por teclado cuando el rendimiento dependa de ellos. Sustituya indicadores crípticos por estados con nombre. Un formulario más bonito que debilita el límite de aprobación es una regresión.

Los lotes y las salidas impresas son interfaces de producción

Las pantallas interactivas solo muestran el borde diurno de muchos sistemas IBM i. Los trabajos por lotes, colas, planificadores, archivos de spool, transferencias y mensajes al operador suelen realizar liquidaciones, reposición, facturación, informes e intercambios con socios cuando los usuarios ya se han ido. Estas interfaces necesitan la misma disciplina de migración que una API.

La documentación de IBM sobre gestión de trabajos describe cómo los trabajos enviados esperan en colas y se ejecutan en subsistemas con recursos e instrucciones asignados. Una descripción de trabajo puede controlar el enrutamiento y la salida. Por eso, el comportamiento de un programa por lotes depende de su contexto de lanzamiento. Ejecutar la misma llamada de forma interactiva durante una prueba puede usar otra lista de bibliotecas, otro perfil de usuario, otra regla de mensajes, otra fecha u otra cola de salida. La prueba puede pasar mientras el trabajo programado sigue fallando.

Inventaríe cada planificador, trabajo enviado, subsistema, cola de trabajos, descripción de trabajo, entrada de enrutamiento, cola de salida y cola de mensajes supervisada dentro del alcance de negocio. Incluya planificadores externos y scripts que se conectan por FTP, SFTP, protocolos de base de datos o interfaces de comandos. Registre calendarios, dependencias, reglas de reintento, límites de concurrencia, rangos de duración previstos y la persona o sistema que responde a un fallo. No deduzca un horario de los comentarios del código. Obsérvelo.

La salida de spool merece atención especial. Un archivo de impresora puede codificar encabezados, totales, comportamiento de desbordamiento, saltos de página, copias y enrutamiento. Es posible que la impresora física ya no exista mientras otro proceso sigue consumiendo el spool como fuente de documentos o archivo. Pregunte quién recibe cada salida, qué hace con ella y qué demuestra su entrega. Sustituir un informe por una página web no es equivalente si un almacén espera un flujo de etiquetas o un banco espera un archivo de registros fijos.

El comportamiento de reinicio de los lotes es otro contrato oculto. Un trabajo puede vaciar un archivo de trabajo, procesar registros en orden de clave, guardar un punto de control en un área de datos y volver a enviarse después de un mensaje recuperable. Otro puede ser seguro de repetir porque comprueba un indicador de contabilización. Si el reemplazo usa una cola con entrega al menos una vez, debe saber qué operaciones son idempotentes y cuáles necesitan una clave de negocio estable. Una factura duplicada no es un detalle de infraestructura.

Trate el tiempo como una entrada. Las fechas de proceso, periodos fiscales, cambios de horario, calendarios festivos y cambios de fin de día pueden proceder de áreas de datos o archivos de control en vez del reloj del sistema. Un planificador en la nube con la hora correcta aún puede producir la fecha de negocio equivocada.

El descubrimiento debe producir un mapa de comportamiento

Una fase de descubrimiento útil produce un mapa consultable que conecta puntos de entrada, objetos, datos, efectos y operadores. Una hoja con nombres de programas y recuentos de líneas no puede responder si una liberación de crédito provoca una impresión, un mensaje de cola y una segunda actualización mediante un programa invocado.

Empiece con inventarios del sistema y contrástelos después con el código y las pruebas de ejecución. Los siguientes comandos de IBM i crean datos de salida que pueden consultarse en lugar de copiarse de pantallas de terminal:

DSPOBJD OBJ(APP/*ALL) OBJTYPE(*ALL) OUTPUT(*OUTFILE) OUTFILE(AUDIT/OBJECTS)
DSPPGMREF PGM(APP/*ALL) OUTPUT(*OUTFILE) OUTFILE(AUDIT/PGMREF)
DSPFD FILE(APP/*ALL) TYPE(*ATR) OUTPUT(*OUTFILE) FILEATR(*PF *LF) OUTFILE(AUDIT/FILEATTR)
DSPFFD FILE(APP/*ALL) OUTPUT(*OUTFILE) OUTFILE(AUDIT/FIELDS)

Estos comandos son un artefacto inicial, no un analizador completo. Ejecute inventarios equivalentes en todas las bibliotecas relevantes, conserve los nombres cualificados de objetos y anote dónde los comandos exigen selecciones separadas. Añada listas de miembros de código, datos del catálogo SQL, calendarios de trabajos, configuración de colas, permisos, disparadores, restricciones, diarios y rutas del Integrated File System. Un archivo de referencias de programas informa de las referencias estáticas conocidas por el objeto programa, pero las llamadas dinámicas y las redirecciones de ejecución todavía necesitan rastros y análisis de CL.

Para cada transacción de negocio, guarde como mínimo el punto de entrada, la identidad que llama, la lista de bibliotecas, los programas y programas de servicio alcanzados, los archivos y miembros abiertos, los formatos de registro usados, los mensajes enviados, los trabajos sometidos, los archivos de spool creados, los extremos externos invocados y el resultado de negocio final. Adjunte confianza y pruebas a cada arista. Una referencia de código, una descripción de objeto y un rastro de producción no tienen el mismo peso. Los conflictos entre ellos son hallazgos, no ruido.

El análisis de código muerto debe seguir las pruebas de ejecución. Las fechas de último cambio son señales débiles en sistemas estables, y los datos de último uso pueden faltar o haberse reiniciado. Un programa que no cambia desde hace quince años puede ejecutarse cada noche. Por el contrario, un objeto compilado recientemente puede no recibir ninguna llamada de producción. Ponga en cuarentena las rutas que parezcan muertas, observe un ciclo de negocio representativo y pida a un responsable que acepte su retirada.

La pregunta incómoda es cuánto descubrimiento basta. Hay suficiente cuando el equipo puede elegir una transacción y predecir sus lecturas, escrituras, salidas, señales de fallo, identidad y ruta de recuperación, y luego confirmar esa predicción con pruebas de producción. Las aristas dinámicas desconocidas deben quedar explícitas y probarse. Un inventario grande con puntos de entrada sin explicar no está completo.

La paridad exige resultados y efectos iguales

Las pruebas de paridad deben comparar el comportamiento de negocio observable, no si las funciones traducidas devuelven valores parecidos. El contrato del sistema antiguo incluye mutaciones de la base, orden, mensajes, documentos, envíos a colas de trabajo, llamadas externas, bloqueos y recuperación ante fallos. Una prueba que solo comprueba la fila final puede aprobar un reemplazo que envió dos facturas.

Construya un banco de pruebas alrededor de transacciones de producción registradas y depuradas. Capture el contexto de entrada necesario para repetir cada caso: usuario o rol, contexto de biblioteca o empresa, fecha de negocio, registros iniciales relevantes, campos de pantalla o solicitud y respuestas dependientes. Ejecute las rutas antigua y nueva con datos aislados, normalice diferencias irrelevantes y compare el resultado completo. Mantenga inmutable el rastro original para que un fixture cambiante no haga coincidir ambos sistemas por la razón equivocada.

Un registro de comparación puede ser sencillo:

{"case_id":"credit-release-017","result":"held","writes":[{"entity":"order","key":"48152","fields":{"status":"H"}}],"messages":["CREDIT LIMIT EXCEEDED"],"jobs_submitted":[],"documents":[]}

Los identificadores son ilustrativos, pero la forma obliga al equipo a comparar más que un código de estado. Añada lecturas ordenadas cuando el orden de acceso cambie el resultado, marcas de tiempo con tolerancias declaradas y hashes para documentos grandes. En los informes generados, compare campos analizados y totales antes de preocuparse por la identidad byte a byte. En extractos financieros o formatos fijos de socios, esa identidad puede ser el contrato.

Incluya casos límite y de concurrencia tomados de reglas reales: espacios en blanco frente a cero, valores empaquetados máximos, envíos duplicados, bloqueos de registros, fallos parciales, pantallas canceladas, reinicio después de que termine un trabajo y dos usuarios editando la misma entidad. Repita casos donde los operadores eligieron una tecla de función inusual o corrigieron un campo después de un error. Estas rutas exponen reglas que las muestras del camino feliz omiten.

No permita que la implementación nueva defina el oráculo. Los responsables de producto pueden aprobar cambios intencionados, pero cada diferencia necesita una decisión identificada y un resultado esperado. De lo contrario, la modernización se convierte en excusa para una deriva semántica silenciosa. El conjunto de paridad debe sobrevivir al corte y convertirse en las pruebas de regresión de versiones posteriores.

El destino debe exponer las reglas sin copiar la máquina

Una arquitectura de destino sensata conserva el comportamiento y traslada las reglas a componentes que las personas pueden entender y operar. No recrea bibliotecas, indicadores y redirecciones de archivos con nombres nuevos. La transliteración conserva las dependencias que dificultaban cambiar el sistema antiguo.

Organice el destino alrededor de capacidades de negocio y límites de transacción descubiertos mediante pruebas. Los servicios Go pueden ser responsables de flujos transaccionales y API externas. Los clientes TypeScript pueden expresar el estado de una pantalla sin indicadores numéricos. PostgreSQL puede aplicar restricciones relacionales y proporcionar esquemas, vistas e índices explícitos. Rust tiene sentido para núcleos numéricos cuando las mediciones o los requisitos del dominio lo justifican, no como reemplazo predeterminado de cada cálculo. Son decisiones de diseño, no una tabla mecánica de lenguajes.

Mapee cada elemento de IBM i según su significado. Un archivo físico puede convertirse en una tabla, pero el uso de varios miembros requiere un modelo deliberado. Un archivo lógico puede convertirse en un índice más una vista o en una consulta dentro de un servicio. Una cola de datos puede convertirse en un tema de mensajería, una bandeja de salida de base de datos o una llamada directa según su contrato de entrega. Un área de datos puede convertirse en configuración, estado duradero o una secuencia. Una condición de archivo de pantalla puede convertirse en una regla de cliente o una comprobación de autorización del servidor. Coloque las decisiones de seguridad en el servidor aunque la pantalla antigua ayudara a aplicarlas.

Corte por límites que el mapa de comportamiento pueda verificar. Una secuencia habitual mueve primero las consultas de solo lectura, luego las actualizaciones delimitadas y después los lotes y las interfaces externas, mientras una capa de enrutamiento decide qué implementación atiende una transacción. La secuencia correcta depende del acoplamiento y del riesgo operativo. Evite la doble escritura salvo que pueda demostrar orden, deduplicación y recuperación. La captura de cambios o un único escritor autorizado suelen ser más fáciles de razonar.

CodeHero lee conjuntamente todo el árbol de RPG y CL, reescribe el sistema en Go, Rust, TypeScript y PostgreSQL, y comprueba el comportamiento con un banco de paridad frente al tráfico de producción registrado. Ese método solo resulta útil si el alcance de entrada incluye los archivos, definiciones de pantalla y rutas operativas descritos aquí. Un agente no puede conservar un objeto que nadie recogió.

Mantenga separadas las decisiones de modernización y las de paridad. Primero describa el comportamiento antiguo con pruebas. Después apruebe una regla, un modelo de datos o un flujo de usuario modificado y codifique la nueva expectativa. Esta separación permite que ingeniería explique cada diferencia durante la revisión y la revierta sin adivinar qué desviaciones fueron accidentales.

La prueba de salida pertenece a operaciones

La migración termina cuando la empresa puede operar, recuperar, auditar y cambiar el reemplazo sin depender de IBM i. Superar las pruebas funcionales es necesario, pero los operadores son responsables de la prueba de salida porque gestionan las condiciones que las demostraciones evitan.

Prepare el corte como una transición de estado controlada. Defina la última escritura autorizada en IBM i, la captura o carga final, las consultas de conciliación, las reglas para vaciar colas, el manejo de documentos, los cambios de credenciales, los cambios de ruta y un punto de decisión para la reversión. Nombre a la persona que puede detener el corte y las pruebas que utilizará. Si revertir exige combinar escrituras de dos sistemas, resuelva ese diseño antes del evento en vez de escribir un procedimiento optimista.

Concilie invariantes de negocio, no solo recuentos de tablas. Los pedidos por estado, saldos abiertos, existencias por ubicación, lotes sin contabilizar, continuidad de secuencias, mensajes pendientes y totales de documentos revelan fallos distintos. Conserve identificadores de origen para que el equipo pueda rastrear un registro de destino hasta su procedencia. Archive definiciones fuente, inventarios de objetos, listados de compilación disponibles, diarios o extractos exigidos por las políticas y las pruebas de paridad que respaldan la aceptación.

Ejercite la recuperación antes del apagado. Termine un proceso durante una actualización de varios registros. Retenga una respuesta externa. Duplique un mensaje. Llene una cola. Restaure una copia de la base de datos y repita el trabajo que falta. Confirme que las alertas llegan a una persona con suficiente contexto para actuar. IBM i puede haber convertido algunos comportamientos de recuperación en rutina mediante diarios, registros de trabajos y colas. El reemplazo debe hacer explícita cada responsabilidad.

La seguridad necesita la misma prueba. Compare el acceso efectivo por rol de negocio, incluidos los permisos adoptados y las identidades de trabajos programados. Elimine credenciales temporales de migración, permisos amplios de base de datos, cuentas de transferencia y excepciones de firewall. En entornos regulados, documente dónde se ejecutan los datos y modelos, quién puede administrarlos y qué registros existen. Dar soporte a un entorno controlado no crea una certificación.

Por último, mantenga el sistema antiguo disponible en un estado definido de solo lectura o recuperación únicamente mientras exista una necesidad aprobada. Asígnele un responsable, un coste, una política de acceso y una condición de destrucción o archivo. Una alternativa indefinida se convierte en un segundo sistema de producción que nadie prueba. La meta honesta es el primer día operativo normal en que un trabajo fallido, un total discutido y una regla nueva puedan resolverse sin llamar a la última persona que recuerda el indicador 31.