Migrer Jira et Confluence vers le Cloud, sur le papier, c’est un projet technique. En pratique, pour une organisation de 1000+ utilisateurs, c’est un projet de transformation dont la complexité réelle n’apparaît pas dans les guides de migration Atlassian.
Les Cloud Migration Assistants (JCMA, CCMA) gèrent le transfert de données. Mais ils ne gèrent pas la gouvernance multi-projets, les workflows JSM imbriqués dans vos processus métier, ni les intégrations qui connectent Atlassian au reste de votre SI. C’est là que les migrations Enterprise déraillent.
Cet article détaille les trois dimensions de complexité que nous évaluons systématiquement pendant un assessment, et ce que chacune implique pour votre projet.
Dimension 1 : la gouvernance
Dans un environnement Data Center mature, la gouvernance s’est construite organiquement sur plusieurs années. Schémas de permissions hérités, rôles de projets personnalisés, groupes imbriqués, restrictions d’espaces Confluence avec des logiques métier spécifiques. Tout fonctionne, mais personne ne sait exactement pourquoi.
En Cloud, le modèle de gouvernance est différent. Les permissions s’appuient sur Atlassian Guard (anciennement Atlassian Access) pour la couche organisation, sur les rôles de produit pour l’administration, et sur les schémas de permissions au niveau projet. La migration technique transfère vos schémas existants, mais elle ne les adapte pas au modèle Cloud.
Nous évaluons
Schémas de permissions : Combien de schémas de permissions existent dans votre instance Jira ? Combien sont réellement distincts, et combien sont des copies divergentes du même schéma initial ? Dans les environnements Enterprise, nous trouvons régulièrement 50 à 200 schémas de permissions dont 80% pourraient être consolidés en 10 à 15 schémas standardisés. Cette consolidation n’est pas obligatoire pour migrer, mais elle détermine votre capacité à administrer l’environnement Cloud efficacement après migration.
Groupes et rôles : Le modèle de groupes Data Center repose souvent sur des groupes LDAP/AD synchronisés. En Cloud, la synchronisation se fait via un identity provider (Okta, Azure AD, Google Workspace) connecté à Atlassian Guard. Les groupes locaux Data Center qui ne sont pas dans votre IdP devront être recréés manuellement ou intégrés dans votre stratégie de provisioning. Nous cartographions chaque groupe, son origine (IdP ou local), et son usage réel.
Administration déléguée : En Data Center, certaines équipes ont des droits d’administration système pour gérer leurs projets. En Cloud, l’administration est centralisée au niveau du site, avec une délégation possible via les rôles “Organization admin”, “Site admin”, et “Product admin”. Si votre modèle actuel repose sur une administration distribuée, la migration nécessite une redéfinition des responsabilités.
Espaces Confluence et restrictions : Les restrictions de pages et d’espaces Confluence migrent techniquement, mais le modèle Cloud gère les permissions différemment (permissions d’espace simplifiées, restrictions de page héritées). Nous identifions les configurations qui nécessitent une adaptation manuelle post-migration.
Indicateurs de complexité élevée
- Plus de 100 schémas de permissions dans Jira
- Groupes locaux non synchronisés avec un IdP
- Administration système déléguée à plus de 5 équipes
- Restrictions Confluence basées sur des groupes imbriqués
- Absence de documentation sur la logique de permissions actuelle
Dimension 2 : Jira Service Management
JSM en Data Center est souvent le produit Atlassian le plus profondément intégré dans les processus métier. Ce n’est pas un simple outil de ticketing : c’est le moteur de vos processus ITSM, et parfois de vos processus métier (RH, juridique, facilities, procurement).
La migration de JSM vers Cloud ne se limite pas au transfert des projets de service. Elle implique la migration de l’ensemble de l’écosystème qui gravite autour : portails clients, SLA, automatisations, files d’attente, assets (anciennement Insight), et les intégrations avec vos outils de monitoring et d’alerte.
Nous évaluons
Portails et expérience client : Combien de portails de service existent ? Sont-ils personnalisés (branding, formulaires dynamiques, catégories) ? En Cloud, les portails JSM offrent des capacités de personnalisation différentes. Les formulaires dynamiques (Proforma, désormais natif dans JSM Cloud) remplacent souvent des solutions tierces utilisées en Data Center. Nous identifions les écarts fonctionnels pour chaque portail.
SLA et automatisations : Les configurations SLA migrent, mais leur comportement peut différer en Cloud (calendriers, fuseaux horaires, conditions de pause). Les automatisations Jira (anciennement Automation for Jira Server/DC) ont des équivalences Cloud, mais certaines actions ou conditions n’existent pas à l’identique. Nous auditons chaque règle d’automatisation et identifions celles qui nécessitent une réécriture.
Assets (Insight) : Si vous utilisez Insight en Data Center pour votre CMDB, la migration vers Assets en Cloud est un sous-projet à part entière. Les schémas d’objets, les imports automatisés, et les références entre assets et tickets doivent être validés. Assets Cloud a évolué significativement et offre des fonctionnalités natives (discovery, intégrations) qui n’existaient pas en Data Center, mais la structure de données doit être compatible.
Queues et triage. Les files d’attente JSM Cloud fonctionnent différemment de Data Center. Les queues personnalisées avec des filtres JQL complexes migrent, mais les performances et le comportement de tri peuvent varier. Pour les équipes qui traitent des centaines de tickets par jour, cette différence est critique.
Pratiques ITSM. Si vous utilisez les pratiques ITSM avancées (incident management, change management, problem management), leur configuration Cloud diffère de Data Center. Le change management Cloud s’intègre nativement avec Bitbucket et les outils CI/CD pour les change requests automatisées, une capacité qui n’existe pas en Data Center mais qui nécessite une configuration spécifique.
Indicateurs de complexité élevée
- Plus de 10 projets de service actifs
- Utilisation d’Assets/Insight avec imports automatisés
- Automatisations JSM avec plus de 50 règles actives
- Portails personnalisés avec formulaires dynamiques tiers
- Intégrations avec des outils de monitoring (PagerDuty, Opsgenie, Datadog, ServiceNow)
- Pratiques ITSM avancées (change, problem, incident) en production
Dimension 3 : les intégrations
Un environnement Atlassian Enterprise n’existe pas en isolation. Il est connecté à votre SI par des dizaines d’intégrations : CI/CD, monitoring, CMDB, ERP, CRM, outils de documentation, plateformes de communication. Chaque intégration est un point de complexité dans votre migration.
En Data Center, ces intégrations utilisent des mécanismes variés : API REST directes, webhooks, apps Marketplace avec composants serveur, scripts ScriptRunner, connecteurs personnalisés, bases de données partagées. En Cloud, certains de ces mécanismes n’existent plus ou fonctionnent différemment.
Nous évaluons
Apps Marketplace : Pour chaque app installée, nous déterminons son chemin de migration. Trois scénarios possibles : l’app existe en Cloud avec migration automatisée des données (cas idéal), l’app existe en Cloud mais sans migration de données (reconfiguration nécessaire), ou l’app n’existe pas en Cloud (remplacement fonctionnel à trouver). Pour les apps critiques sans équivalent Cloud, nous contactons directement l’éditeur pour connaître sa roadmap.
ScriptRunner et personnalisations : ScriptRunner for Jira/Confluence est l’app la plus répandue dans les environnements Enterprise Data Center. En Cloud, ScriptRunner existe mais avec un modèle d’exécution différent (pas d’accès direct au serveur, API Atlassian Cloud, limites de rate). Les scripts Groovy Data Center ne sont pas compatibles directement. Nous auditons chaque script, évaluons sa criticité, et déterminons s’il peut être remplacé par une automatisation native, réécrit pour ScriptRunner Cloud, ou remplacé par une Forge app.
Intégrations API directes : Les intégrations qui appellent l’API REST Atlassian doivent être adaptées. L’API Cloud diffère de l’API Data Center : authentification OAuth 2.0 ou API token (plus de basic auth avec mot de passe), endpoints différents, pagination modifiée, rate limiting strict. Nous inventorions chaque intégration, son propriétaire technique, et l’effort d’adaptation estimé.
Webhooks : En Data Center, les webhooks sont configurés au niveau système. En Cloud, ils sont gérés via l’interface d’administration ou via des apps (Automation for Jira, Forge). Les webhooks existants doivent être recréés et les systèmes récepteurs doivent être adaptés au nouveau format de payload Cloud.
Connecteurs d’entreprise : Les intégrations avec SAP, Salesforce, ServiceNow, ou d’autres plateformes d’entreprise passent souvent par des middleware (MuleSoft, Workato, Boomi) ou des connecteurs personnalisés. Ces intégrations doivent être revalidées avec les endpoints Cloud et les mécanismes d’authentification OAuth 2.0.
Indicateurs de complexité élevée
- Plus de 30 apps Marketplace installées
- ScriptRunner avec plus de 20 scripts personnalisés actifs
- Intégrations API directes avec plus de 5 systèmes externes
- Connecteurs d’entreprise (ERP, CRM, CMDB externe)
- Scripts post-functions personnalisés dans les workflows
- Bases de données partagées entre Atlassian et d’autres systèmes
Ces trois dimensions déterminent votre calendrier
La durée d’une migration Atlassian Enterprise n’est pas proportionnelle au volume de données mais à la complexité combinée de ces trois dimensions.
Une organisation avec 5000 utilisateurs, 10 schémas de permissions standardisés, 3 projets JSM simples, et 15 apps Marketplace peut migrer en 3 à 4 mois. Une organisation avec 2000 utilisateurs, 150 schémas de permissions hérités, 20 projets JSM avec Assets et automatisations complexes, et 50 apps dont ScriptRunner avec 100 scripts, aura besoin de 9 à 12 mois.
C’est pourquoi les projets de migration échouent quand ils sont planifiés uniquement sur la base du nombre d’utilisateurs ou du volume de données.
Comment nous évaluons cette complexité
Notre Assessment Cloud Atlassian Enterprise couvre ces trois dimensions de manière structurée pendant les 8 premières semaines d’engagement. Nous produisons :
- Un inventaire complet de votre modèle de gouvernance avec recommandations de simplification
- Un audit JSM détaillé couvrant portails, SLA, automatisations, Assets, et pratiques ITSM
- Un catalogue d’intégrations avec chemin de migration, effort estimé, et propriétaire technique pour chacune
- Un score de complexité global qui détermine la durée et l’effort réalistes de votre migration
- Un plan de migration séquencé qui traite les dépendances entre ces trois dimensions
Ce travail d’évaluation est ce qui transforme un projet de migration incertain en un projet planifiable. Votre direction obtient un calendrier crédible. Vos équipes techniques obtiennent un périmètre clair. Et votre fin de support Data Center en mars 2029 devient une échéance gérable plutôt qu’une menace abstraite.
Et après ?
Si vous avez lu nos articles précédents sur la fin de Data Center, les exigences réglementaires DORA, RGPD et Solvency II, ou les raisons pour lesquelles les projets de migration échouent, vous comprenez déjà le contexte. Cet article vous donne les critères concrets pour évaluer où se situe votre organisation sur l’échelle de complexité.
Un premier échange de 30 minutes avec notre équipe suffit pour estimer votre niveau de complexité et déterminer si un assessment structuré est pertinent pour votre contexte.
