Contexte — fin de vente et EOL Jira Data Center
Atlassian a officiellement cessé la vente de nouvelles licences Jira Data Center aux nouveaux clients le 30 mars 2026. Les clients Data Center existants conservent la possibilité d'acheter des extensions de licences et des renouvellements jusqu'au 30 mars 2028, date après laquelle ces options disparaissent également. L'étape finale est l'EOL du 28 mars 2029 : à cette date, les produits Data Center passent en mode lecture seule. Vos données restent accessibles à la consultation, mais toute création ou modification de ticket, de projet ou de configuration devient impossible.
Ce calendrier laisse en apparence du temps. En pratique, une migration de gestion de projet mobilise des semaines de préparation : inventaire des projets actifs, nettoyage des tickets obsolètes, reconfiguration des workflows, formation des équipes, et période de double-run pour valider la continuité. Attendre 2028 revient à conduire la migration en urgence, sous pression de la date butoir, avec un risque élevé de perte de données ou d'interruption de production.
Cinq raisons de migrer maintenant plutôt qu'en urgence
- Coût des licences Data Center par siège — le modèle de tarification Data Center facture par utilisateur actif, avec des paliers annuels dont les révisions tarifaires Atlassian sont hors de votre contrôle. Partir maintenant permet de calculer sereinement le TCO de la nouvelle solution.
- Calendrier verrouillé, sans surprise — la date du 28 mars 2029 est définitive. Une migration menée en 2026 ou 2027 laisse le temps d'un run en parallèle et d'un retour arrière éventuel ; une migration menée en 2028 ne laisse ni l'un ni l'autre.
- Risque de lecture seule à l'EOL — si votre instance Data Center n'est pas migrée au 28 mars 2029, vos équipes perdent la capacité de créer ou modifier des tickets. Un incident bloquant pendant la période de gel est un scénario à éliminer en amont.
- Contrôle des données et des sauvegardes — sur un VPS à accès root, vous choisissez la fréquence des sauvegardes, le chiffrement, la rétention et la localisation des données. Aucun tiers ne décide de la durée de rétention à votre place.
- Opportunité de nettoyage — une migration est le moment idéal pour archiver les projets inactifs, harmoniser les statuts et les types de tickets, et repartir sur une base propre plutôt que de transférer des années d'artefacts accumulés.
- Stabilité des intégrations — les connecteurs Jira (CI/CD, Confluence, Slack, plugins tiers) devront de toute façon être reconstruits lors du passage à une nouvelle plateforme. Le faire aujourd'hui permet de choisir des intégrations ouvertes, basées sur des API standard, sans dépendance à un écosystème propriétaire.
- Suppressions de plugins non portées — Atlassian a annoncé que certains plugins Data Center ne seront pas portés au-delà de 2028 ; les fonctionnalités qui en dépendent doivent être identifiées et remplacées avant l'EOL.
Prérequis chiffrés avant de commencer
Avant de choisir entre OpenProject et Plane, vérifiez que votre VPS couvre les exigences minimales de chaque outil. OpenProject requiert un processeur quad-core à au moins 2 GHz et 4 Go de RAM pour accueillir jusqu'à 200 utilisateurs au total — c'est la configuration recommandée par l'éditeur pour un usage de production stable. En dessous, les opérations d'arrière-plan (notifications, mise à jour des attributs calculés) ralentissent. Plane nécessite au minimum 2 vCPU, 4 Go de RAM et 20 Go de stockage pour son déploiement AIO (All-In-One) en Docker.
Du côté des prérequis communs : un export XML complet de votre instance Jira Data Center doit être produit et vérifié avant de toucher quoi que ce soit sur l'environnement cible. Exportez projet par projet pour les instances volumineuses — Jira impose des limites de taille sur les exports globaux. Disposez d'une sauvegarde complète de tous vos projets, incluant les pièces jointes. Le VPS cible doit être accessible en SSH avec un accès root, et Docker avec docker compose v2 doit être installé ou installable librement. Prévoyez également un domaine ou sous-domaine (ex. pm.votreentreprise.com) et les enregistrements DNS correspondants avant de générer les certificats TLS.
OpenProject vs Plane — comparaison des critères clés
| Critère | OpenProject | Plane |
|---|---|---|
| Licence | GPL-3.0 | AGPL-3.0 |
| GitHub stars | ~15 900 | ~56 000 |
| RAM minimale (production) | 4 Go — quad-core ≥ 2 GHz (jusqu'à 200 utilisateurs) | 4 Go — 2 vCPU, 20 Go stockage |
| Jira Migrator natif | Oui — Beta (depuis OpenProject 17.4, mai 2026) | Import natif depuis export Jira XML |
| Interface | Proche de Jira — work packages, roadmaps, Gantt intégré | Moderne et épurée — issues, cycles, modules |
| Courbe d'apprentissage | Modérée — vocabulaire et concepts proches de Jira | Légère pour les équipes habituées à des outils agiles modernes |
| Authentification fédérée | LDAP et SAML inclus dans la version Community | LDAP inclus en self-hosted ; SAML disponible en self-hosted |
OpenProject — migration via le Jira Migrator officiel
Exporter les données depuis Jira Data Center
Dans l'administration Jira, accédez à Système → Sauvegarde et export. Lancez un export XML par projet pour les instances volumineuses plutôt qu'un export global — Jira Data Center impose des limites de taille qui tronquent silencieusement les exports trop grands. Incluez les pièces jointes dans l'export. Vérifiez la taille de l'archive produite et comparez le nombre de tickets exportés avec le compteur en base avant de continuer.
Déployer OpenProject via Docker
Sur le VPS, créez un dossier de travail et récupérez le fichier docker-compose.yml officiel OpenProject. Définissez les variables d'environnement obligatoires : SECRET_KEY_BASE (générez une chaîne aléatoire de 64 caractères), OPENPROJECT_HOST__NAME (votre domaine), OPENPROJECT_HTTPS=true. Lancez la stack avec docker compose up -d et attendez la fin des migrations de base de données (visible dans les logs du conteneur web).
Configurer et activer le Jira Migrator
Le Jira Migrator d'OpenProject est disponible en Beta depuis la version 17.4 (mai 2026). Dans l'administration OpenProject, rendez-vous dans Modules → Jira Migration. L'outil vous demande l'archive XML Jira exportée à l'étape précédente. Avant de lancer, lisez les limitations connues documentées sur openproject.org/docs/installation-and-operations/jira-migration/ — certains types de champs personnalisés ou de configurations de workflow peuvent nécessiter un traitement manuel après import.
Lancer la migration et surveiller la progression
Démarrez l'import depuis l'interface du Jira Migrator. Pour les instances de grande taille (plusieurs dizaines de milliers de tickets), le processus peut prendre plusieurs heures. Surveillez les logs du conteneur worker d'OpenProject en parallèle : les erreurs d'import apparaissent là avant d'être agrégées dans le rapport de fin de migration. Ne coupez pas la stack Docker pendant l'import.
Valider les work packages, pièces jointes et champs personnalisés
Une fois l'import terminé, le Jira Migrator affiche un rapport avec le nombre d'éléments importés et les éventuelles erreurs. Vérifiez un échantillon représentatif de work packages : titre, description, statut, type, pièces jointes, historique des commentaires. Contrôlez les champs personnalisés de type texte, nombre, date et liste de sélection — ce sont les quatre types migrés par le Beta. Les champs de type formule ou cascade ne sont pas migrés automatiquement.
Configurer les utilisateurs et les permissions
Le Jira Migrator crée des utilisateurs OpenProject correspondant aux comptes Jira, en se basant sur l'adresse e-mail. Les utilisateurs dont l'e-mail ne correspond à aucun compte OpenProject existant sont créés comme inactifs. Activez-les manuellement, assignez-les aux groupes et projets appropriés, et configurez les rôles. Si vous utilisez LDAP ou SAML, connectez l'annuaire avant cette étape pour que les comptes soient liés à l'authentification centralisée dès la première connexion.
Configurer les notifications et le serveur mail
Dans Administration → Paramètres e-mail, renseignez les informations de votre serveur SMTP. OpenProject envoie des notifications pour les mentions, les changements de statut et les dates d'échéance. Envoyez un e-mail de test avant de valider la configuration. Définissez les préférences de notification par défaut pour les nouveaux utilisateurs afin d'éviter une avalanche de mails dès l'ouverture de la plateforme aux équipes.
Plane — import natif depuis un export Jira XML
Exporter les données depuis Jira Data Center
Procédez de la même façon que pour OpenProject : export XML par projet depuis l'administration Jira, pièces jointes incluses. Si votre instance Jira dépasse les limites d'export global, découpez par projet et importez-les séquentiellement dans Plane. Gardez les archives XML originales jusqu'à la validation complète de la migration.
Déployer Plane en mode AIO via Docker
Plane propose un déploiement AIO (All-In-One) via Docker qui embarque tous les services dans une configuration simplifiée. Clonez le dépôt officiel, copiez le fichier .env.example en .env et renseignez au minimum WEB_URL (votre domaine), SECRET_KEY et les paramètres de base de données. Lancez avec docker compose -f docker-compose.yml up -d. Les services qui démarrent incluent le frontend Next.js, l'API Django, le worker Celery, la base de données PostgreSQL et Redis.
Importer depuis Jira XML dans l'interface Plane
Une fois Plane accessible, créez un espace de travail. Accédez aux paramètres de l'espace de travail → Importeurs → Jira. Plane vous demande de téléverser l'archive XML exportée depuis Jira. L'import crée un projet Plane pour chaque projet Jira contenu dans l'archive, avec les issues, les descriptions, les pièces jointes et les commentaires. Les statuts Jira sont mappés vers des états Plane que vous pouvez renommer après l'import.
Valider les issues et les pièces jointes
Après l'import, parcourez un échantillon d'issues par projet : titre, description en Markdown, pièces jointes, commentaires historiques. Vérifiez que les statuts personnalisés ont été correctement mappés. Les issues dont les pièces jointes dépassent la taille autorisée par l'export Jira peuvent apparaître sans leur fichier joint — vérifiez le rapport d'import dans les paramètres de l'espace de travail.
Configurer les cycles, modules et membres
Plane organise le travail en cycles (l'équivalent des sprints Jira) et en modules (regroupements thématiques). Ces structures ne sont pas importées automatiquement depuis Jira — elles sont à recréer selon l'organisation souhaitée pour la nouvelle plateforme. Invitez les membres de l'équipe par e-mail ou configurez le SSO SAML dans les paramètres de l'espace de travail avant d'ouvrir l'accès à l'ensemble des utilisateurs.
Ce que les deux outils ne reprennent pas
Avant d'annoncer la migration à vos équipes, documentez explicitement ce qui ne sera pas transféré — c'est la principale source de déception et de résistance au changement.
Les automations et règles Jira (triggers sur changement de statut, re-assignation automatique, transitions conditionnelles) ne sont pas migrées. OpenProject et Plane ont chacun leur propre système d'automatisation, mais il doit être reconfiguré from scratch. Planifiez un atelier avec les équipes pour cartographier les automations existantes avant la migration.
Les intégrations tierces — connecteurs Confluence, bots Slack, webhooks vers des systèmes CI/CD, plugins Marketplace Jira — devront être reconstruites sur les API d'OpenProject ou de Plane. Les deux outils exposent des API REST documentées, mais la logique d'intégration doit être réécrite.
Les workflows projet avec des conditions complexes (permissions par rôle sur chaque transition, contraintes de validation) ne sont pas migrés par le Jira Migrator Beta. OpenProject permet de reconfigurer des workflows complets, mais uniquement via son interface d'administration — pas automatiquement à l'import.
Les données historiques de sprint — vélocité, burndown, capacité planifiée vs. réalisée — ne sont pas transférées. L'historique des issues et des commentaires est préservé, mais les métriques agiles agrégées restent dans Jira. Si ces données ont une valeur pour l'équipe, exportez-les en CSV depuis Jira avant de fermer l'instance.
Enfin, les types de tickets Jira Service Management (incidents, demandes de service, problèmes au sens ITSM) ne correspondent pas directement aux types d'issues des deux outils. Si vous utilisez Jira à la fois pour le développement et pour le support ITSM, évaluez si OpenProject ou Plane couvrent vos besoins ITSM ou si une solution dédiée (Zammad, Mattermost, Freshdesk auto-hébergé) doit être déployée en complément.
Créez toujours un compte administrateur local avant d'activer l'authentification SSO (SAML ou LDAP). Si la configuration SSO contient une erreur — mauvais identifiant d'entité, certificat expiré, mapping d'attributs incorrect — vous serez définitivement exclu de l'interface lors de la première tentative de connexion SSO. Le compte local permet de corriger la configuration sans intervention sur le serveur. Sur OpenProject, ce compte doit être créé avant d'activer le module LDAP dans les paramètres ; sur Plane, désactivez le SSO le temps de valider la connexion admin. Faites également un export XML complet de Jira et une sauvegarde de l'ensemble des projets avant toute opération sur l'environnement cible.
Dépannage — erreurs fréquentes lors de la migration
Plusieurs erreurs reviennent dans la grande majorité des migrations Jira vers OpenProject ou Plane.
Identifiants non mappés. Le Jira Migrator (et l'importeur Plane) associent les utilisateurs Jira à des comptes de la plateforme cible via l'adresse e-mail. Si un utilisateur Jira a une adresse e-mail différente de celle de son compte OpenProject ou Plane, ses tickets apparaissent sans assignation ou avec un assigné générique. Solution : pré-créez tous les comptes utilisateurs avec les mêmes adresses e-mail que dans Jira avant de lancer l'import.
Pièces jointes manquantes. Les exports Jira Data Center incluent les pièces jointes dans l'archive ZIP, mais Jira peut imposer une limite de taille globale sur les exports. Si l'archive est tronquée, les fichiers joints des tickets les plus récents sont absents. Vérifiez la taille de l'archive exportée et comparez avec l'espace disque effectif de votre répertoire d'attachments Jira. Sur les instances volumineuses, exportez par projet et vérifiez projet par projet.
Timeout sur les exports volumineux. Pour les projets avec des dizaines de milliers de tickets, l'export XML global de Jira peut expirer côté serveur. Utilisez la fonctionnalité d'export partiel par projet disponible dans l'interface d'administration Jira DC. Importez ensuite chaque archive séquentiellement dans OpenProject ou Plane.
Problèmes d'encodage de caractères dans le XML. Les exports Jira qui contiennent des caractères spéciaux (guillemets typographiques, caractères accentués dans certaines locales, emoji insérés dans des descriptions) peuvent produire des fichiers XML mal formés. Validez l'archive XML avec un outil comme xmllint avant l'import. Si des erreurs d'encodage apparaissent, ouvrez le fichier dans un éditeur avec détection de l'encodage et corrigez les séquences invalides.
Erreurs Beta du Jira Migrator OpenProject. Le Jira Migrator est en Beta depuis la version 17.4 (mai 2026) et son comportement peut évoluer entre versions mineures. En cas d'erreur bloquante, consultez la page de limitations connues sur openproject.org/docs/installation-and-operations/jira-migration/ avant d'ouvrir un ticket de support. La plupart des erreurs Beta sont documentées avec une procédure de contournement.
VPS à accès root + OpenProject ou Plane — une sortie propre de Jira Data Center
La migration depuis Jira Data Center n'est pas un projet de plusieurs mois si elle est abordée méthodiquement. Un export XML propre, un VPS dimensionné selon les prérequis de l'outil choisi, et une journée de travail suffisent à transférer les issues, les pièces jointes, les champs personnalisés essentiels et l'historique des commentaires vers OpenProject ou Plane.
Le choix entre les deux dépend de votre contexte : OpenProject est plus proche de Jira dans ses concepts (work packages, roadmaps, Gantt) et dispose d'un Jira Migrator officiel, ce qui en fait la migration la moins risquée pour les équipes habituées au vocabulaire Atlassian. Plane est plus moderne dans son approche et plus largement adopté par les équipes de développement qui veulent repartir sur des bases plus légères.
Dans les deux cas, vous récupérez le contrôle complet : accès root au serveur, sauvegardes maîtrisées, absence de tarification par siège révisable unilatéralement par un éditeur, et données hébergées dans l'infrastructure de votre choix. La sortie de Jira Data Center cesse d'être une contrainte pour devenir une opportunité d'assainissement de votre outillage projet.
