Atlassian ayant annoncé la fin de vie de Jira Data Center en mars 2029, de nombreuses entreprises réfléchissent activement à la marche à suivre. OpenProject est devenu l’une des solutions open source les plus performantes pour répondre à cette question : il s’agit d’une plateforme autonome et auto-hébergée qui regroupe, au sein d’un seul et même outil, la gestion de projet, la gestion de produit, le suivi des tickets, les diagrammes de Gantt, les tableaux agiles et la collaboration en équipe.
Mais la migration de la chaîne d’outils de gestion de projet d’une organisation ne se résume jamais à une simple exportation de données. Cela concerne à la fois les personnes, les processus et les données. La question qui nous est le plus souvent posée par les équipes qui envisagent de quitter Jira est simple : comment devons-nous concrètement procéder à la migration ?
Il n’y a pas une seule bonne réponse. La stratégie à adopter dépend de la taille de votre organisation, de la complexité de votre configuration Jira, de votre tolérance au risque, des interdépendances entre les équipes et de votre culture d’entreprise. Cet article vous présente les trois principales stratégies de migration, leurs avantages et inconvénients respectifs ainsi que les scénarios auxquels elles se prêtent le mieux, et se termine par la démarche que nous recommandons aujourd’hui à la plupart des entreprises.
Navigation rapide :
- Une brève note concernant l’outil OpenProject Jira Migrator
- Trois stratégies de migration
- Comparaison des stratégies en un coup d’œil
- Notre recommandation : commencer par une phase pilote, puis passer à un déploiement par vagues
- Ce qui distingue les migrations réussies de celles qui s’avèrent pénibles
- Les principaux risques à surveiller
- En résumé
- Pour en savoir plus
Quelques mots sur l’outil OpenProject Jira Migrator
Avant d’aborder la question de la stratégie, il est utile de savoir de quels outils nous disposons.
OpenProject intègre un outil de migration vers Jira, disponible depuis début 2026 et actuellement en version bêta. Il se connecte à Jira Data Center 10.x et 11.x via un jeton d’accès personnel et importe les données dans OpenProject via l’API. Jira Cloud n’est pas encore pris en charge, mais sa prise en charge est prévue.
Ce que l’outil de migration importe aujourd’hui :
- Projets (c’est vous qui choisissez lesquels)
- Problèmes, notamment le résumé, la description, les pièces jointes, l’historique et les commentaires
- Utilisateurs (nom, adresse e-mail, appartenance à un projet) et groupes
- Statuts et types de problèmes
- Champs personnalisés pour lesquels il existe une correspondance dans OpenProject
Ce qui figure toujours dans la feuille de route et n’a pas encore été abordé :
- Relations entre les tickets
- Affectation des sprints
- Flux de travail au niveau du projet
- Autorisations
- Schémas
- Étiquettes
- Versions corrigées et versions concernées
- Composants
[!REMARQUE] Jira Migrator fait l’objet d’un développement actif, et nous publions des améliorations chaque mois. Consultez systématiquement la documentation relative à la migration vers Jira ainsi que les notes de mise à jour avant de planifier une migration en production. Certaines lacunes qui existent aujourd’hui auront peut-être déjà été comblées d’ici à ce que vous commenciez.
Trois stratégies de migration
Stratégie A : « Big Bang » (basculement direct)
Toutes les équipes et tous les projets migreront de Jira vers OpenProject à une date de basculement unique et prédéfinie. Jira est mis hors service immédiatement après.
Avantages : la transition s’effectue en une seule étape ; les coûts d’exploitation à long terme sont réduits puisqu’il n’y a pas de fonctionnement en parallèle ; la communication est simplifiée car tout le monde effectue la transition en même temps ; il n’est pas nécessaire de synchroniser deux systèmes ; et toutes les équipes travaillent sur un seul outil à la fois.
Inconvénients : le risque est élevé, car tout échec de la migration affecte l’ensemble de l’organisation d’un seul coup. La demande de formation se concentre sur une courte période ; une restauration implique de rétablir Jira à partir d’une sauvegarde, ce qui entraîne des perturbations, et les efforts liés à la gestion du changement s’accumulent dans un délai très court.
Idéal pour : les petites organisations (moins de 250 utilisateurs), les configurations Jira simples comportant peu de champs personnalisés, ou les situations dans lesquelles les licences Jira expirent à une date fixe.
Stratégie B : Migration par étapes / par vagues
Les équipes ou les unités opérationnelles migrent par vagues successives, sur plusieurs semaines ou plusieurs mois. Chaque vague met en pratique les enseignements tirés de la précédente.
Avantages : le risque est limité, car les problèmes rencontrés au cours d’une phase n’affectent pas toutes les équipes. Le Jira Migrator peut être ajusté d’une vague à l’autre, à mesure que de nouvelles fonctionnalités sont mises en place, que les supports de formation et d’assistance s’améliorent progressivement, que les premiers utilisateurs deviennent des ambassadeurs en interne pour les vagues suivantes et que les efforts de gestion du changement sont répartis dans le temps.
Inconvénients : Jira et OpenProject fonctionnent en parallèle pendant la période de migration ; les dépendances entre les équipes se complexifient lorsque celles-ci utilisent des outils différents ; et une gouvernance claire est nécessaire pour déterminer l’ordre des phases.
Idéal pour : les grandes entreprises comptant de nombreuses équipes et menant des projets de nature variée. Il s’agit de loin de l’approche la plus courante dans le monde de l’entreprise.
Stratégie C : Approche « Pilot-First » (valivation du concept)
Une seule équipe ou un seul projet effectue d’abord la migration à titre de démonstration de faisabilité. Ces conclusions sont consignées et servent à affiner le guide de migration avant tout déploiement à plus grande échelle.
Un projet pilote type se déroule comme suit : choisissez une équipe présentant très peu de dépendances externes, identifiez les promoteurs du projet, cartographiez les processus actuels lors d’un atelier, préparez un environnement de test, laissez l’équipe le tester, convenez d’une date de basculement, geler Jira (de préférence pendant un week-end), effectuez la migration vers l’environnement de production, puis validez OpenProject pour une utilisation quotidienne.
Avantages : le risque est très faible, puisqu’une seule équipe est concernée. Cela permet de valider à la fois Jira Migrator et OpenProject dans un environnement réel, de fournir des preuves concrètes aux parties prenantes et à la direction, de mettre en évidence très tôt les problèmes de qualité des données et les incohérences, de recueillir les retours d’expérience des utilisateurs afin d’améliorer les supports de formation, et de faire des premiers utilisateurs des ambassadeurs pour les migrations ultérieures.
Inconvénients : le double fonctionnement se poursuit pendant la période pilote, et l’équipe chargée du projet pilote doit assumer une charge de travail supplémentaire pendant la phase de test.
Idéal pour : les organisations qui découvrent OpenProject et souhaitent tester l’outil avant de s’engager, ainsi que celles qui voient grand mais préfèrent commencer modestement. Un projet pilote constitue également une excellente première étape dans le cadre d’une migration par vagues.
Comparaison des stratégies en un coup d’œil
| Stratégie | Niveau de risque | Frise chronologique | Périmètre par phase | Action de formation et de gestion du changement | Coût d’exploitation | Outillage essentiel |
|---|---|---|---|---|---|---|
| Big Bang | Haut | Court | Une organisation complète en un clin d’œil | Condensé | Faible (pas de fonctionnement en parallèle) | Jira Migrator |
| Par étapes / Par vagues | Moyenne | Moyen à long | Une vague à la fois | Réparti dans le temps. Les premiers à adopter cette approche deviennent les moteurs du changement. | Moyen (deux passages par vague) | Jira Migrator |
| Le pilote d’abord | Très faible | Moyen à long | Une équipe, puis des vagues | Faible, réservé dans un premier temps aux premiers utilisateurs. | Faible (pilote uniquement) | Jira Migrator |
Notre recommandation : commencer par une phase pilote, puis passer à un déploiement par vagues
Compte tenu de l’état actuel de Jira Migrator (prêt pour la production en ce qui concerne les données de base, mais encore en phase de maturation pour les fonctionnalités avancées), des meilleures pratiques en matière de migration d’entreprise et des exigences de la gestion du changement au sein des organisations réelles, la démarche que nous recommandons à la plupart des organisations consiste à commencer par un projet pilote contrôlé, puis à migrer le reste de l’organisation par vagues successives.
Voici à quoi cela ressemble concrètement.
Phase 1 : Préparation (4 à 6 semaines)
- Choisissez un projet pilote d’une complexité modérée, ni le plus simple, ni le plus compliqué. L’absence de dépendances externes, ou un nombre limité de celles-ci, constitue un atout.
- Installez et configurez OpenProject (en auto-hébergement ou dans le cloud), tant pour les environnements de test que de production, en adaptant les capacités de l’infrastructure en conséquence.
- Faites l’inventaire de vos données Jira : répertoriez les projets, les champs personnalisés, les workflows, les types de tickets, les groupes d’utilisateurs et les intégrations (GitHub, liens vers Confluence, etc.).
- Vérifiez la connectivité de l’API afin qu’OpenProject puisse récupérer les données depuis Jira.
- Formez les administrateurs et l’équipe de pilotage, et expliquez clairement aux participants comment obtenir de l’aide.
[!CONSEIL] Vous pouvez d’ores et déjà effectuer une migration pilote grâce à l’outil Jira Migrator d’OpenProject. Il n’y a aucune raison d’attendre. Si vous avez besoin d’un coup de main, notre équipe peut apporter son soutien directement au projet pilote.
Phase 2 : Migration pilote (2 à 4 semaines)
- Exécutez l’outil de migration sur les projets de l’équipe pilote dans l’environnement de préproduction.
- Vérifier les données migrées : problèmes, descriptions, pièces jointes, affectations d’utilisateurs.
- Répertoriez les lacunes : champs personnalisés, relations, tout ce que l’outil de migration ne prend pas encore en charge.
- Configurez OpenProject manuellement afin de combler ces lacunes là où cela s’avère nécessaire.
- Effectuez les tests d’acceptation par les utilisateurs (UAT) dans l’environnement de préproduction.
- Une fois que les tests d’acceptation utilisateur (UAT) ont donné un résultat positif, répétez la migration vers l’environnement de production.
- Convenez d’une date de mise en service avec l’équipe chargée du projet pilote, puis procédez à la migration.
- Recueillez chaque semaine les retours d’expérience, consignez les enseignements tirés et mettez à jour le guide pratique.
Phase 3 : Déploiement par vagues (2 à 3 semaines par vague)
- Classez les vagues par niveau de complexité des équipes : commencez par les équipes les plus simples, puis passez aux plus complexes.
- Exécutez l’outil de migration par vague pour les projets sélectionnés.
- Réutilisez la liste de contrôle de préparation issue de la phase pilote. C’est désormais un guide pratique.
- Proposez des formations ciblées et des permanences pour chaque vague.
- Recueillez des retours d’expérience chaque semaine et mettez en pratique les enseignements tirés lors des phases suivantes.
- Suivi des indicateurs : durée de la migration, scores de qualité des données, satisfaction des utilisateurs.
Phase 4 : Basculement et mise hors service
- Une fois toutes les vagues terminées, définissez une date finale de mise en lecture seule pour Jira (mode archive).
- Veillez à ce qu’une instance Jira en lecture seule reste disponible à des fins de référence historique pendant environ trois mois.
- Désactivez les licences et l’infrastructure Jira à l’issue de la période d’archivage.
- Organisez une rétrospective après la migration et mettez à jour la documentation relative à vos processus internes.
Ce qui distingue les migrations réussies de celles qui s’avèrent pénibles
Les outils ont leur importance, mais les migrations qui se déroulent sans encombre sont presque toujours celles où les équipes prennent au sérieux certaines pratiques non techniques.
Qualité des données. Nettoyez vos données avant la migration. Clôturez les tickets obsolètes, supprimez les champs personnalisés inutilisés et résolvez les doublons d’utilisateurs. Ne procédez jamais à la migration des données de production sans disposer de sauvegardes vérifiées à la fois de Jira et d’OpenProject. Utilisez le mode de vérification de l’outil de migration pour contrôler les importations avant de les valider.
Important
Une fois qu’une importation a été validée dans Jira Migrator, elle ne peut plus être annulée. Veillez à toujours vérifier au préalable les données importées en mode prévisualisation.
Gestion du changement. Communiquez dès le début et régulièrement, et ne sous-estimez pas l’importance de la communication dans le cadre d’une migration. Veuillez communiquer le calendrier et les répercussions au moins quatre semaines avant chaque vague. Désignez des « champions » OpenProject au sein de chaque équipe afin de favoriser l’entraide entre collègues. Organisez des ateliers pratiques, ne vous contentez pas de fournir de la documentation, car c’est en faisant que l’on apprend. Veillez à maintenir un canal de retour d’information ouvert tout au long de la migration, qu’il s’agisse d’un canal de discussion, d’une adresse e-mail dédiée ou d’un projet OpenProject Helpdesk dédié. Nous serons également ravis de vous accompagner dans ce processus de changement grâce à des bonnes pratiques, des formations ou des services de conseil sur mesure, adaptés à vos besoins.
Mesures de sécurité techniques. Effectuez toujours vos tests en environnement de préproduction avant de passer en production. L’outil de migration intégré nécessite un jeton d’accès personnel de niveau administrateur fourni par Jira ; veillez donc à bien protéger ces identifiants.
Validation après la migration. Comparez le nombre de tickets, le nombre de pièces jointes et les appartenances des utilisateurs entre Jira et OpenProject. Surveillez les performances d’OpenProject après chaque vague, en particulier lors d’importations volumineuses. Archivez les projets Jira plutôt que de les supprimer jusqu’à ce que chaque équipe ait confirmé la réussite de la migration, et mettez à jour votre documentation interne destinée aux développeurs et aux responsables de projet afin qu’elle reflète les workflows d’OpenProject.
Les principaux risques à surveiller de près
| Risk | Gravité | Atténuation |
|---|---|---|
| Perte de données lors de la migration | Haut | Sauvegardez les deux systèmes ; utilisez le mode de révision avant de valider ; effectuez d’abord un test pilote. |
| Échec de l’adoption par les utilisateurs | Haut | Investissez dès le début dans la gestion du changement, la désignation de relais et la formation ; recueillez en permanence les retours d’expérience. On ne communique jamais trop. Impliquez les utilisateurs dès le début du processus de changement afin qu’ils s’approprient ce changement. |
| Erreurs de mappage des champs personnalisés | Moyenne | Mappages de documents ; valider des échantillons avant la migration complète. |
| Instabilité de l’outil de migration (version bêta) | Faible à moyen | Utilisez un environnement de test ; vérifiez les résultats de la migration. |
In summary
La migration de Jira vers OpenProject est un projet d’envergure, mais tout à fait réalisable. OpenProject Jira Migrator offre déjà une base solide permettant d’importer, avec un effort technique limité, les données essentielles dont dépendent la plupart des équipes. La feuille de route comble, mois après mois, les lacunes restantes.
La stratégie que nous recommandons, à savoir une approche « Pilot-First » suivie d’une migration par vagues, permet de trouver un juste équilibre entre la réduction des risques et l’efficacité opérationnelle. Cela permet aux outils de mûrir, donne aux équipes le temps de se familiariser avec OpenProject et garantit que chaque phase tire parti des enseignements de la précédente. Une migration de type « Big Bang » ne doit être envisagée que si votre organisation est de petite taille, si la configuration de Jira est simple et si l’outil de migration couvre tous vos besoins.
La réussite dépend autant de la mise en œuvre technique que de la gestion du changement. C’est l’investissement dans la formation des utilisateurs, dans la désignation de référents internes et dans une communication claire qui détermine si le nouvel outil sera bien accueilli ou s’il se heurtera à une résistance, quelle que soit la qualité de la migration des données. Pour trouver davantage d’inspiration sur la manière de mener une transition du logiciel propriétaire vers le logiciel libre, nous vous recommandons de visionner l’intervention de Rosanna Sibora (CPO chez OpenProject) lors du FOSDEM (https://fosdem.org/2026/schedule/event/7YMJST-how-to-lead-change-to-open-source/).
La prochaine étape la plus utile que vous puissiez entreprendre cette semaine consiste à sélectionner une équipe pilote et à migrer son premier projet. Vous en apprendrez davantage auprès d’un seul pilote expérimenté qu’au cours de trois mois de réunions de planification. Commencez à planifier votre première migration et faites évoluer vos projets et votre organisation, étape par étape, vers votre nouvelle solution numérique entièrement souveraine.
Pour en savoir plus
- Documentation relative à la migration d’OpenProject vers Jira
- OpenProject, une alternative à Jira Data Center
- Feuille de route d’OpenProject : abandon de Jira
- Favoriser l’adoption par les utilisateurs et piloter la transition de Jira vers OpenProject
- Votre solution pour abandonner Jira : OpenProject Jira Migrator
- Guide de démarrage d’OpenProject
*Vous avez des questions concernant les outils de migration d’OpenProject ou sur la manière de planifier votre sortie de Jira ? Contactez-nous.
