Préparer une migration de données sans mauvaise surprise

Pourquoi la migration fait dérailler les projets

La migration de données est souvent traitée comme une tâche technique de fin de projet : on exporte, on importe, on lance. C’est pourtant elle qui décide si vos équipes feront confiance au nouveau système dès le premier jour.

Des soldes clients faux, un stock qui ne correspond pas à l’entrepôt ou des doublons dans les contacts suffisent à renvoyer tout le monde vers les anciens fichiers.

1. Avant : préparer

• Délimiter le périmètreQuelles données migrer (clients, fournisseurs, produits, soldes, stocks, historique) et lesquelles laisser archivées.
• Inventorier les sourcesChaque système, tableur ou export d’où viennent les données, avec sa date et son niveau de fiabilité.
• Nommer un propriétaire par type de donnéesLa personne qui sait si un client, un prix ou un solde est exact, et qui validera la reprise.
• Nettoyer à la sourceDoublons, fiches inactives, formats incohérents : on corrige avant de migrer, pas après.
• Définir les règles de correspondanceComment chaque champ de l’ancien système se traduit dans Odoo : catégories, taxes, unités de mesure, conditions de paiement.
• Décider du sort de l’historiqueMigrer l’historique détaillé, seulement les soldes d’ouverture, ou garder l’ancien système consultable en lecture seule.

2. La migration d’essai : répéter

• Migrer sur une copieUne première reprise complète dans un environnement de test, jamais directement en production.
• Compter les enregistrementsLe nombre de clients, de produits et de documents correspond-il entre la source et Odoo ?
• Rapprocher les soldesComptes clients, comptes fournisseurs et balance de vérification : les totaux doivent concorder à la date de coupure.
• Vérifier les stocksQuantités et valeurs d’inventaire comparées à un décompte récent.
• Tester par rôleChaque équipe exécute ses opérations habituelles sur les données migrées et signale ce qui ne va pas.
• Corriger les règles, puis recommencerOn ajuste les scripts ou les règles de correspondance et on refait l’essai jusqu’à ce qu’il soit propre.

3. La bascule : exécuter

• Fixer une date de coupureLe moment à partir duquel on cesse de saisir dans l’ancien système.
• Geler les saisiesPendant la migration finale, personne ne modifie les données sources.
• Rejouer la migration validéeLa même procédure que l’essai, sans improvisation.
• Faire signer la validationLes propriétaires de données confirment les contrôles clés avant l’ouverture aux utilisateurs.
• Prévoir le retour arrièreCe qu’on fait, et qui décide, si un contrôle critique échoue.

4. Après : consolider

• Surveiller les premières semainesUn point de contact pour les écarts signalés, et des corrections rapides.
• Refaire les contrôles à la première fin de moisLe premier cycle de facturation et de clôture confirme que les données tiennent.
• Archiver les anciennes sourcesConserver une copie en lecture seule, selon vos obligations de conservation, puis retirer les accès en écriture.

En résumé

Une bonne migration se reconnaît à une chose : le jour du lancement, personne ne ressent le besoin de revérifier les chiffres dans l’ancien système. Pour y arriver, il faut préparer, répéter, puis exécuter une procédure déjà éprouvée.