Comment une migration AS/400 déplace plus qu'un ERP

Qualifier l'AS/400 d'ERP est une erreur de catégorie qui pousse les équipes à mal délimiter le projet. Un ERP est une application. IBM i est un environnement d'exploitation qui peut héberger des progiciels, des applications RPG sur mesure, une base de données, des écrans, des files d'attente, des rapports, des règles de sécurité et les routines qui relient tous ces éléments. Une entreprise peut remplacer le progiciel qu'elle identifie tout en restant prisonnière de la machine.

Une migration AS/400 ne réussit que si le système de remplacement reproduit les résultats métier de l'environnement actuel, y compris les parcours étranges que personne n'a documentés. Déplacer les tables et réécrire les programmes visibles ne couvre qu'une partie du travail. La difficulté consiste à trouver où se loge le comportement, à décider ce qui mérite d'être conservé et à prouver que le nouveau système concorde avec la production avant d'arrêter l'ancien.

La bonne unité d'analyse n'est ni un nom d'application ni un membre source. C'est une transaction métier et tous les objets qu'elle touche. Suivez la validation d'une commande, un blocage de crédit, un ajustement de stock ou une écriture de clôture mensuelle à travers les écrans, programmes, fichiers, files d'attente, sorties imprimées et interventions des opérateurs. Ce parcours indique ce qui doit migrer.

Le nom AS/400 cache un environnement d'exploitation

La machine contient généralement un réseau d'applications et de conventions d'exploitation, pas un bloc unique en forme d'ERP. IBM a renommé la plateforme plusieurs fois et IBM i fonctionne désormais sur du matériel Power, mais beaucoup d'entreprises emploient encore AS/400 comme nom pratique pour tout ce qui se trouve derrière un écran vert. Ce raccourci ne pose aucun problème jusqu'au moment où il définit la frontière de la migration.

Commencez par le modèle objet. Les programmes, fichiers de base de données, fichiers écran, fichiers imprimante, commandes, zones de données, files de données, files de travaux, files de sortie, profils utilisateur et listes d'autorisation sont des objets système dotés de types et de droits. Les bibliothèques regroupent les objets, tandis que la liste de bibliothèques d'un travail détermine quel objet un nom non qualifié résout à l'exécution. Deux travaux peuvent appeler le même nom de programme et atteindre des objets différents parce que leurs listes de bibliothèques diffèrent. Une recherche dans le dépôt ne suffit pas à le montrer.

Les logiciels achetés compliquent la situation. Un progiciel peut posséder le coeur comptable, tandis que du code RPG sur mesure gère la tarification, l'affectation, les contrôles réglementaires, les opérations d'entrepôt ou les échanges de fichiers. Des programmes CL peuvent préparer l'environnement, substituer des fichiers, soumettre des travaux et appeler des programmes du fournisseur comme des programmes internes. Les opérateurs peuvent lancer des commandes depuis des menus dans un ordre précis parce qu'un ancien parcours d'exception n'a jamais reçu d'interface correcte. Rien de cela ne devient une partie de l'ERP simplement parce que les utilisateurs passent par le même menu.

La première frontière à tracer sépare la plateforme, le progiciel, les adaptations et les intégrations. Notez qui possède chaque composant, comment il est appelé et quelles données ou quels effets il contrôle. Cette distinction change les options disponibles. Vous pouvez remplacer un progiciel, conserver temporairement une base, réécrire des processus sur mesure et retirer un protocole de transfert selon des calendriers distincts. Traiter tout l'environnement comme un seul produit impose soit une bascule globale risquée, soit la découverte des dépendances cachées au moment du basculement.

Les schémas d'architecture omettent souvent les objets d'exploitation parce qu'ils ne ressemblent pas à du code source. C'est une erreur. Une description de travail peut choisir la liste de bibliothèques, la file de sortie, le niveau de journalisation et l'identité utilisateur des travaux soumis. Une zone de données peut contenir une date de traitement ou un numéro de séquence. Une file de messages peut être le seul endroit où un opérateur apprend qu'un lot s'est arrêté. Si un processus métier a besoin d'un objet, cet objet appartient à la carte applicative.

Db2 for i fait partie du comportement applicatif

Un export de base de données ne saisit pas la sémantique de Db2 for i, car les programmes dépendent de bien plus que des lignes et des colonnes. Db2 for i est intégré à IBM i. Les applications traditionnelles utilisent souvent des fichiers physiques et logiques créés en DDS au moyen d'un accès natif aux enregistrements, tandis que le code plus récent ou remanié peut employer des tables, vues, index, procédures et déclencheurs SQL. Les deux styles peuvent coexister dans la même transaction.

La documentation Database files d'IBM établit une distinction précise : un fichier physique stocke les données applicatives, tandis qu'un fichier logique représente un ou plusieurs fichiers physiques sans conserver une autre copie des enregistrements. Du point de vue SQL, un fichier physique ressemble à une table. Un fichier logique peut ressembler à une vue, à un index ou aux deux. Ce dernier point compte. Un fichier logique peut définir un chemin d'accès par clé, sélectionner ou omettre des enregistrements, réordonner des champs, joindre des fichiers physiques ou présenter un format d'enregistrement attendu par un programme. Transformer chaque fichier logique en vue PostgreSQL peut supprimer une propriété d'ordre ou de recherche dont dépendait le code RPG natif. Tout convertir en index peut faire perdre des règles de sélection et de projection.

Les membres créent un autre écart. Un fichier physique peut contenir plusieurs membres, chacun constituant un ensemble distinct d'enregistrements de même format. Beaucoup de systèmes n'utilisent que le membre par défaut, mais certains emploient les membres pour des périodes, des agences, des imports ou des ensembles de travail. Un export plat qui ne lit qu'un membre perd des données sans le signaler. La conception cible doit décider si un membre devient une partition, une colonne de locataire ou de période, une table de transit ou une convention devenue inutile. Cette décision exige des preuves d'utilisation, pas une correspondance générale.

Les formats d'enregistrement transportent eux aussi des hypothèses sur les données. Les décimaux condensés, les décimaux zonés, les champs de caractères à longueur fixe, les blancs, les dates nulles, les indicateurs codés et les champs décrits en externe ne se comportent pas comme des types SQL choisis à la légère. Un nombre de dix chiffres peut être un identifiant sur lequel aucun calcul ne doit être fait. Un blanc peut signifier inconnu, alors que zéro signifie explicitement aucun. Certains fichiers n'ont aucune contrainte de base parce que chaque programme RPG qui écrivait dedans appliquait historiquement la règle. La migration doit retrouver cette règle avant d'ajouter une contrainte dans la cible, sinon des enregistrements anciens pourtant valides échoueront au chargement.

La journalisation et le contrôle de validation demandent une analyse séparée. La documentation Commitment control d'IBM indique qu'un groupe de modifications de base peut être validé ou annulé comme une seule unité et que les fichiers utilisés sous ce contrôle doivent être journalisés. Certains parcours applicatifs utilisent ces limites, tandis que d'autres font des écritures natives indépendantes et comptent sur une logique de reprise. Enfermer toute une requête de remplacement dans une transaction peut modifier la durée des verrous et la reprise après incident. Ne pas créer de transaction là où l'ancien travail en possédait une peut exposer des mises à jour partielles. Reproduisez d'abord l'unité de travail observée, puis améliorez-la consciemment.

La découverte de la base doit donc inclure les définitions de fichiers, les membres, les chemins d'accès, les contraintes, les déclencheurs, les journaux, les volumes d'enregistrements, les droits et les traces réelles d'accès. Le schéma n'est que le début.

Le source RPG n'est qu'une partie du graphe exécutable

Les programmes RPG montrent les calculs, mais le graphe exécutable comprend aussi les descriptions compilées, les conventions d'appel, la préparation en CL, les procédures liées, les substitutions et la résolution des objets à l'exécution. Même un inventaire propre des sources peut manquer le code réellement exécuté en production.

La documentation RPG d'IBM distingue les fichiers décrits par programme des fichiers décrits en externe. Pour un fichier décrit en externe, le compilateur récupère les définitions des champs et des enregistrements dans les définitions DDS ou SQL au moment de la compilation. Cela crée une dépendance facile à manquer : modifier le format d'un fichier peut imposer de recompiler les programmes qui en dépendent, même si leur source n'a pas changé. Les contrôles de niveau peuvent signaler un format incompatible, mais leur désactivation ne rend pas les structures compatibles. Elle retire seulement un mécanisme d'alerte.

Un ancien programme RPG peut utiliser le cycle, les indicateurs, les structures de données, les sous-routines, les indicateurs d'exception et des opérations natives comme CHAIN, SETLL, READE, WRITE, UPDATE et DELETE. Du RPG moderne peut utiliser la syntaxe libre, des procédures, des programmes de service et du SQL intégré. Aucune syntaxe ne révèle l'importance métier d'un programme. Un wrapper CL de trente lignes qui définit une liste de bibliothèques et substitue un fichier de base peut changer le sens d'un programme RPG de dix mille lignes.

Les liaisons à l'exécution méritent leur propre carte. Relevez chaque relation d'appel observable, y compris les noms de programme dynamiques construits depuis des données, les commandes de menu, les programmes de sortie, les déclencheurs et les appels distants. Décrivez les paramètres par position, type, longueur et comportement de modification. Les programmes IBM i passent souvent les paramètres par référence, ce qui permet à l'appelé de renvoyer un état en modifiant un champ d'entrée. Une API de remplacement qui ne représente que la valeur de retour visible peut perdre des détails d'erreur ou un état de poursuite.

Les substitutions de fichiers causent souvent des défauts de migration. Une commande OVRDBF peut rediriger le nom de fichier d'un programme vers un autre fichier ou membre sans modifier le source RPG. Ce mécanisme sert aux données de test, aux sociétés alternatives, aux membres d'archive et aux travaux temporaires. Si la découverte ne lit que les spécifications F et les instructions SQL, elle enregistre la cible déclarée plutôt que l'objet ouvert à l'exécution. Capturez les substitutions dans le CL et les travaux actifs, puis reliez-les aux transactions qui les utilisent.

Procédez de même pour les listes de bibliothèques et les droits. Un programme peut s'exécuter sous le profil de l'appelant, adopter les droits de son propriétaire ou dépendre d'une liste d'autorisation. Le service cible a besoin d'un modèle explicite d'identité et de permissions. Copier de larges droits IBM i dans un compte de base unique peut faire réussir le premier test, mais supprime la séparation dont la production dépendait silencieusement.

Une réécriture est sûre lorsque chaque point d'entrée de production possède un chemin tracé dans ce graphe. Traduire le source sans ce graphe produit du code convaincant qui appelle le mauvais objet.

Les fichiers écran contiennent des décisions métier

Un fichier écran décrit un comportement d'interface exécutable, pas une simple présentation visuelle. Les fichiers écran DDS définissent les formats d'enregistrement, champs, constantes, touches de fonction, sous-fichiers, attributs, mots-clés de validation et indicateurs qui contrôlent ce qu'un utilisateur peut voir ou saisir. RPG et le fichier écran se partagent la responsabilité de l'interaction. Migrer uniquement la moitié RPG modifie le processus.

Prenez un écran de validation de commande. RPG peut charger la commande et activer l'indicateur 31 lorsque le client dépasse un seuil de crédit. Le fichier écran peut utiliser cet indicateur pour afficher un avertissement, protéger un champ de montant, colorer un statut ou activer une touche de fonction. Un autre indicateur peut signaler une saisie invalide et placer le curseur sur le champ en faute. Le source RPG montre que l'indicateur change, tandis que le DDS explique ce que ce changement signifie pour l'opérateur. Sans les deux, un nouvel écran web peut autoriser une modification que l'ancien bloquait.

Les sous-fichiers ajoutent un comportement avec état. Un programme peut charger une page, conserver un numéro d'enregistrement relatif, marquer les lignes modifiées et ne traiter que les enregistrements dont le champ de sélection a changé. Les touches de fonction peuvent avoir un sens différent selon le format d'enregistrement. Les messages d'erreur peuvent provenir de fichiers de messages plutôt que de chaînes littérales. Des fichiers de référence de champs peuvent fournir des longueurs et des règles de validation partagées par de nombreux écrans. Une capture d'écran enregistre l'apparence d'un état, pas les règles qui relient les états.

Les règles DDS d'IBM précisent qu'un indicateur d'option ou un nom de condition peut conditionner un mot-clé, un champ ou sa position. Cette courte phrase explique pourquoi la conversion automatique des écrans déçoit souvent. La logique de l'interface est distribuée entre l'état RPG et les conditions DDS. Un analyseur d'écran doit produire un modèle d'état, pas un formulaire statique.

Parcourez le chemin d'échec, pas seulement le cas nominal. Saisissez un client fermé, un entrepôt invalide, une quantité supérieure au disponible et une touche de fonction pendant une mise à jour partiellement terminée. Relevez le message affiché, la position du curseur, les champs protégés, les lectures et écritures en base, les verrous et l'écran suivant. Recommencez avec deux sessions qui touchent le même enregistrement. Les opérateurs dépendent souvent du comportement exact de reprise, même si personne ne l'appelle une exigence.

Le remplacement n'a pas à imiter un écran vert au pixel près. Il doit préserver les décisions et les contrôles, puis les exprimer dans une conception client claire. Séparez la validation des champs de la politique métier. Conservez les parcours clavier lorsque le débit en dépend. Remplacez les indicateurs obscurs par des états nommés. Un formulaire plus joli qui affaiblit la limite d'approbation est une régression.

Les traitements par lots et les sorties imprimées sont des interfaces

Les écrans interactifs ne montrent que la partie diurne de nombreux systèmes IBM i. Les travaux par lots, files d'attente, planificateurs, fichiers spool, transferts et messages opérateur assurent souvent le règlement, le réapprovisionnement, la facturation, les rapports et les échanges avec les partenaires après le départ des utilisateurs. Ces interfaces exigent la même rigueur de migration qu'une API.

La documentation IBM sur la gestion des travaux décrit comment les travaux soumis attendent dans des files et s'exécutent dans des sous-systèmes dotés de ressources et d'instructions de traitement. Une description de travail peut contrôler le routage et la sortie. Le comportement d'un programme par lot dépend donc de son contexte de lancement. Exécuter le même appel de manière interactive pendant un test peut utiliser une autre liste de bibliothèques, un autre profil utilisateur, une autre règle de gestion des messages, une autre date ou une autre file de sortie. Le test peut réussir alors que le travail planifié échoue toujours.

Inventoriez chaque planificateur, travail soumis, sous-système, file de travaux, description de travail, entrée de routage, file de sortie et file de messages surveillée dans le périmètre métier. Incluez les planificateurs externes et les scripts qui se connectent par FTP, SFTP, protocoles de base de données ou interfaces de commande. Notez les calendriers, dépendances, règles de nouvelle tentative, limites de concurrence, plages de durée attendues et la personne ou le système qui réagit à un échec. Ne déduisez pas un calendrier des commentaires du source. Observez-le.

Les sorties spool méritent une attention particulière. Un fichier imprimante peut coder les en-têtes, totaux, débordements, sauts de page, copies et routages. L'imprimante physique peut avoir disparu alors qu'un autre processus consomme encore le spool comme source de documents ou d'archives. Demandez qui reçoit chaque sortie, ce qu'il en fait et ce qui prouve la livraison. Remplacer un rapport par une page web n'est pas équivalent si un entrepôt attend un flux d'étiquettes ou une banque un fichier à enregistrements fixes.

Le comportement de reprise d'un lot est un autre contrat caché. Un travail peut vider un fichier temporaire, traiter les enregistrements dans l'ordre des clés, placer un point de reprise dans une zone de données et se soumettre à nouveau après un message récupérable. Un autre peut être volontairement rejouable parce qu'il vérifie un indicateur de comptabilisation. Si le remplacement emploie une file livrée au moins une fois, vous devez savoir quelles opérations sont idempotentes et lesquelles exigent une clé métier stable. Une facture en double n'est pas un détail d'infrastructure.

Traitez le temps comme une donnée d'entrée. Les dates de traitement, périodes comptables, changements d'heure, calendriers fériés et bascules de fin de journée peuvent venir de zones de données ou de fichiers de contrôle plutôt que de l'horloge système. Un planificateur cloud réglé à la bonne heure peut quand même produire la mauvaise date métier.

La découverte doit produire une carte des comportements

Une phase de découverte utile produit une carte interrogeable des comportements qui relie points d'entrée, objets, données, effets et opérateurs. Une feuille contenant des noms de programmes et des nombres de lignes ne peut pas dire si une validation de crédit déclenche une impression, un message de file et une seconde mise à jour dans un programme appelé.

Commencez par les inventaires système, puis confrontez-les au source et aux preuves d'exécution. Les commandes IBM i suivantes créent des données dans des fichiers de sortie interrogeables au lieu d'informations recopiées depuis des écrans 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)

Ces commandes constituent un premier artefact, pas un analyseur complet. Exécutez des inventaires équivalents dans toutes les bibliothèques concernées, conservez les noms d'objets qualifiés et notez les commandes qui exigent des sélections séparées. Ajoutez les listes de membres source, les catalogues SQL, les calendriers de travaux, la configuration des files, les droits, déclencheurs, contraintes, journaux et chemins de l'Integrated File System. Un fichier de références de programmes signale les références statiques connues de l'objet programme, mais les appels dynamiques et les substitutions à l'exécution nécessitent toujours des traces et une analyse CL.

Pour chaque transaction métier, stockez au moins le point d'entrée, l'identité appelante, la liste de bibliothèques, les programmes et programmes de service atteints, les fichiers et membres ouverts, les formats d'enregistrement utilisés, les messages envoyés, les travaux soumis, les fichiers spool créés, les points externes appelés et le résultat métier final. Attachez un niveau de confiance et une preuve à chaque relation. Une référence de source, une description d'objet et une trace de production n'ont pas le même poids. Leurs contradictions sont des résultats d'analyse, pas du bruit.

L'analyse du code mort doit suivre les preuves d'exécution. Les dates de dernière modification sont de faibles signaux sur des systèmes stables, et les données de dernière utilisation peuvent manquer ou avoir été réinitialisées. Un programme inchangé depuis quinze ans peut tourner toutes les nuits. À l'inverse, un objet compilé récemment peut ne jamais recevoir d'appel de production. Mettez en quarantaine les parcours supposés morts, observez un cycle métier représentatif et obtenez l'accord d'un responsable avant de les retirer.

La question gênante est de savoir quand la découverte suffit. Elle suffit lorsque l'équipe peut choisir une transaction, prévoir ses lectures, écritures, sorties, signaux d'échec, son identité et son chemin de reprise, puis confirmer cette prévision par des preuves de production. Les relations dynamiques inconnues doivent être explicites et testées. Un vaste inventaire avec des points d'entrée inexpliqués n'est pas complet.

La parité porte sur les résultats et les effets

Les tests de parité doivent comparer le comportement métier observable, pas la simple ressemblance des valeurs renvoyées par les fonctions traduites. Le contrat de l'ancien système comprend les mutations de base, l'ordre, les messages, les documents, les soumissions de travaux, les appels externes, les verrous et la reprise après erreur. Un test qui ne vérifie que la dernière ligne peut approuver un remplacement qui a envoyé deux factures.

Construisez un banc de test autour de transactions de production enregistrées et assainies. Capturez le contexte d'entrée nécessaire pour rejouer chaque cas : utilisateur ou rôle, contexte de bibliothèque ou de société, date métier, enregistrements initiaux concernés, champs d'écran ou de requête et réponses dépendantes. Exécutez l'ancien et le nouveau parcours sur des données isolées, normalisez les différences sans importance et comparez le résultat complet. Conservez la trace d'origine sans modification afin qu'un jeu de test changeant ne fasse pas concorder les deux systèmes pour une mauvaise raison.

Un enregistrement de comparaison peut rester simple :

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

Les identifiants sont des exemples, mais cette forme oblige l'équipe à comparer plus qu'un code d'état. Ajoutez les lectures ordonnées lorsque l'ordre d'accès influe sur le résultat, des horodatages avec des tolérances déclarées et des empreintes pour les gros documents. Pour les rapports générés, comparez les champs analysés et les totaux avant de rechercher l'identité octet par octet. Pour des extraits financiers ou des formats partenaires fixes, cette identité peut constituer le contrat.

Incluez des cas limites et concurrents tirés des vraies règles : blancs contre zéro, valeurs condensées maximales, soumissions en double, verrous d'enregistrement, échecs partiels, écrans annulés, reprise après l'arrêt d'un travail et deux utilisateurs modifiant la même entité. Rejouez les cas où les opérateurs ont choisi une touche inhabituelle ou corrigé un champ après une erreur. Ces parcours exposent des règles que les cas nominaux ne voient pas.

Ne laissez pas la nouvelle implémentation définir l'oracle. Les responsables produit peuvent approuver des changements voulus, mais chaque différence exige une décision nommée et un résultat attendu. Sinon, la modernisation excuse une dérive sémantique silencieuse. La suite de parité doit survivre au basculement et devenir la suite de régression des versions suivantes.

La cible doit exposer les règles sans copier la machine

Une architecture cible saine conserve le comportement tout en plaçant les règles dans des composants que les personnes peuvent comprendre et exploiter. Elle ne recrée pas les bibliothèques, indicateurs et substitutions de fichiers sous de nouveaux noms. La translittération conserve les dépendances qui rendaient l'ancien système difficile à modifier.

Organisez la cible selon les capacités métier et les limites de transaction révélées par les preuves. Des services Go peuvent posséder les processus transactionnels et les API externes. Des clients TypeScript peuvent exprimer l'état d'un écran sans indicateurs numériques. PostgreSQL peut appliquer des contraintes relationnelles et fournir des schémas, vues et index explicites. Rust convient aux noyaux numériques quand les mesures ou les exigences métier le justifient, pas comme remplacement par défaut de chaque calcul. Ce sont des choix de conception, pas une table mécanique de correspondance des langages.

Associez chaque construction IBM i selon son sens. Un fichier physique peut devenir une table, mais l'emploi de plusieurs membres exige un modèle réfléchi. Un fichier logique peut devenir un index accompagné d'une vue ou une requête dans un service. Une file de données peut devenir un sujet de courtier de messages, une boîte d'envoi en base ou un appel direct selon son contrat de livraison. Une zone de données peut devenir une configuration, un état durable ou une séquence. Une condition de fichier écran peut devenir une règle client ou un contrôle d'autorisation côté serveur. Placez les décisions de sécurité sur le serveur, même lorsque l'ancien écran contribuait à les appliquer.

Découpez selon des frontières que la carte des comportements peut vérifier. Une séquence courante déplace d'abord les consultations en lecture seule, puis les mises à jour délimitées, puis les traitements par lots et les interfaces externes, tandis qu'une couche de routage choisit l'implémentation qui traite la transaction. Le bon ordre dépend du couplage et du risque opérationnel. Évitez les doubles écritures sauf si vous pouvez prouver l'ordre, la déduplication et la reprise. La capture de changements ou un rédacteur unique faisant autorité sont généralement plus faciles à raisonner.

CodeHero lit tout l'arbre RPG et CL ensemble, réécrit le système en Go, Rust, TypeScript et PostgreSQL, puis vérifie le comportement avec un banc de parité fondé sur le trafic de production enregistré. Cette méthode n'est utile que si le périmètre d'entrée comprend les fichiers, définitions d'écran et parcours d'exploitation décrits ici. Un agent ne peut pas préserver un objet que personne n'a collecté.

Séparez les décisions de modernisation des décisions de parité. Établissez d'abord l'ancien comportement avec des preuves. Approuvez ensuite la modification d'une règle, d'un modèle de données ou d'un parcours utilisateur et codez la nouvelle attente. Cette séparation permet aux ingénieurs d'expliquer chaque différence en revue et de la retirer sans deviner quelles divergences étaient accidentelles.

Le test de sortie appartient aux opérations

La migration est terminée lorsque l'entreprise peut exploiter, restaurer, auditer et modifier le remplacement sans dépendre d'IBM i. Les tests fonctionnels sont nécessaires, mais les opérateurs possèdent le test de sortie parce qu'ils traitent les situations que les démonstrations applicatives évitent.

Préparez le basculement comme une transition d'état contrôlée. Définissez la dernière écriture faisant autorité sur IBM i, la capture ou le chargement final, les requêtes de rapprochement, les règles de vidage des files, le traitement des documents, les changements d'identifiants, les changements de routage et un point de décision pour le retour arrière. Nommez la personne qui peut arrêter le basculement et les preuves qu'elle emploiera. Si le retour exige de fusionner des écritures de deux systèmes, résolvez cette conception avant l'événement au lieu de rédiger une procédure optimiste.

Rapprochez les invariants métier, pas seulement les nombres de lignes. Les commandes par état, soldes ouverts, stocks par emplacement, lots non comptabilisés, continuité des séquences, messages en attente et totaux des documents révèlent des erreurs différentes. Conservez les identifiants source afin que l'équipe puisse retracer un enregistrement cible jusqu'à son origine. Archivez les définitions source, inventaires d'objets, listes de compilation disponibles, journaux ou extraits exigés par les règles internes et les preuves de parité qui soutiennent la recette.

Exercez la reprise avant l'arrêt. Tuez un processus pendant une mise à jour de plusieurs enregistrements. Retenez une réponse externe. Dupliquez un message. Remplissez une file. Restaurez une sauvegarde de base et rejouez le travail manquant. Vérifiez que les alertes atteignent une personne avec assez de contexte pour agir. IBM i a pu rendre certaines reprises habituelles grâce aux journaux, journaux de travaux et files. Le remplacement doit rendre chaque responsabilité explicite.

La sécurité demande la même preuve. Comparez les accès effectifs par rôle métier, y compris les droits adoptés et les identités des travaux planifiés. Retirez les identifiants temporaires de migration, les droits larges sur la base, les comptes de transfert et les exceptions de pare-feu. Dans les environnements réglementés, documentez où s'exécutent les données et les modèles, qui peut les administrer et quels journaux existent. La prise en charge d'un environnement contrôlé ne crée pas une certification.

Enfin, ne laissez l'ancien système disponible dans un état défini de lecture seule ou de secours que pendant la durée d'un besoin approuvé. Attribuez-lui un responsable, un coût, une politique d'accès et une condition de destruction ou d'archivage. Un repli sans limite devient un second système de production que personne ne teste. La véritable arrivée est le premier jour d'exploitation ordinaire où un travail échoué, un total contesté et une nouvelle règle peuvent tous être traités sans appeler la dernière personne qui se souvient de l'indicateur 31.