De nombreuses équipes recherchent actuellement des alternatives à Jira. Elles sont souvent soumises à des contraintes de temps pour trouver une solution adaptée à leurs besoins. Cependant, la migration ne se limite pas à déplacer des données d’un outil à l’autre. Cela signifie qu’il faut comprendre comment votre configuration existante s’adapte à un nouveau système, et envisager les solutions de contournement, les compromis et les améliorations potentielles.
Avec Jira Migrator d’OpenProject , nous soutenons ce processus étape par étape. Le 13 mai, il sera disponible sans feature flag dans le cadre d’OpenProject 17.4. En plus des fonctionnalités de base déjà disponibles, il permettra l’importation de champs personnalisés de base, qui est un élément essentiel dans la gestion des tâches et des projets.
Dans cet article, nous expliquons ce que cela signifie pour votre sortie de Jira.
La migration depuis Jira n’est pas un processus de transposition directe
Bien que de nombreux concepts fondamentaux tels que les lots de travaux, les flux de travail ou les champs personnalisés existent dans les deux systèmes, ils sont souvent nommés, structurés et gérés différemment.
Dans Jira, les configurations sont souvent adaptées à des projets individuels et étendues à l’aide de plugins. Certaines configurations basées sur des plugins dans Jira n’ont pas d’équivalent direct dans OpenProject et peuvent nécessiter des approches alternatives. Dans OpenProject, des cas d’utilisation similaires peuvent souvent être réalisés, mais nécessitent parfois une configuration ou une approche différente. Cela signifie que la migration de vos données ne consiste pas seulement à transférer des informations, mais aussi à les adapter à un nouveau système.
Par conséquent, les solutions de contournement et les ajustements font souvent partie du processus. L’ouverture à ces changements est la clé d’une migration réussie et peut également être l’occasion de simplifier et d’améliorer les structures existantes.
Aperçu d’OpenProject 17.4 : Jira Migrator disponible sans feature flag
Avec la version OpenProject 17.4 (prévue pour le 13 mai), Jira Migrator sera disponible et pourra être utilisé directement. Bien qu’il soit déjà fonctionnel, il n’est pas encore complet et il est donc publié en tant que version bêta.
*Image : Jira Migrator d’OpenProject version 17.4, disponible le 13 mai 2026.
Cette approche fait partie de la manière dont nous développons OpenProject. Avec des versions mensuelles, nous apportons continuellement des améliorations et mettons à disposition des fonctionnalités dès qu’elles apportent une réelle valeur ajoutée, même si elles ne sont pas encore totalement terminées. Cela permet aux équipes de commencer à travailler avec de nouvelles fonctionnalités plus tôt, de les tester dans des scénarios réels et de fournir un retour d’information qui influence directement le développement ultérieur.
Dans le même temps, cela signifie également que certaines limitations subsistent et que certains flux de travail peuvent nécessiter des ajustements. Nous pensons que cette approche transparente et itérative nous aide à améliorer Jira Migrator avec notre communauté. Consultez notre feuille de route pour savoir comment OpenProject prévoit de soutenir davantage la migration à partir de Jira et les principes fondamentaux de Jira.
*Image : Jira Migrator d’OpenProject après une importation réussie.
Bon à savoir : Jira Migrator lui-même est conçu comme un assistant guidé, rendant le processus de migration accessible et facile à suivre, même pour les utilisateurs sans connaissances techniques approfondies. Consultez la documentation relative à la migration Jira pour obtenir un guide étape par étape.
Importer des champs personnalisés de Jira vers OpenProject
Avec OpenProject 17.4, Jira Migrator prendra en charge l’importation de champs personnalisés de base, une partie essentielle de la gestion des tâches et des projets. En savoir plus sur les champs personnalisés dans OpenProject.
*Image : un lot de travaux dans OpenProject avec la section « importation Jira » et l’aperçu de l’importation dans l’onglet « Activité ».
Certains types de champs peuvent apparaître différemment dans OpenProject par rapport à Jira. Par exemple, les cases à cocher dans Jira sont représentées sous forme de listes, mais offrent une fonctionnalité similaire dans OpenProject. Bien que la fonctionnalité sous-jacente soit souvent comparable, la manière dont ces champs sont configurés et utilisés peut différer entre Jira et OpenProject.
Au fur et à mesure de notre développement, vous pouvez suivre les spécifications des « importations de champs personnalisés dans Jira Migrator » dans ce lot de travaux.
Comment les champs personnalisés sont traités lors de la migration
Une différence clé entre Jira et OpenProject est la façon dont les champs personnalisés sont gérés : dans Jira, les champs personnalisés peuvent être configurés différemment pour chaque projet. Dans OpenProject, les champs personnalisés sont définis à l’échelle du système, puis activés pour des projets spécifiques.
Lors de la migration, Jira Migrator s’adapte à cette différence. Si un champ personnalisé est utilisé de manière cohérente dans tous les projets, il sera créé en tant que champ personnalisé unique dans OpenProject. Si le même champ est configuré différemment via le « contexte du champ » dans plusieurs projets Jira, il sera divisé en champs personnalisés distincts.
Pour rendre cela transparent, l’outil de migration ajoute un suffixe avec l’identifiant du projet à chaque champ de fractionnement. Cela vous permet de voir clairement quel champ appartient à quel projet.
Placement des champs personnalisés importés
Lorsque des champs personnalisés sont importés, ils doivent être placés dans la présentation du lot de travaux. Pour s’assurer que tous les champs importés sont visibles, Jira Migrator les ajoute à une section de groupe dédiée appelée Importation Jira. À partir de là, les administrateurs peuvent revoir et ajuster l’emplacement de ces champs si nécessaire.
Ce à quoi vous devez vous attendre lorsque vous travaillez avec des données importées
Comme pour toute migration, certains ajustements peuvent être nécessaires après l’importation. Par exemple, il peut être nécessaire d’activer des champs personnalisés pour des projets spécifiques ou de les réorganiser dans la présentation du lot de travaux. En outre, les utilisateurs sont importés dans un état inactif pour permettre un processus d’importation fluide, en particulier pour les grands ensembles de données et les contraintes de licence.
Bien que ces étapes nécessitent un examen manuel, elles garantissent que vos données sont transférées d’une manière cohérente et gérable.
Foire aux questions (FAQ) sur la migration Jira
Un aperçu rapide des questions les plus courantes sur la migration depuis Jira et sur l’utilisation de Jira Migrator.
Devrais-je déjà utiliser Jira Migrator dans son état actuel ?
Jira Migrator est fonctionnel et peut déjà être utilisé, mais il est encore en cours de développement. Il convient mieux aux scénarios de test, d’évaluation et de migration précoce dans lesquels vous pouvez envisager des ajustements. Consultez notre article de blog sur Jira Migrator pour obtenir une vue d’ensemble.
Quelles sont les limites actuelles de Jira Migrator ?
Certaines fonctionnalités, telles que les champs personnalisés avancés ou les configurations basées sur des plugins, ne sont pas encore totalement prises en charge. En fonction de votre configuration Jira, certains éléments peuvent nécessiter des ajustements manuels ou des configurations alternatives. Les fonctionnalités suivantes seront bientôt disponibles : identificateurs de projets et d’enjeux, relations entre les enjeux et assignations de sprints. Les flux de travail, les autorisations et les schémas au niveau du projet seront disponibles ultérieurement. Veuillez consulter notre feuille de route de développement complète pour obtenir une liste actualisée.
À quelle quantité de travail manuel dois-je m’attendre après la migration ?
La migration n’est pas un processus entièrement automatisé. Bien que les données de base puissent être transférées, l’examen des champs personnalisés, l’ajustement des configurations et la validation de votre installation sont des étapes importantes après l’importation.
Pourquoi OpenProject publie-t-il Jira Migrator avant qu’il soit complètement terminé ?
OpenProject suit une approche de développement itérative avec des versions mensuelles. En mettant les fonctionnalités à disposition dès le début, les utilisateurs peuvent les tester dans des scénarios réels et fournir un retour d’information qui influe directement sur le développement ultérieur.
Nous demandons à nos utilisateurs de comprendre qu’une disponibilité précoce signifie également que tout ne fonctionne pas encore parfaitement. Le retour d’informations de la part de la communauté, par exemple par le biais de rapports de bugs, nous aide à identifier rapidement les problèmes et à y remédier dans les versions suivantes.
Aidez-nous à améliorer Jira Migrator
Nous vous invitons à essayer Jira Migrator avec OpenProject 17.4 et à découvrir comment il fonctionne avec vos propres données. Vos commentaires sont une part importante du développement ultérieur. Si vous rencontrez des problèmes ou si vous avez des suggestions, nous vous encourageons à nous en faire part. Cela nous aide à améliorer Jira Migrator et à mieux prendre en charge les scénarios de migration réels. Découvrez comment contribuer et partager vos commentaires dans notre Communauté, par exemple en signalant des bugs.
Si vous souhaitez partager des données anonymes issues de votre migration pour aider notre équipe de développement, veuillez nous contacter. Nous signerons volontiers un accord de confidentialité. Nous sommes impatients de recevoir vos commentaires et de continuer à améliorer Jira Migrator avec notre communauté.
