La fin du support de Jira Server, actée par Atlassian pour février 2024, a contraint des milliers d’organisations à basculer vers Jira Cloud ou Data Center. Pour un responsable des systèmes d’information, cette migration n’est pas une simple mise à jour : c’est le déplacement de toute la mémoire projet de l’entreprise — tickets, workflows, permissions, tableaux, automatisations — vers une plateforme SaaS dont le modèle de données, le système d’apps et la gestion des identités diffèrent profondément de l’édition hébergée en interne.
Pourquoi la migration vers Jira Cloud est devenue inévitable
Atlassian a fermé la porte aux nouvelles licences Server dès 2021, puis cessé toute maintenance, correctif de sécurité et mise à jour pour les instances Server au 15 février 2024. Rester sur Jira Server, c’est désormais exploiter un logiciel non maintenu : vulnérabilités non corrigées, absence de conformité, impossibilité d’utiliser les nouvelles fonctionnalités du produit. Le choix se résume en pratique à Jira Cloud (SaaS, multi-tenant) ou Jira Data Center (auto-hébergé, licences par paliers). Pour la majorité des équipes, le Cloud s’impose : zéro serveur à administrer, mises à jour continues, et accès natif aux nouveautés Atlassian — mais au prix d’une migration qu’il faut préparer rigoureusement.
Les différences structurelles entre Jira Server et Jira Cloud
Comprendre ces écarts conditionne toute la stratégie de bascule. Le tableau ci-dessous résume les points qui ont le plus d’impact sur une migration.
| Dimension | Jira Server | Jira Cloud |
|---|---|---|
| Hébergement | Sur vos serveurs (VM, on-premise) | SaaS Atlassian, multi-tenant |
| Identités | Annuaire interne (LDAP/AD), comptes locaux | Comptes Atlassian, SSO via Atlassian Access |
| Applications | Apps installées côté serveur, scripts Groovy | Apps du Marketplace Cloud, sandboxées |
| Personnalisation | Accès direct à la base et aux fichiers | API REST et UI uniquement |
| Sauvegardes | À votre charge | Gérées par Atlassian |
Ce tableau met en évidence le point de vigilance numéro un : ce qui reposait sur des scripts serveur ou un accès direct à la base de données n’a pas d’équivalent direct dans le Cloud, où toute personnalisation passe par l’API.
Les étapes clés d’une migration Jira Server vers Jira Cloud
- Audit de l’instance source : recenser les projets, types de tickets, workflows, schémas (permissions, notifications, écrans, champs), utilisateurs actifs, groupes, apps installées et leur version.
- Nettoyage préalable : archiver les projets obsolètes, désactiver les comptes inutilisés, supprimer les apps sans équivalent Cloud et les champs personnalisés redondants. Un périmètre propre simplifie la reprise.
- Choix de la méthode : Jira Cloud Migration Assistant (JCMA) pour un transfert assisté depuis l’interface, ou Cloud Site Import pour les volumes importants ou les besoins de transfert plus fin. JCMA couvre la majorité des cas courants.
- Cartographie des apps : vérifier, pour chaque app Server, l’existence d’une version Cloud compatible et le mécanisme de migration de ses données. Les apps sans équivalent doivent être retirées avant bascule.
- Pré-migration et test : exécuter une migration sur un site Cloud de test, contrôler l’intégrité des tickets, des pièces jointes, des historiques et des champs.
- Bascule définitive : planifier une fenêtre de bascule, verrouiller l’instance source, lancer la migration finale, puis réconcilier les données entre source et cible.
- Post-migration : reconfigurer le SSO, les intégrations externes (CI/CD, messagerie), former les équipes et basculer les URLs et intégrations tierces.
Les pièges techniques à anticiper
La perte de données n’est pas le seul risque. Les échecs de migration viennent le plus souvent de trois zones. Premièrement, les apps et scripts : une automatisation ScriptRunner écrite en Groovy ne se transpose pas telle quelle ; elle doit être réécrite avec Automation for Jira, dont le moteur de règles est différent. Deuxièmement, les identités : dans le Cloud, chaque utilisateur a besoin d’un compte Atlassian ; la correspondance entre comptes internes, adresses e-mail et groupes doit être établie avant la bascule, sous peine de perdre les mentions, les assignations et l’historique des modifications. Troisièmement, les limites du Cloud : quotas de pièces jointes, taille maximale par fichier, limites de requêtes API et de champs personnalisés par projet peuvent imposer des arbitrages.
Bonnes pratiques pour une bascule sans régression
- Sauvegarder l’instance Server complète (base de données et répertoire de données) avant toute manipulation.
- Effectuer une ou plusieurs migrations de répétition sur un environnement Cloud de test, et mesurer le temps de transfert réel pour calibrer la fenêtre de bascule.
- Documenter les règles métier des workflows (validateurs, conditions, post-functions) pour vérifier leur équivalence après migration.
- Prévoir un plan de rollback : tant que le Cloud n’est pas validé, l’instance Server reste disponible en lecture pour toute vérification.
- Communiquer en amont : les utilisateurs doivent savoir quand la bascule a lieu et vers quelle URL se connecter.
Conduire le changement auprès des équipes
La bascule vers Jira Cloud modifie aussi les habitudes : nouvelle interface, nouvelles règles d’automatisation, éventuel passage à des tableaux Kanban et Scrum repensés. Une formation courte des administrateurs projet et des développeurs, couplée à une documentation interne des nouveaux processus, évite la perte de productivité post-migration.
Gestion des apps et validation d’intégrité
La gestion des apps est l’étape la plus délicate de la migration Jira Server. Chaque app installée côté serveur doit être auditée : existe-t-il une version Cloud compatible ? Ses données sont-elles migrées automatiquement par le Migration Assistant, ou doivent-elles être exportées et réimportées manuellement ? Certaines apps historiques, notamment les apps de scripting et de reporting avancé, n’ont pas d’équivalent Cloud, ce qui impose de reconstruire la fonctionnalité autrement. La règle est simple : toute app sans équivalent doit être retirée avant la bascule, sinon elle bloque la migration ou laisse des données orphelines.
Après chaque migration de test, la validation d’intégrité doit confronter systématiquement les compteurs source et cible : nombre de projets, d’issues par statut, de commentaires, de pièces jointes et d’utilisateurs. Les écarts proviennent le plus souvent d’apps non migrées, de champs personnalisés orphelins ou de comptes sans adresse e-mail valide — trois causes qu’un audit préalable permet d’éliminer. Il faut également vérifier que les filtres JQL, les tableaux de bord partagés et les tableaux Kanban retrouvent leur comportement d’origine.
Enfin, la post-migration impose de re-tester chaque intégration externe : dépôts de code, outils CI/CD, messagerie et SSO. Leurs jetons et identifiants changent à la bascule, et la cause la plus fréquente de régression post-migration est une automatisation qui cesse silencieusement de fonctionner parce que son compte de service n’a pas été recréé dans le Cloud.
Chez Performances Digital, nous pilotons ces migrations de bout en bout : audit de l’instance Server, cartographie des apps et des identités, reprise des projets et des workflows, vérification d’intégrité des tickets et accompagnement des équipes. Notre objectif est une bascule sans perte de données ni de continuité de service, dans le respect de vos contraintes de sécurité et de conformité.
Une migration Jira Server réussie est celle où les équipes retrouvent, le lendemain de la bascule, l’intégralité de leur historique et de leurs processus, sans rupture. Demandez votre devis gratuit : nous évaluons votre périmètre, vos apps et vos volumes, puis nous vous remettons une feuille de route chiffrée et adaptée à votre organisation.
