Le plus grand risque d’une migration Atlassian Cloud, ce n’est pas la complexité technique. C’est de commencer trop tard pour avoir le choix de bien faire les choses.

On accompagne des migrations depuis l’annonce du programme Atlassian Ascend. Et le schéma qu’on observe le plus souvent, ce n’est pas l’équipe qui sous-estime la difficulté technique. C’est l’équipe qui sait très bien ce qu’elle a à faire, qui a même une bonne vision de son instance, mais qui repousse le démarrage parce que le quotidien passe toujours en premier.

Le résultat : on se retrouve à lancer le projet en 2027 ou 2028, avec moins de marge pour tester, moins de partenaires disponibles, et une fenêtre de bascule qu’on ne choisit plus vraiment. La migration se fait quand même, mais dans des conditions qui auraient pu être évitées.

Ce guide n’est pas là pour vous convaincre que migrer est une bonne idée. Vous le savez déjà. Il est là pour vous aider à structurer le projet de façon à ce qu’il reste gérable, même quand vous n’avez pas une équipe dédiée pour le porter.

Calendrier Atlassian Data Center : les dates clés à connaître avant 2029

Le calendrier de fin de vie Data Center est fixé :

Ce qui compte ici : si vous n’avez pas une équipe dédiée à ce projet, la migration ne se fera pas en mode « task force pendant six mois ». Elle devra s’intégrer dans un quotidien déjà chargé. C’est précisément pour ça que commencer maintenant, plutôt qu’en 2027 ou 2028, change tout.

Votre migration Jira et Confluence vers le Cloud est probablement plus simple que vous ne le pensez

Les cas qui font peur dans les retours d’expérience, les instances avec des dizaines de milliers de projets, des centaines de scripts ScriptRunner critiques, des intégrations avec cinq systèmes métiers différents, ce sont des environnements qui ont grandi pendant dix ans avec des équipes dédiées.

Ce qui fait déraper ces migrations, ce n’est pas la complexité technique mais le manque de préparation sur trois sujets précis.

Les trois erreurs qui font déraper une migration Atlassian Data Center vers Cloud

1. Les apps Marketplace non évaluées avant la migration

C’est le point qui génère le plus de surprises tardives. Avoir une app disponible en Cloud ne garantit pas la parité fonctionnelle avec votre version Data Center. Et surtout : les données applicatives, les valeurs de custom fields pilotées par une app, les configurations stockées côté plugin, ne migrent pas avec les outils natifs Atlassian. Chaque vendor a son propre chemin de migration, et certains n’en ont pas.

Le réflexe à avoir maintenant : lancer Portfolio Insights depuis admin.atlassian.com. C’est gratuit, disponible pour toutes les organisations Atlassian, et ça vous donne une cartographie complète de votre portefeuille d’apps avec leur statut Cloud. Faites-le avant de planifier quoi que ce soit.

2. Les comptes utilisateurs inactifs non nettoyés avant la migration

Le modèle de licence Data Center est basé sur le nombre d’utilisateurs autorisés. Le Cloud, lui, facture à l’utilisateur actif. Une migration sans nettoyage préalable des comptes inactifs, anciens collaborateurs, prestataires dont la mission est terminée, vous expose à payer pour des utilisateurs qui n’ont plus rien à faire dans votre instance.

La règle simple : exportez votre liste d’utilisateurs avec les dates de dernière connexion, croisez avec les données RH, désactivez les comptes inactifs depuis plus de 90 jours avant de migrer. Ce nettoyage réduit votre coût Cloud et assainit votre gouvernance en même temps (source : miniorange.com).

3. Une fenêtre de bascule mal planifiée

Jira est souvent au coeur des opérations quotidiennes. Une bascule mal planifiée sur une période chargée, une fin de sprint, une release, une période de clôture, génère des perturbations que votre équipe support absorbe mal quand elle est déjà à flux tendu.

Identifiez votre « offseason » : une période de faible activité, idéalement un week-end prolongé ou une période de congés, où la fenêtre de migration minimise l’impact sur les équipes. Planifiez plusieurs dry-runs avant la bascule réelle. Ce n’est pas une option, c’est ce qui fait la différence entre une migration propre et une migration qui génère des tickets pendant trois semaines.

Bénéfices d’Atlassian Cloud : ce que la migration vous apporte concrètement

Au-delà de la contrainte calendaire, la migration vers Atlassian Cloud apporte des bénéfices opérationnels réels.

Moins d’administration infrastructure. Plus de maintenance serveur, plus de mises à jour d’infrastructure à planifier. Pour un admin qui gère Atlassian en plus du reste, c’est du temps récupéré sur des tâches à faible valeur.

Sécurité gérée au niveau de la plateforme. Atlassian Cloud est conforme ISO 27001, SOC 2 et RGPD. Atlassian Guard apporte la détection des menaces, la prévention des pertes de données et l’audit logging centralisé, des fonctionnalités Cloud-only qui nécessitaient des configurations manuelles en Data Center.

Accès immédiat aux nouvelles fonctionnalités. Rovo, l’assistant IA d’Atlassian, l’automatisation avancée, les nouvelles interfaces : tout sort en Cloud. Rester sur Data Center, c’est accepter un écart fonctionnel qui se creuse chaque trimestre.

Migration Atlassian Cloud : faut-il faire appel à un partenaire ou gérer en interne ?

Pour une instance simple, peu d’apps, peu d’intégrations, une équipe disponible : une migration en interne avec les outils natifs Atlassian est tout à fait viable.

Mais certains signaux indiquent qu’un accompagnement externe change vraiment l’équation :

• Votre admin Atlassian ne peut pas dédier plus de 20 % de son temps au projet
• Vous avez cinq apps Marketplace ou plus avec des dépendances métiers critiques
• Vous avez des intégrations avec des systèmes tiers (SIRH, CRM, outils CI/CD)
• Vous n’avez jamais fait de migration Atlassian auparavant
• Vous avez besoin d’une garantie sur la préservation des données et des workflows

Dans ces cas, le coût d’une erreur, perte de données, workflow cassé, adoption ratée, dépasse largement l’investissement dans un accompagnement structuré.

SQORUS, Atlassian Solution Partner Silver : notre approche de la migration Cloud

SQORUS est Atlassian Solution Partner Silver. Nos consultants certifiés accompagnent des migrations Data Center vers Cloud avec une approche qui part toujours de l’audit de l’existant avant de toucher à quoi que ce soit.

Ce que ça change pour vous :

• Un diagnostic honnête de votre instance : cartographie des apps, identification des risques réels, estimation de charge. Pas de promesse sur un délai avant d’avoir regardé ce qu’il y a sous le capot.

• Un plan adapté à vos contraintes : on structure le projet pour que la charge interne reste absorbable, avec des jalons clairs et une fenêtre de bascule bien choisie.

• La reprise complète de vos workflows, permissions et automatisations : vous arrivez en Cloud avec votre instance qui fonctionne, pas avec un environnement à reconfigurer.

• La formation de vos équipes : vos utilisateurs savent ce qui change et pourquoi, avant la bascule, pas après.

• Un support post-migration : les premières semaines en Cloud sont celles où les questions arrivent. On est là pour y répondre.

Nos consultants interviennent aussi bien sur la configuration technique que sur les usages métiers (ITSM, Agile, gestion de projet, ESM), ce qui évite les allers-retours quand une décision de migration touche à la fois l’administration et les processus des équipes.

Conclusion Migration Data Center vers Cloud : choisissez votre calendrier avant qu’il s’impose à vous

Migrer vers Atlassian Cloud n’est pas un projet qu’on lance du jour au lendemain. Mais ce n’est pas non plus un chantier réservé aux équipes qui ont six mois devant elles et une task force dédiée.

Ce que les migrations qui se passent bien ont en commun, c’est une chose : elles commencent par un nettoyage de l’instance Data Center avant de toucher à quoi que ce soit d’autre. Projets inactifs, workflows obsolètes, permission schemes en doublon, comptes utilisateurs fantômes, apps Marketplace non utilisées.

Une instance assainie avant migration arrive en Cloud dans un état stable, gouverné, prêt à évoluer. Une instance migrée telle quelle transporte ses problèmes dans un nouvel environnement et ils sont souvent plus visibles et plus coûteux à corriger une fois en Cloud.

Ce qui fait la différence ensuite, c’est la préparation. Lancer Portfolio Insights pour cartographier vos apps. Nettoyer vos utilisateurs inactifs avant de migrer. Choisir votre fenêtre de bascule plutôt que de la subir. Trois actions concrètes, faisables maintenant, qui changent radicalement la suite.

Vous avez encore une fenêtre confortable devant vous. Pas indéfinie, mais confortable. Les organisations qui démarrent leur réflexion en 2026 peuvent se permettre de faire les choses dans l’ordre : diagnostic, plan, dry-runs, bascule maîtrisée. Celles qui attendent 2028 migrent sous pression, avec moins de partenaires disponibles et moins de marge pour absorber les imprévus.

La question n’est pas « est-ce que je dois migrer ». La réponse, vous la connaissez. La question, c’est « est-ce que je veux choisir comment le faire, ou attendre qu’on me l’impose ».

Commencez par un diagnostic. On vous dit en une session ce que votre migration implique vraiment !

FAQ – Migration Atlassian Data Center vers Cloud