Si vous utilisez Jira Server en 2026, vous utilisez un logiciel non pris en charge. Atlassian a mis fin au support le 15 février 2024. Aucun correctif de sécurité. Aucune correction de bug. Aucun support éditeur.
Le 30 mars 2026, Atlassian a cessé d'accepter les nouveaux abonnements Data Center de la part de nouveaux clients. Les clients existants peuvent poursuivre certains achats jusqu'au 30 mars 2028 et les renouvellements jusqu'au 28 mars 2029, date à laquelle les produits concernés passent en lecture seule selon le calendrier de fin de vie Data Center publié par Atlassian.
Alors, et maintenant ?
Il existe trois options auto-hébergées sérieuses à comparer en 2026 : OpenProject, Plane et Redmine. Cet article les compare par archétype d'usage plutôt que par liste de fonctionnalités, examine le Jira Migrator officiel d'OpenProject, aujourd'hui en bêta pour les versions prises en charge de Jira Server et Data Center, et se termine par le contrepoint honnête : quand Jira Cloud reste la bonne réponse.
Si vous êtes ici parce que « nous devons migrer d'ici 2029 et j'ai besoin de connaître mes vraies options », continuez à lire. Si c'est parce que « je veux un tableau de scores avec 47 colonnes », d'autres articles existent pour cela. Ce n'est pas celui-ci.
La version courte
- Jira Server n'est déjà plus pris en charge, et Jira Software Data Center est en cours de retrait. Les nouvelles ventes Data Center à de nouveaux clients ont pris fin en 2026 ; les abonnements existants concernés arrivent en fin de vie en 2029.
- Trois véritables voies auto-hébergées en 2026. OpenProject pour les équipes qui veulent un remplaçant à la forme de Jira avec un outil de migration, Plane pour les équipes menées par l'ingénierie qui veulent l'UX de Linear sans la facture SaaS, Redmine pour les équipes qui veulent un suivi de tickets peu gourmand qui fonctionne depuis vingt ans.
- OpenProject intègre un Jira Migrator en bêta pour Jira Server et Data Center 10.x et 11.x, mais pas pour Jira Cloud. Ses sources officielles sont actuellement désynchronisées : le guide technique de mai liste un jeu de données de base plus restreint, tandis que les pages plus récentes de juillet indiquent que le Migrator importe aussi l'historique des tickets, les commentaires ainsi que les utilisateurs et groupes concernés. Considérez ces affirmations récentes comme dépendantes de la version et confirmez-les par un pilote sur la version exacte d'OpenProject que vous allez déployer. Plane annonce de son côté un import Jira encadré et un accompagnement de migration sur mesure pour les équipes de plus de 100 sièges. Redmine n'a pas de voie officielle comparable.
- Le dimensionnement du VPS reste modeste. Les recommandations officielles démarrent OpenProject et Plane à 4 Go de RAM ; Plane conseille 8 Go en production. L'image Redmine de Cloudzy indique 2 Go de RAM comme minimum.
- Jira Cloud reste le bon choix pour certaines équipes, en particulier celles sans capacité d'exploitation. La tarification d'Atlassian varie selon le nombre de sièges et la périodicité de facturation ; consultez donc la page de tarifs Jira actuelle plutôt que de vous fier à un tarif figé et obsolète.
Le compte à rebours d'Atlassian : ce qui se passe réellement
Trois dates qui lancent le compte à rebours pour Jira :
- 15 février 2024 : Atlassian a mis fin au support de Jira Server. Aucun support technique, aucune mise à jour de sécurité ni correction de bug n'est fourni pour les produits ou applications Server.
- 30 mars 2026 : Atlassian a cessé de vendre de nouveaux abonnements Data Center et applications Marketplace Data Center à de nouveaux clients. Les clients existants peuvent encore renouveler.
- 28 mars 2029 : les abonnements et applications Data Center concernés expirent et passent en lecture seule. Atlassian indique qu'une maintenance prolongée exceptionnelle peut être proposée à certains clients.
Les équipes réagissent de trois façons environ. Certaines migrent vers Jira Cloud, paient la facture par siège et acceptent la simplification opérationnelle. D'autres s'appuient sur les renouvellements Data Center jusqu'en 2029 et repoussent l'échéance à leur futur soi. D'autres encore évaluent dès maintenant des alternatives auto-hébergées pour éviter à la fois le prix et la date limite.
Si vous êtes dans le deuxième groupe (« on verra plus tard »), l'évaluation honnête est que « plus tard » ne devient un problème de 2029 que si vous n'avez rien d'autre à votre feuille de route d'ici là. La plupart des équipes que j'ai vues faire ce choix finissent par migrer dans la panique, parce que le calendrier avance plus vite que tout le monde ne le pense.
Astuce de pro : Si votre équipe est sur Server, le seul risque de sécurité justifie de traiter le sujet comme un problème de 2026, pas de 2029. Un suivi de tickets non pris en charge reste une surface d'attaque, et il passe souvent en bas de la pile des revues de sécurité précisément parce qu'il « fonctionne tout seul ».
À retenir de cette section : Le compte à rebours est daté, public et officiel. Planifiez autour de 2026-2027, pas de 2029.
Les trois voies auto-hébergées réalistes en 2026
L'écosystème open source compte des dizaines de suivis de tickets. Pour rester ciblé, cet article couvre trois voies distinctes : OpenProject pour la gestion de projet formelle et l'outillage de migration le plus direct ; Plane pour un flux de travail d'ingénierie moderne ; et Redmine pour un tracker mature et extensible. Taiga, Tuleap, Kanboard et d'autres projets peuvent rester de meilleurs choix pour des besoins plus étroits.
Voici ce qu'est réellement chacun d'eux.
OpenProject
OpenProject est une application Ruby on Rails adossée à PostgreSQL. La Community Edition est sous GPLv3 et gratuite à auto-héberger ; les offres Enterprise on-premises payantes ajoutent le support et des fonctionnalités Enterprise.
Le positionnement UX est utilitaire et dense en fonctionnalités. Cela ressemble à un logiciel de gestion de projet d'entreprise parce que c'en est un. Bonne prise en charge des diagrammes de Gantt, du reporting formel de portefeuille de projets, de la collaboration basée sur BCF pour la construction et l'ingénierie, et des flux de responsabilité des parties prenantes. Si votre équipe a déjà réclamé « du vrai Gantt » ou « des dépendances entre epics de projets différents », c'est votre outil.
L'équipe idéale pour OpenProject est celle qui a besoin de faire coexister cycle en V traditionnel et agilité dans la même instance, d'un reporting formel vers le haut de la hiérarchie et d'une voie de migration officielle depuis les versions prises en charge de Jira Server ou Data Center. Nous aborderons le Migrator, et ses limites actuelles, plus bas.
Le point faible est la courbe d'apprentissage. Les membres d'équipe venant de Jira Cloud ou de Linear vous diront qu'OpenProject paraît lourd. Ils n'ont pas tort. De nombreux concepts clés de Jira ont un équivalent dans OpenProject, mais il faudra peut-être lire la documentation pour les trouver.
OpenProject est disponible dans la la marketplace Cloudzy en déploiement en un clic si vous voulez éviter la danse des fichiers Compose.
Plane
Plane est un projet plus jeune, fondé en 2022. Sa distribution auto-hébergée actuelle est un déploiement Docker ou Kubernetes packagé, avec plusieurs services applicatifs plus PostgreSQL, Redis et un stockage objet, plutôt qu'une simple pile de cinq conteneurs.
- Services web et API
- Workers en arrière-plan
- PostgreSQL
- Redis
- Stockage objet
La Community Edition est sous licence AGPLv3.
Le positionnement UX s'inspire ouvertement de Linear. Cycles, modules, projets, vues. Moderne, rapide, assumé. Si vous avez déjà aimé les raccourcis clavier par défaut de Linear ou son modèle de tickets, Plane vous semblera familier en moins d'une heure.
L'équipe idéale est menée par l'ingénierie : startups, équipes produit indépendantes, petites boîtes de dev où les ingénieurs sont les utilisateurs principaux et où l'outil de gestion de projet se résume surtout à un suivi de tickets plus un tableau de sprint. C'est là que Plane brille.
Il faut reconnaître de vraies faiblesses. Le projet est plus jeune que les autres, ce qui signifie un écosystème d'intégrations plus restreint et une surface de déploiement qui bouge plus vite. Sa licence AGPLv3 mérite aussi un examen avant de modifier le logiciel pour un service réseau commercial.
Plane n'est pas dans la marketplace Cloudzy en juillet 2026 : il faut donc passer par le déploiement Docker ou Kubernetes propre à Plane sur le VPS de votre choix. C'est gérable pour une équipe déjà à l'aise avec les conteneurs, mais cela ajoute de l'installation et de la maintenance par rapport à une image en un clic.
Redmine
Redmine est le vétéran. Première version en 2006. Ruby on Rails, backend MySQL ou PostgreSQL. GPLv2. Léger selon les standards actuels, en partie parce que le cœur est réellement petit et en partie parce que l'essentiel de ce que les gens attendent de Redmine passe par des plugins.
L'UX a vieilli. Inutile de prétendre le contraire. Redmine 7.0 est devenue la dernière branche stable en juin 2026, mais son interface par défaut reste d'aspect traditionnel. Le thème Bleuclair modernise Redmine 6.1 ; vérifiez la compatibilité du thème et des plugins avant de passer à Redmine 7. Si une UX moderne est une exigence ferme, regardez Plane.
L'équipe idéale est celle qui utilise déjà Redmine, ou celle qui veut un suivi de tickets stable et peu gourmand, sans workflow trop dogmatique imposé par l'outil. L'écosystème de plugins est énorme :
- Tableaux agiles
- Gantt
- Suivi du temps
- Intégrations SCM
- Workflows personnalisés
Si une équipe a un besoin de workflow précis, il existe probablement un plugin Redmine pour cela.
La faiblesse est double. L'UX, comme évoqué. Et l'écosystème de plugins lui-même, qui est à double tranchant : les plugins résolvent des problèmes mais créent des casse-têtes de compatibilité de version au moment des mises à jour. Une instance Redmine avec huit plugins est une instance où chaque mise à jour mineure exige des tests.
Une note pour les équipes déjà sous Redmine : si le seul reproche porte sur l'UX et que vous êtes en Redmine 6.1, le thème Bleuclair est une expérience peu coûteuse qui peut supprimer le besoin de changer de plateforme. Testez-le d'abord, et vérifiez la compatibilité avant toute montée vers Redmine 7.
À retenir de cette section : Choisissez par archétype. OpenProject pour un remplaçant à la forme de Jira. Plane pour l'UX de Linear sans la facture SaaS. Redmine pour un suivi de tickets stable avec un plugin pour tout.
Comparaison côte à côte
Maintenant que chaque outil a été détaillé, mettons-les dans un format facile à comparer.
| Dimension | OpenProject (Community) | Plane (Community) | Redmine |
|---|---|---|---|
| Première version | 2012 | 2022 | 2006 |
| Pile | Ruby on Rails plus PostgreSQL | Application packagée plus PostgreSQL, Redis et stockage objet | Ruby on Rails plus MySQL ou PostgreSQL |
| Licence | GPLv3 | AGPLv3 | GPLv2 |
| Plancher de dimensionnement (petite équipe) | 4 cœurs, 4 Go de RAM | À partir de 4 Go de RAM, 8 Go recommandés en production | À partir de 2 Go de RAM |
| la marketplace Cloudzy | Oui (en un clic) | Non (déploiement autogéré) | Oui (en un clic) |
| Voie de migration Jira officielle | Bêta intégrée : Server/Data Center 10.x à 11.x | Import guidé ; accompagnement sur mesure au-delà de 100 sièges | Aucune |
| Point fort | Gestion de projet formelle, Gantt, reporting de portefeuille | UX moderne, équipes d'ingénierie | Suivi de tickets léger, plugins |
| Point faible | UX plus lourde ; migrateur encore en bêta | Écosystème plus jeune ; plancher de RAM plus élevé | UX par défaut vieillissante ; compatibilité des plugins |
Le Jira Migrator d'OpenProject : ce qu'il fait réellement
C'est le détail que la plupart des comparatifs de 2026 sautent ou reléguent en note de bas de page. C'est aussi la raison porteuse qui fait d'OpenProject le choix le plus naturel pour les équipes actuellement sous Jira.
OpenProject a rendu son Jira Migrator en bêta disponible en 2026 dans le cadre de la Community Edition. Il se connecte par API avec un Personal Access Token administrateur à Jira Server ou Data Center 10.x et 11.x. Jira Cloud n'est pas pris en charge pour l'instant.
Ce que les pages officielles actuelles d'OpenProject disent collectivement qu'il importe :
- Projets et identifiants de projet
- Tickets : résumé ou titre, description, pièces jointes, historique, commentaires, date d'échéance, heures estimées et heures restantes ; les identifiants de tickets sont aussi pris en charge en bêta
- Utilisateurs et groupes concernés, y compris noms, adresses e-mail, appartenance aux projets et appartenance aux groupes
- Champs personnalisés pris en charge ayant une correspondance dans OpenProject
- Statuts et types de tickets
Ce que vous devez encore considérer comme non pris en charge :
- Relations entre tickets et affectations de sprint
- Workflows, permissions et schémas au niveau projet
- Étiquettes, versions, composants et tout autre champ non listé comme couvert doivent être considérés comme non pris en charge tant qu'un pilote n'a pas prouvé le contraire
- Jira Cloud, données des applications Marketplace, règles d'automatisation et intégrations externes
Deux détails opérationnels comptent autant que la liste des champs. Les imports arrivent d'abord dans un mode de revue, et un import peut être annulé tant qu'il est encore en revue. Une fois l'import approuvé, l'annulation n'est plus possible. Et comme la couverture évolue encore d'une version à l'autre, consultez la documentation à jour avant chaque migration.
Un modèle mental raisonnable : le Migrator en bêta gère un ensemble croissant de données de projet essentielles, pas un environnement Jira complet. Prévoyez un pilote encadré et du temps pour reconstruire la logique de workflow, les permissions, les applications et les intégrations non prises en charge.
Remarque : le guide technique du 6 mai d'OpenProject liste un jeu de données plus restreint que ses pages de juillet, plus récentes, qui ajoutent l'historique, les commentaires ainsi que les utilisateurs et groupes concernés. Le Migrator restant en bêta, vérifiez la couverture dans la version exacte que vous allez déployer et testez-la sur un projet Jira représentatif avant la bascule.
Une trajectoire de migration plus sûre, vue de haut, ressemble à ceci :
- Montez une instance OpenProject hors production sur un VPS (l'image en un clic de Cloudzy convient, ou utilisez les méthodes de déploiement prises en charge par OpenProject).
- Vérifiez que la source est bien Jira Server ou Data Center 10.x ou 11.x, puis créez un Personal Access Token administrateur.
- Sauvegardez l'instance de test OpenProject, puis configurez le Migrator avec l'URL Jira et le token.
- Lancez un pilote sur un projet représentatif et vérifiez les identifiants de projet, les utilisateurs, les appartenances aux groupes, les statuts, les types de tickets, les champs personnalisés pris en charge, les pièces jointes, l'historique, les commentaires, les dates d'échéance, les estimations et les heures restantes.
- Examinez le pilote attentivement. Tant que l'import est en revue, annulez-le si les correspondances sont fausses ; après approbation, cet import ne peut plus être annulé.
- Ne planifiez la migration de production qu'une fois le pilote validé. Utilisez une fenêtre de maintenance, gelez les écritures dans Jira, conservez les sauvegardes et reconstruisez séparément les workflows et intégrations non pris en charge.
Plane annonce désormais un import Jira officiel et encadré qui fait correspondre projets, tickets, sprints, types de tickets, statuts, champs personnalisés, commentaires et pièces jointes ; les équipes de plus de 100 sièges peuvent demander un accompagnement de migration sur mesure. La voie de Redmine reste moins directe, reposant sur des plugins communautaires ou des flux CSV à tester contre des versions et configurations précises.
À retenir de cette section : Le Migrator en bêta d'OpenProject prend en charge Jira Server/Data Center 10.x et 11.x, mais ses sources officielles ne s'accordent pas sur la couverture actuelle. Validez votre version exacte. Plane propose un import guidé ; Redmine n'a pas de voie officielle comparable. Testez OpenProject et Plane en pilote avant la production.
Dimensionnement du VPS : ce dont chaque outil a réellement besoin
Le coût d'infrastructure pour auto-héberger ces outils est modeste. La fiabilité, les sauvegardes, les tests de restauration et la supervision comptent davantage que de faire tenir la pile sur le plus petit forfait. Cloudzy publie actuellement un SLA de disponibilité de 99,95 %, et ses forfaits VPS peuvent être redimensionnés à mesure que l'usage croît.
| Point de planification | OpenProject | Plane | Redmine |
|---|---|---|---|
| Recommandation de départ | 4 cœurs, 4 Go de RAM | 2 cœurs, 4 Go de RAM | À partir de 2 Go de RAM (image Cloudzy) |
| Note pour la production | Minimum pour un serveur unique ; jusqu'à 200 utilisateurs au total | Recommande 8 Go de RAM | Les plugins et la concurrence déterminent la charge |
| Passer à l'échelle quand | Les files d'attente, la latence de la base ou la RAM augmentent | Les services se disputent la RAM et le CPU | La latence de la base ou la charge des plugins augmente |
Quelques remarques qui comptent au quotidien :
- Le minimum officiel d'OpenProject pour une installation sur un seul serveur est un CPU quatre cœurs, 4 Go de RAM et 20 Go d'espace disque libre. Son exemple de petite instance liste séparément 2 cœurs CPU et 4 Go de RAM pour l'application, plus 2 cœurs CPU et 4 Go de RAM pour PostgreSQL.
- Les prérequis officiels d'auto-hébergement de Plane précisent 2 cœurs CPU et 4 Go de RAM au minimum, avec 8 Go recommandés en production.
- L'image Redmine de Cloudzy indique 2 Go de RAM comme minimum. N'en déduisez pas un nombre d'utilisateurs garanti : ce sont les plugins, le volume de pièces jointes, les requêtes simultanées et le comportement de la base qui déterminent la capacité réelle.
À titre de référence, le forfait standard 4 Go de Cloudzy offre 2 vCPU, 120 Go de stockage NVMe et 5 To de trafic. Il atteint le plancher de RAM d'OpenProject mais pas le minimum officiel de quatre cœurs, utilisez donc un forfait ou une configuration sur mesure d'au moins 4 vCPU pour OpenProject. Surveillez la latence de la base, les files des workers et la pression mémoire avant de monter en gamme ; ne promettez pas un multiplicateur de performance fixe sur la seule base du type de stockage.
Développez sur un VPS Linux avec accès root, NVMe et la puissance AMD EPYC.
Voir les plans LinuxÀ retenir de cette section : Redmine peut démarrer autour de 15 $ par mois et Plane autour de 29 $ par mois aux tarifs catalogue standard actuels de Cloudzy, avant promotions. OpenProject exige au moins quatre cœurs CPU selon son minimum officiel : chiffrez-le donc sur une configuration correspondante plutôt que sur le forfait 2 vCPU / 4 Go.
Quand Jira Cloud reste la bonne réponse
L'auto-hébergement échange des dollars contre du temps. Il existe une configuration d'équipe où les dollars valent plus que le temps que vous économiseriez, et cette équipe-là devrait payer Atlassian.
Tarifs catalogue de Jira Cloud en juillet 2026, relevés sur la page de prix publique d'Atlassian (les tarifs sont fixés par Atlassian, varient selon la périodicité de facturation et le nombre de sièges, et changent sans préavis : considérez donc chaque chiffre ci-dessous comme un instantané de 2026 et vérifiez-le sur la page de tarifs Jira actuelle avant de bâtir votre budget) :
- Gratuit : jusqu'à 10 utilisateurs.
- Standard : around $8 per user per month as of mid-2026.
- Premium : around $14 per user per month as of mid-2026.
- Enterprise : contrats annuels, tarification sur mesure.
At that rate, 25 seats total roughly $2,400 per year. A Cloudzy 4 GB VPS is $28.95 per month at standard list price, or about $347 per year before promotions. Jira Cloud's subscription is therefore roughly seven times the VPS infrastructure cost on those 2026 figures, but that comparison excludes operator time, backups, monitoring, paid support, and any Enterprise features.
Posez maintenant la question honnête : qui prendra en charge les sauvegardes, les tests de restauration, les mises à niveau, la maintenance de Postgres, la supervision, les certificats SSL, la création des comptes et la réponse aux incidents ? Comparez l'abonnement Jira Cloud au coût complet d'exploitation de la pile auto-hébergée, pas seulement à la facture de la VM. Si personne ne porte ce travail, les économies apparentes peuvent disparaître vite.
La valeur de Jira Cloud est surtout opérationnelle. Atlassian gère la plateforme, les mises à niveau, les correctifs et les sauvegardes au niveau du service ; votre équipe garde la main sur les politiques d'accès, l'intégration des identités, la gouvernance des applications et les décisions de rétention des données. Pour une équipe où personne ne peut exploiter une pile de gestion de projet, cette couche managée a une valeur réelle.
Formulé honnêtement : l'auto-hébergement convient aux équipes qui exploitent déjà un VPS, comptent un ingénieur à l'aise avec Docker et disposent de la capacité d'assumer le travail d'exploitation. Jira Cloud convient aux équipes où personne dans l'effectif ne veut être réveillé parce que Postgres n'a plus d'espace disque.
Si vous ne savez pas dans quelle catégorie vous vous situez, lancez un pilote OpenProject de deux semaines sur un VPS. Si votre source est une version prise en charge de Jira Server ou Data Center, importez un projet représentatif avec le Migrator en bêta ; Jira Cloud n'est pas encore pris en charge. Soit l'équipe adopte l'outil et vous découvrez la charge d'exploitation, soit la facture du service managé Jira Cloud commence à paraître plus raisonnable.
Verdict rapide
- Vous migrez depuis une version prise en charge de Jira Server ou Data Center et voulez une bêta intégrée en libre-service : OpenProject. Validez la couverture des champs propre à la version avant la production.
- Équipe menée par l'ingénierie, en quête d'une UX moderne et d'un import Jira guidé : Plane. Il exige 4 Go de RAM, en recommande 8 en production, et propose un accompagnement de migration sur mesure pour les équipes de plus de 100 sièges.
- Vous utilisez déjà Redmine et voulez un suivi de tickets stable sur un VPS peu gourmand : restez sur Redmine. Testez le thème Bleuclair avant même d'envisager une migration.
Foire aux questions
Jira Server est-il encore pris en charge en 2026 ?
Non. Atlassian a mis fin au support de Jira Server le 15 février 2024. Quiconque l'utilise en 2026 s'appuie sur un logiciel non pris en charge, sans correctifs de sécurité. Les nouveaux clients ne peuvent plus acheter Jira Data Center : les voies prises en charge réalistes sont donc Jira Cloud ou une alternative maintenue ; les clients Data Center existants peuvent continuer selon le calendrier de retrait publié par Atlassian.
Puis-je encore acheter Jira Data Center ?
Non, pas en tant que nouveau client. Atlassian a cessé les nouvelles ventes Data Center aux nouveaux clients le 30 mars 2026. Les clients existants peuvent acheter de nouveaux abonnements, applications et extensions jusqu'au 30 mars 2028 et renouveler leurs abonnements existants jusqu'au 28 mars 2029. Les produits concernés passent ensuite en lecture seule, sauf prolongation exceptionnelle accordée par Atlassian.
Comment migrer de Jira vers OpenProject ?
Le Jira Migrator d'OpenProject est actuellement en bêta. Il se connecte par API à Jira Server ou Data Center 10.x et 11.x avec un Personal Access Token administrateur ; Jira Cloud n'est pas pris en charge. Les pages officielles plus récentes de juillet 2026 indiquent qu'il importe les projets et leurs identifiants ; les tickets avec descriptions, pièces jointes, historique et commentaires ; les utilisateurs et groupes concernés ; les statuts et les types ; ainsi que les champs personnalisés pris en charge. Le guide technique de mai d'OpenProject liste encore un ensemble plus restreint : confirmez donc la couverture exacte dans la version que vous déployez. Les workflows, les permissions, les schémas, les relations entre tickets et les affectations de sprint restent non pris en charge ou inscrits à la feuille de route.
Quelle est l'alternative à Jira auto-hébergée la moins chère ?
D'après les points de départ actuellement documentés, Redmine sur l'image 2 Go de Cloudzy est l'option la moins chère. Le minimum d'OpenProject pour un serveur unique est de quatre cœurs CPU et 4 Go de RAM. Plane exige 2 cœurs et 4 Go de RAM, avec 8 Go recommandés en production. Les éditions Community n'ajoutent pas de frais de licence logicielle, mais le support payant, les sauvegardes, la supervision et le temps d'exploitation comptent quand même.
Plane est-il un vrai remplaçant de Jira ?
Pour les équipes menées par l'ingénierie, oui. L'UX de Plane est plus proche de Linear que de Jira, et son modèle de tickets convient aux flux de travail d'ingénierie. Plane documente un import Jira encadré couvrant les projets, les tickets actifs et du backlog, les assignations, les étiquettes, les priorités, les sprints, les types de tickets, les statuts, les champs personnalisés, les commentaires et les pièces jointes. Il propose aussi un accompagnement de migration sur mesure au-delà de 100 sièges, mais les équipes avec des applications Marketplace ou des workflows complexes devraient tout de même valider un pilote.
Redmine dispose-t-il d'un outil de migration depuis Jira ?
Pas officiellement. Il existe des plugins d'import communautaires et des flux CSV, mais la compatibilité et la couverture des données varient selon les versions de Jira et de Redmine. Testez le chemin exact sur un projet représentatif. OpenProject dispose d'un Migrator intégré en bêta pour les sources Jira Server ou Data Center prises en charge, tandis que Plane propose un import officiel guidé.
Puis-je faire tourner l'un d'eux sur un petit VPS ?
L'image Redmine de Cloudzy indique 2 Go de RAM comme minimum, soit 14,95 $ par mois au tarif catalogue standard. OpenProject exige au moins quatre cœurs CPU et 4 Go de RAM. Plane exige 2 cœurs et 4 Go de RAM, avec 8 Go recommandés en production. Le forfait standard 4 Go de Cloudzy offre 2 vCPU et s'affiche à 28,95 $ par mois, les promotions le faisant parfois baisser. Faire tourner les trois sur un même petit VPS n'est pas une conception de production raisonnable.
