Migrer en gardant les décisions

Revenir à l’ancien outil sans perdre le travail fait après la bascule

Pour qui : Un pilote doit être abandonné après que l’équipe a déjà modifié des tâches dans la destination.

Recherche documentaire le 8 novembre 2026 ; aucune application testée.

Notre avis

Définir les modifications récupérables et le délai de retour avant d’ouvrir le pilote aux données actives.

Dans l’ordre

  1. Une sauvegarde initiale ne contient pas le travail du pilote
  2. Revenir avec trois types de modification
  3. Préparer un retour d’essai contenant trois changements postérieurs à la bascule puis décider jusqu’à quand ce retour reste acceptable.

Pourquoi

  • La sauvegarde initiale ne contient pas les changements du pilote ; traiter ce delta évite de reconstituer les engagements de mémoire au retour.

Ce qui change le choix

Lorsque l’ancien service n’est plus accessible, parler de reprise indépendante et non de retour arrière garanti.

Une sauvegarde initiale ne contient pas le travail du pilote

Le retour vers l’ancien outil doit tenir compte de ce qui a été fait depuis la bascule. Nous définirions avant le pilote les modifications récupérables, celles qui demanderont une ressaisie et la dernière date à laquelle le retour reste praticable. La copie initiale ne possède pas ces changements futurs.

Ce protocole peut rester léger : une liste datée des objets modifiés et une règle de rapprochement suffisent parfois. Il devient plus coûteux lorsque les équipes utilisent des objets ou automatismes qui n’existent pas dans la source. Cette limite doit intervenir dans le choix du périmètre du pilote.

Revenir avec trois types de modification

Dans un projet témoin, changez une date, réaffectez une tâche et ajoutez un commentaire après import. Préparez le retour. Pour chaque changement, montrez la valeur reçue, le lien conservé et l’auteur ou la date encore disponibles. Identifiez ce qui ne peut pas être réinjecté proprement.

Nous n’appellerions pas retour arrière un redémarrage vide qui oblige l’équipe à reconstituer ses engagements de mémoire. Si l’ancien service n’est plus accessible, il faut parler de reprise dans un troisième support et prévoir un contrôle indépendant de cette reprise.

Asana indique que son import CSV prend en charge notamment responsables, dates, dépendances et champs personnalisés.

Limites

Analyse documentaire et méthode éditoriale. Les protocoles sont proposés, pas exécutés sur les logiciels. Les exemples chiffrés sont fictifs ; les fonctions dépendent du produit, du forfait, des droits et de la configuration.

Prochaine action

Préparer un retour d’essai contenant trois changements postérieurs à la bascule puis décider jusqu’à quand ce retour reste acceptable.

Preuves et sources

Ce qui relève d’un fait lu, d’une déclaration, de notre calcul, de notre méthode ou de notre avis. Notre méthode

  • Déclaration de l’éditeur. Asana indique que son import CSV prend en charge notamment responsables, dates, dépendances et champs personnalisés.

    Relevé du 8 novembre 2026. Édition ou périmètre : Documentation publique du 8 novembre 2026 ; produit et périmètre nommés dans le constat.

  • Notre méthode. Changer dates, responsables et commentaires après bascule, puis préparer un retour ; lister les trois types repris, perdus ou ressaisis.

    Daté du 8 novembre 2026. Édition ou périmètre : Protocole éditorial proposé ; aucune observation de compte client.