Transformer son entreprise sans arrêter de travailler : organiser une migration progressive

Choisir une frontière qui a un sens métier

Basculer un département entier paraît simple sur un planning. Pourtant, ses dossiers peuvent dépendre de plusieurs équipes. Une meilleure frontière peut être un type de prestation, un groupe de clients ou les nouveaux dossiers à partir d’une date. Le lot doit être assez complet pour que son fonctionnement soit observable.

Évitez un découpage qui oblige l’équipe à chercher chaque information dans deux endroits sans règle stable. La migration n’est pas seulement le déplacement d’une base : c’est un changement de référence opérationnelle. Pour chaque lot, il faut savoir où créer, modifier, valider et retrouver le dossier.

Préparer les données avant la bascule

Inventoriez les clients, pièces, statuts et liens entre objets. Conservez les identifiants qui permettent de rapprocher l’ancien et le nouveau système. Un total de lignes identique ne prouve pas que les factures sont liées aux bons clients ni que les documents restent consultables.

La documentation d’import d’Odoo souligne notamment l’utilité des identifiants externes pour les mises à jour et les relations. Elle rappelle aussi qu’un import n’est pas simplement annulable. La recommandation pratique est de tester sur une copie, de contrôler un échantillon de bout en bout et de préparer la restauration avant l’opération sur les données de travail.

Pour approfondir : Export and import data — Odoo 19.0 documentation

Limiter la période de double exploitation

Deux systèmes ouverts en écriture peuvent diverger rapidement. Définissez, pour chaque donnée, lequel fait référence pendant la transition. Si une double saisie reste nécessaire, attribuez son rapprochement et sa durée. Une solution provisoire sans date de sortie devient souvent une charge permanente.

Prévoyez le temps nécessaire pour terminer les dossiers anciens. Tout migrer peut être plus coûteux que de conserver un historique consultable, tandis que laisser des dossiers actifs dans un outil abandonné crée un risque de suivi. Le choix dépend des besoins réels de consultation, de modification et de conservation, à examiner avec les responsables concernés.

Prévoir le retour avant d’en avoir besoin

Un retour en arrière doit préciser les données créées depuis la bascule. Restaurer la sauvegarde de la veille peut supprimer des commandes ou validations récentes. Il faut donc prévoir comment les extraire, les rapprocher et les réintroduire, ou définir un point au-delà duquel la correction en avant est préférable.

Les documentations de sauvegarde distinguent plusieurs mécanismes avec leurs hypothèses. Pour votre projet, exigez une répétition de restauration, pas uniquement la présence d’un fichier. Mesurez le temps nécessaire pour retrouver un service utilisable. Une sauvegarde techniquement valide mais incompréhensible à l’équipe d’exploitation ne constitue pas un plan de continuité suffisant.

Notre avis : consacrer un budget à la transition

La charge de migration comprend formation, nettoyage, contrôle et assistance pendant les premiers jours. Si elle est supposée absorbée sans réduire aucune autre tâche, le planning repose sur un travail invisible. Désignez des personnes disponibles et protégez les périodes où elles doivent tester.

Quelle activité ne pouvez-vous pas interrompre demain matin ? Quelle donnée serait impossible à reconstituer ? Ces réponses doivent déterminer l’ordre des lots et les critères d’arrêt. Nous privilégions une progression qui laisse l’entreprise servir ses clients, avec une décision de passage explicite à chaque étape, plutôt qu’un calendrier ambitieux dont personne ne peut expliquer le scénario de repli.