Migrer de Jira vers Polybase : le guide pas à pas
Préparez votre migration depuis Jira : correspondance des champs par CSV, contrôle des workflows et liste de vérification du pilote. Ce qu’il faut transférer, vérifier et conserver avant de passer à Polybase.Sujet Gestion de projetPublié le 8 septembre 2026Temps de lecture 5 minAuteur Polybase
Une migration depuis Jira réussit lorsque l’équipe peut continuer à livrer avec des responsabilités claires, des statuts fiables et un accès au contexte d’origine. Déplacer des lignes n’est qu’un volet du changement. Les décisions difficiles portent sur les champs qui comptent, les workflows à conserver et l’historique qui doit rester accessible.
Ce guide explique comment préparer le passage de Jira à Polybase à partir d’un tableur de tâches relu et d’un pilote maîtrisé. Polybase prend en charge l’import de tâches depuis un tableur ; il ne s’agit pas d’une restauration complète d’une sauvegarde Jira. Traitez les commentaires, les pièces jointes, la hiérarchie, l’historique des modifications et les données propres aux applications tierces comme des besoins de migration distincts.
1. Définir le périmètre avant d’exporter depuis Jira
Commencez par un seul projet et séparez le travail en cours de l’historique de référence. Incluez les tâches ouvertes, les engagements à venir et les travaux récemment terminés qui aident à comprendre les livraisons actuelles. Décidez explicitement du sort des enregistrements plus anciens plutôt que de copier tout le backlog sans l’avoir relu.
Dressez la liste des fonctions dont votre équipe ne peut pas se passer : rapports de sprint, dépendances, workflows personnalisés, suivi du temps, demandes de service ou applications du marketplace. Exigez pour chaque besoin essentiel un workflow démontré dans l’outil cible. Polybase peut être évalué pour la combinaison de messagerie, de tâches et de documents ; les besoins spécialisés propres à Jira appellent une décision d’acceptation distincte.
2. Exporter un échantillon représentatif d’éléments de travail
Dans Jira Cloud, limitez la recherche d’éléments de travail au projet et au périmètre convenus, puis utilisez le menu d’export pour télécharger un CSV contenant les champs nécessaires. Atlassian documente les deux options : champs actuels ou tous les champs. Ces indications concernent la version Cloud ; si vous utilisez Data Center, consultez la documentation de votre édition.
Conservez l’export d’origine intact et préparez une copie de travail à part. Choisissez des exemples dotés d’une longue description, sans responsable, avec un statut personnalisé, plusieurs étiquettes et une échéance. Un fichier qui passe pour cinq tâches simples peut très bien échouer sur les enregistrements les plus importants.
3. Faire correspondre les champs Jira à ceux de Polybase, en connaissance de cause
Dans l’assistant d’import de tâches de Polybase, choisissez la source tableur, importez le fichier préparé et vérifiez la correspondance des colonnes. Passez ensuite en revue les statuts, les priorités et les personnes avant de confirmer l’import. Les correspondances suggérées sont un point de départ : le responsable du projet doit en valider le sens.
Le tableau ci-dessous couvre un jeu de départ réaliste. Conservez la clé Jira d’origine et l’URL source dans la description ou dans le registre de migration, même si les identifiants de tâches peuvent être repris. Ne supposez pas que chaque champ personnalisé a un équivalent natif, ni qu’un nom d’utilisateur exporté désigne sans ambiguïté un collègue actif.
| Champ source | Destination ou traitement | Point de contrôle |
|---|---|---|
| Summary / Description | Titre / description de la tâche | Mise en forme et critères d’acceptation |
| Status / Priority | Correspondance validée des statuts / priorités | Le sens, pas seulement des libellés identiques |
| Assignee / Reporter | Membre assigné / créateur | Correspondance des comptes et personnes parties |
| Labels / Due date | Étiquettes / échéance | Valeurs multiples et interprétation des dates |
| Issue key / custom fields | Identifiant lorsque c’est pris en charge ; sinon texte de référence | Conflits et informations à traiter séparément |
4. Reconstruire les règles de fonctionnement autour des tâches
Un statut intitulé « Revue » ne reprend pas une règle de transition de Jira. Documentez qui peut faire avancer une tâche, ce qui doit être terminé au préalable et qui valide le résultat. Recréez et testez les contrôles nécessaires dans l’outil cible. Polybase propose des statuts de tâches configurables et des validations de statut, mais votre configuration Jira existante ne devient pas équivalente du seul fait que les colonnes se ressemblent.
Validez la configuration avec un vrai relais de travail : une demande devient une tâche, la personne responsable ajoute le brief utile, un relecteur demande une correction et la tâche repasse en validation. Vérifiez la liste, le tableau et la frise chronologique sur les mêmes enregistrements. Ne reconnectez les notifications et les intégrations de développement qu’une fois ce parcours de base fiable.
5. Rapprocher les données du pilote avant la bascule définitive
Créez un registre de migration avec la clé source, la référence de destination, le lot, le résultat et la personne responsable des exceptions. Comparez les totaux par statut et par responsable, pas seulement le nombre total d’enregistrements. Un total identique peut masquer un projet dont toutes les tâches ont le mauvais statut.
Prenez une décision distincte pour les commentaires, les pièces jointes, les relations entre épopées et sous-tâches, les journaux de temps, l’historique des sprints et les règles d’automatisation. La correspondance des tâches par tableur décrite ici ne garantit pas le transfert de ces objets. Recréez les relations nécessaires ou conservez une référence accessible, selon le périmètre convenu. Réglez les écarts essentiels avant la bascule.
- Comparez à la source un échantillon de titres, de descriptions, d’étiquettes et de dates.
- Testez l’accès des membres et vérifiez qui peut modifier les statuts protégés.
- Analysez chaque ligne en échec avant de relancer ; rapprochez les lignes réussies pour éviter les doublons.
- Convenez d’une fenêtre de mise à jour finale, relevez les modifications faites pendant le pilote et désignez la personne qui valide la bascule.
- Gardez la référence source convenue accessible jusqu’à ce que les responsables acceptent les nouveaux enregistrements de travail.
Questions fréquentes
Puis-je importer des tâches Jira dans Polybase au format CSV ?
Polybase dispose d’un outil d’import de tâches depuis un tableur, avec correspondance paramétrable des champs et des valeurs. Préparez un export CSV de Jira et validez un échantillon par cette voie. Cela couvre les champs de tâches mis en correspondance ; il ne faut pas y voir un importeur complet de projets Jira.
Les commentaires, les pièces jointes et l’historique des sprints Jira sont-ils transférés ?
Ne présumez pas qu’ils passent par l’assistant d’import par tableur : ils sortent de la correspondance de champs décrite dans ce guide. Recensez-les séparément et convenez d’une méthode de conservation ou de recréation avant de déplacer les projets essentiels.
Combien de temps dure une migration depuis Jira ?
La durée dépend du volume d’enregistrements actifs, des champs personnalisés, des intégrations et de l’historique à conserver. Estimez-la à partir d’un pilote représentatif et de ses exceptions non résolues plutôt que d’un nombre de jours fixe.