Migrer d’un outil à l’autre : la décision de changer d’outil est prise, pour l’une des rares raisons qui la justifient. Reste l’opération elle-même, qui est rarement anticipée et se déroule presque toujours de la même façon : on exporte tout, on importe tout, et l’on se retrouve avec un nouvel outil contenant exactement le désordre de l’ancien, augmenté des éléments cassés par la conversion. Une migration réussie n’est pas un transfert intégral — c’est un tri suivi d’un transfert partiel.
Ce qu’on perd toujours
Aucune migration ne conserve tout, et il vaut mieux le savoir avant que le découvrir. Les éléments les plus fragiles sont les mêmes d’un outil à l’autre : les tâches récurrentes, les pièces jointes, les liens entre éléments, l’historique des éléments terminés.
Les mises en forme et les structures propriétaires disparaissent également. Une organisation qui reposait sur des vues personnalisées ou des étiquettes de couleur devra être reconstruite, car ces éléments n’ont pas d’équivalent standard.
Anticipez donc ces pertes en les listant à l’avance. La question n’est pas de les éviter mais de décider lesquelles comptent : certaines justifient une reconstruction manuelle, la plupart ne justifient rien du tout.
Trier avant de migrer, pas après
L’erreur centrale consiste à tout transférer en se promettant de faire le ménage ensuite. Ce ménage n’a jamais lieu, et l’on paie deux fois : une fois en temps de migration, une fois en encombrement durable.
La migration est au contraire l’occasion idéale d’un tri sévère, parce que chaque élément doit de toute façon être examiné. Appliquez la question habituelle : si cet élément n’est jamais retrouvé, que se passe-t-il ?
Attendez-vous à ne conserver qu’une fraction de l’existant. Sur un système de tâches tenu depuis deux ans, il n’est pas rare que la moitié des éléments soient périmés, en doublon, ou déjà traités sans avoir été clos.
La règle de l’archive figée
Pour tout ce qui ne mérite pas d’être migré sans mériter d’être supprimé, la solution est l’archive figée : un export complet de l’ancien outil, dans un format lisible, rangé quelque part et jamais rouvert.
Cette archive coûte quelques minutes et supprime l’essentiel de l’anxiété liée à la migration. On ne renonce à rien, on déplace simplement hors du champ de vision ce qui n’a pas d’utilité active.
Choisissez un format ouvert et durable pour cette archive — texte, tableur, document standard — plutôt qu’un format propriétaire qui exigerait de réinstaller l’ancien outil pour être relu.
La période de double saisie
La tentation est de basculer d’un coup. C’est risqué : un outil découvert la semaine même contient forcément des surprises, et le système est alors moins fiable au moment précis où l’on ne veut rien perdre.
Prévoyez plutôt une période de recouvrement d’une à deux semaines pendant laquelle l’ancien outil reste consultable en lecture seule. Vous n’y ajoutez plus rien, mais vous pouvez y retourner chercher ce qui manque.
Évitez en revanche la double saisie réelle — alimenter les deux outils en parallèle. Elle double la charge, produit des divergences, et se termine invariablement par l’abandon du nouvel outil au premier moment de surcharge.
L’ordre de migration
Migrez d’abord ce qui est actif : les tâches de la semaine, les projets en cours, les échéances proches. Cette partie représente peu de volume et permet de travailler immédiatement dans le nouvel outil.
Traitez ensuite le stock différé, en appliquant le tri. Cette étape peut s’étaler sur plusieurs sessions courtes plutôt que d’être menée d’un bloc, ce qui la rend nettement plus supportable.
Ne migrez le reste que sur demande : quand vous cherchez quelque chose et ne le trouvez pas dans le nouvel outil, allez le chercher dans l’archive et transférez-le à ce moment-là. Ce mécanisme opportuniste traite exactement ce qui sert, et rien d’autre.
Les pièges techniques
Vérifiez l’export avant de vous engager. Certains outils n’exportent qu’un format partiel, d’autres perdent les caractères accentués, d’autres encore imposent un abonnement actif pour récupérer ses propres données.
Testez la conversion sur un échantillon avant de traiter l’ensemble. Une trentaine d’éléments suffisent à révéler les problèmes de format, de dates, d’accents ou de caractères spéciaux — bien plus efficacement qu’un import massif qu’il faudra annuler.
Conservez enfin l’export brut d’origine, avant toute manipulation. C’est votre filet de sécurité si la conversion se révèle défectueuse, et il ne coûte rien à conserver.
La date de bascule
Fixez une date explicite à partir de laquelle plus rien n’est ajouté dans l’ancien outil. Sans cette date, la migration s’étire sur des mois et vous entretenez deux systèmes incomplets.
Choisissez un moment de faible charge — une semaine calme, un retour de congés, un début de trimestre. Basculer pendant une période de forte activité garantit un retour à l’ancien outil dès la première difficulté.
Annoncez cette date à ceux qui interagissent avec votre système, le cas échéant. Et supprimez ou désinstallez l’ancien outil une fois la période de recouvrement écoulée : tant qu’il reste accessible d’un clic, une partie de vous continuera de l’utiliser.
En résumé
Une migration réussie est un tri suivi d’un transfert partiel, jamais un transfert intégral. Listez à l’avance ce qui sera perdu, triez avant de migrer plutôt qu’après, et rangez le reste dans une archive figée au format ouvert. Migrez d’abord l’actif, laissez le stock venir à la demande, et fixez une date de bascule ferme dans une période de faible charge.