Migrer les données vers un nouveau logiciel : pourquoi nous comptons les enregistrements trois fois

Quand une organisation passe à un nouveau système, elle parle surtout de ses fonctionnalités. Les écrans, les rapports, l’application mobile. La manière de migrer les données de l’ancien système passe généralement en dernier, avec un simple « on fera un transfert ».

C’est pourtant là que les projets coincent vraiment. Le code fonctionne, les écrans sont prêts, mais une partie des fiches clients arrive incomplète, et personne ne sait combien ni pourquoi.

Dans cet article, j’explique ce que nous vérifions avant, pendant et après la migration.

D’abord l’inventaire

Nous ne commençons pas une migration par une première ligne de code, mais par une liste. Quelles tables existent dans l’ancien système, combien d’enregistrements contient chacune, que signifie chaque champ, lesquels ne sont plus utilisés.

La surprise la plus fréquente dans cette liste, c’est la même information stockée à deux endroits. L’adresse du client figure à la fois dans la table des clients et dans celle des factures, et les deux ne concordent pas. Décider laquelle fait foi n’est pas une décision technique. C’est à l’organisation de la prendre. Il faut poser la question avant la migration.

La deuxième surprise, c’est que l’ancien système soit un fichier Excel. Dans Excel, tout champ qui n’est pas encadré par une règle est un champ où quelqu’un a un jour écrit autre chose « provisoirement ». On trouve des lignes avec « aucune » dans la colonne des dates, des cellules avec deux numéros dans la colonne des téléphones.

La correspondance des champs

Deux systèmes ne stockent pas les données de la même façon. L’ancien peut avoir un seul champ « nom et prénom » quand le nouveau en a deux. La ville, saisie en texte libre dans l’ancien, peut être choisie dans une liste dans le nouveau.

Pour chaque champ, nous écrivons une règle de correspondance : l’ancien champ, le nouveau champ et la conversion entre les deux. Les enregistrements qui ne respectent pas la règle ne sont pas corrigés en silence. Ils sont placés dans une liste à part. Nous examinons cette liste un par un avec l’organisation.

La correction silencieuse est tentante, mais c’est la pire chose à faire dans une migration. Un enregistrement erroné l’était déjà dans l’ancien système. S’il est corrigé au jugé pendant la migration, il devient dans le nouveau système un enregistrement qui paraît juste mais qui est faux. Personne ne s’en apercevra plus jamais.

Compter trois fois

Pour pouvoir dire « terminé » à la fin d’une migration, nous comptons les enregistrements à trois endroits.

Le premier est la source. Le nombre d’enregistrements à migrer dans l’ancien système, table par table.

Le deuxième est le transfert. Le nombre d’enregistrements que le script de migration a lus, convertis et mis de côté dans la liste à part.

Le troisième est la cible. Le nombre d’enregistrements réellement créés dans le nouveau système.

La source doit être égale à la somme des enregistrements transférés et des enregistrements écartés. Les transférés doivent être égaux à la cible. Si ces deux égalités ne tiennent pas, la migration n’est pas terminée, aussi faible que soit l’écart. Un écart de quelques centaines d’enregistrements, c’est l’historique de quelques centaines de clients perdu.

Que les chiffres concordent ne suffit pas. Les chiffres peuvent concorder alors que le contenu est altéré. C’est pourquoi nous ouvrons côte à côte, dans les deux systèmes, des enregistrements choisis au hasard et nous les comparons champ par champ. Pour les champs critiques comme les montants et les dates, nous calculons aussi séparément des totaux et des valeurs de synthèse des deux côtés.

Migration d’essai et plan de retour arrière

Nous ne faisons pas la vraie migration pour la première fois le jour J. Nous effectuons d’abord au moins deux migrations d’essai sur une copie des données. À chaque essai, nous mesurons la durée, examinons les enregistrements écartés et corrigeons les règles de correspondance.

Avant la vraie migration, un plan de retour arrière est mis par écrit. Que faire si la migration s’interrompt à mi-chemin ou si les chiffres ne concordent pas, jusqu’à quel point on peut revenir à l’ancien système, qui prendra cette décision. Quand ces questions sont posées le jour de la migration, on y répond dans la précipitation.

Les deux systèmes ensemble, pour une courte période

Quand c’est possible, l’ancien système reste ouvert en lecture seule pendant une courte période après l’ouverture du nouveau. Si un enregistrement semble manquant ou erroné, on peut consulter l’ancien système et comparer.

La fin de cette période est fixée dès le départ. Sinon, les deux systèmes cohabitent pendant des mois, et le débat sur celui qui fait foi recommence.

Ne pas migrer est aussi une décision

Tout ancien enregistrement n’a pas à être migré vers le nouveau système. Migrer des données dont la durée de conservation a expiré oblige l’organisation à continuer de les conserver inutilement. Pour les données personnelles, cela peut en plus devenir un manquement à une obligation.

La migration est un bon moment pour faire ce tri. Nous identifions les enregistrements dont la durée de conservation a expiré, nous les excluons de la migration avec l’accord de l’organisation et nous consignons la suppression. Le nouveau système démarre ainsi sur une base propre.

En bref

Une migration de données n’est pas un simple transfert, c’est un petit projet. Une migration menée sans inventaire, sans correspondance des champs, sans comptage en trois étapes, sans migration d’essai et sans plan de retour arrière fait perdre la confiance dans le nouveau système dès son premier jour.