TL;DR
Dans de nombreuses organisations, une “migration Atlassian” est vue comme un chantier principalement technique : déplacer Jira, Confluence ou Jira Service Management d’une plateforme à une autre. Pourtant, ce n’est presque jamais là que les projets dérapent. Les échecs les plus marquants que nous rencontrons ne sont pas dus à un bug isolé, mais à une préparation insuffisante, à une gouvernance trop faible et à un accompagnement humain sous‑dimensionné.
Les DSI et directeurs IT qui réussissent leurs migrations Atlassian Enterprise ont un point commun : ils traitent ce sujet comme un programme de transformation de plateforme, pas comme un simple projet IT. Ils y voient une opportunité de moderniser leur environnement, de réduire la dette technique, de renforcer la sécurité et de rationaliser les usages.
Concrètement, les organisations les plus matures adressent systématiquement quatre familles de risques :
- Gouvernance & stratégie : une cible claire, des décisions tranchées et un sponsor visible.
- Technique & données : une instance assainie, une maîtrise des apps Marketplace et des intégrations.
- Environnement & opérations : une capacité réelle à exécuter la migration dans les contraintes de production.
- Humain & adoption : communication, formation, support renforcé pour que la migration soit acceptée, pas subie.
Elles industrialisent aussi leur approche : inventaire des usages, plusieurs migrations de test, runbook détaillé, indicateurs de succès partagés. Enfin, elles s’appuient sur un partenaire Platinum capable de leur apporter retours d’expérience, méthodologie et interface avec Atlassian pour sécuriser les choix structurants.
Une migration Atlassian, ce n’est plus un “simple” projet IT
Dans la plupart des grandes organisations, Jira, Confluence et Jira Service Management ne sont plus de “simples outils de l’IT”.
Ils supportent :
- le delivery logiciel et les pratiques DevOps,
- les processus ITSM/ESM (incidents, demandes, changements),
- des usages métiers critiques (projets transverses, qualité, conformité, bases de connaissances internes ou clients).
Avec le temps, ces usages se sont empilés : multiples instances, couches de personnalisation, apps Marketplace, intégrations au SI. Et la pression s’intensifie : la fin de vie d’Atlassian Data Center est programmée pour mars 2029, ce qui place de nombreuses organisations face à l’obligation de migrer dans un calendrier contraint.
Dans ce contexte, une migration Atlassian Enterprise, qu’il s’agisse d’un passage au Cloud, d’une consolidation d’instances ou d’un changement d’offre (Enterprise, Isolated, etc.), n’est plus une simple mise à niveau technique. Pour un DSI ou un directeur IT, c’est un chantier :
- visible au niveau COMEX, par ses impacts potentiels sur la production et les métiers,
- sensible sur le plan sécurité et conformité (identité, data residency, traçabilité),
- coûteux en énergie interne, car il mobilise les équipes IT, support et métiers sur plusieurs mois.
L’ambition de cet article est donc double :
- Mettre en lumière pourquoi les projets de migration Atlassian échouent réellement en contexte Enterprise (au‑delà des seules causes “techniques”).
- Montrer comment les organisations les plus matures structurent leur approche pour transformer ce risque projet en levier de modernisation de leur plateforme.
Dans la section suivante, nous proposons une grille de lecture simple autour de quatre familles de risques qui expliquent l’essentiel des dérapages observés sur le terrain.
D’où viennent réellement les échecs : 4 familles de risques
Derrière chaque projet de migration Atlassian qui dérape, le récit est différent… mais les causes profondes se ressemblent beaucoup. Avec le recul de multiples projets en contexte Enterprise, on peut les regrouper en quatre grandes familles de risques.
Cette grille de lecture est précieuse pour un DSI ou un directeur IT : elle permet de dépasser la liste de “problèmes techniques” pour revenir à ce qui doit réellement être maîtrisé au niveau du programme.
Risques de gouvernance & de pilotage
Beaucoup de projets partent avec :
- une cible floue (Cloud / DC / Enterprise / Isolated, une ou plusieurs instances, quelles entités incluses ?),
- un périmètre mal cadré (instances parallèles, environnements, filiales oubliées),
- un sponsor exécutif peu impliqué et des arbitrages laissés au niveau “projet IT”.
Conséquence : décisions tardives, contournements, empilement d’exceptions… et un projet qui avance sans vrai cap partagé.
Risques techniques & données
La question n’est pas “est‑ce que Jira/Confluence peuvent migrer ?”, mais dans quel état est l’instance que l’on migre :
- années de personnalisations, workflows complexes, champs obsolètes, schémas de permissions historiques,
- dépendance forte à des apps Marketplace pour des processus critiques,
- volumétrie importante (projets, espaces, pièces jointes) qui complique les stratégies de migration.
Sans assainissement ni choix clairs, on projette la dette technique “as is” et on augmente le risque d’erreurs, de temps de traitement excessifs et d’instabilité post‑migration.
Risques environnement & opérations
Une migration Enterprise est avant tout un événement de production :
- plateformes Server/DC déjà sous tension (ressources, stockage),
- contraintes réseau et sécurité (débit, proxys, politiques filtrantes),
- calendrier de production chargé (autres projets, périodes de gel, pics d’activité).
Si ces contraintes ne sont pas intégrées dès le design (fenêtres réalistes, séquencement, ressources d’exploitation), on se retrouve avec un plan “théorique” impossible à exécuter proprement en conditions réelles.
Risques humains & adoption
Enfin, beaucoup de migrations techniquement réussies sont vécues comme un échec car :
- les utilisateurs ont le sentiment de subir un changement imposé,
- les équipes support et admins ne sont pas prêtes à absorber la vague de questions,
- les bénéfices attendus ne sont pas visibles, faute de communication et d’accompagnement.
Le risque : shadow IT, contournements, discours négatif sur la DSI, et une plateforme Cloud perçue comme moins utile que l’ancienne, alors même qu’elle offre plus de possibilités.
Les 7 erreurs majeures qui font dérailler les migrations Atlassian Enterprise
Dans les faits, les quatre familles de risques se traduisent presque toujours par les mêmes erreurs de pilotage. En voici sept, que nous voyons revenir en boucle dans les projets Enterprise.
Erreur n°1 – Sous‑estimer le périmètre réel de la migration
On pense “migrer Jira + Confluence”, mais on découvre au fur et à mesure :
- des instances parallèles ou historiques,
- des projets/espaces critiques “cachés”,
- des intégrations non recensées,
- des environnements (test, pré‑prod) oubliés.
Résultat : planning qui explose, arbitrages en catastrophe, perte de confiance des métiers.
Nous conseillons d’imposer un assessment structuré : inventaire outillé, criticité, propriétaire métier, périmètre validé en comité de pilotage avant de parler dates.
Erreur n°2 – Traiter l’identité & les accès comme un sujet secondaire
L’email et le SSO sont centraux en Cloud / Enterprise, mais souvent traités en fin de projet :
- domaines d’email hétérogènes, comptes doublons, comptes de service flous,
- modèle SSO / IdP non stabilisé,
- impacts sur groupes et permissions sous‑estimés.
On se retrouve avec des utilisateurs qui ne se connectent pas, des droits incohérents, des tensions avec la sécurité.
Nous conseillons de créer un workstream dédié “Identité & Accès”, piloté avec l’IAM, et figent tôt domaines, IdP, SSO, MFA et principes de gestion des comptes.
Erreur n°3 – Sous‑estimer l’impact des apps Marketplace et des macros
Des pans entiers de process reposent sur des apps (ITSM, PPM, reporting, scripting, connecteurs) et macros Confluence.
Or toutes ne sont pas disponibles ni équivalentes dans la cible, et toutes ne migrent pas leurs données.
Sans analyse sérieuse, on découvre post‑migration :
- des tableaux de bord vides,
- des formulaires inutilisables,
- des données d’app perdues.
Nous conseillons d’inventorier et classee les apps (critique / important / optionnel), valident les cibles et les chemins de migration des apps critiques, et préparent un plan B quand nécessaire.
Erreur n°4 – Migrer une instance “telle quelle” sans assainir données et configuration
Workflows labyrinthiques, champs obsolètes, projets/espaces jamais archivés, permissions héritées de couches successives…
Projeter tout cela tel quel, c’est :
- augmenter les risques d’erreur,
- rendre l’instance cible lourde à exploiter,
- rater une occasion de simplifier.
Nous conseillons de prévoir un chantier d’assainissement en amont : archivage, rationalisation, correction d’incohérences, aligné sur une cible plus standardisée.
Erreur n°5 – Limiter les migrations de test au strict minimum
Par manque de temps/budget, on se contente souvent :
- d’un pilote unique, sur un périmètre peu représentatif,
- de tests surtout techniques,
- de peu d’implication métier.
Les vrais problèmes (volumétrie, cas particuliers, intégrations) surgissent alors en production.
Nous conseillons de réaliser plusieurs migrations de test sur des périmètres représentatifs et construisent un runbook détaillé, ajusté à chaque itération, avec de vrais tests métiers.
Erreur n°6 – Négliger le change management et la communication
Vue utilisateurs, la migration, ce n’est ni le licensing ni l’architecture : c’est “mon outil a changé”.
Sans explication ni accompagnement :
- le changement est perçu comme imposé,
- les bénéfices ne sont pas visibles,
- les irritants dominent le discours.
Nous conseillons de formuler un message simple (“pourquoi on change, ce que ça apporte, ce qui change pour vous”) et montent un plan de change : communication cadencée, supports, formation ciblée, support renforcé après bascule.
Erreur n°7 – Laisser l’IT porter seule tous les arbitrages
Quand la DSI se retrouve seule à décider des apps, des niveaux de sécurité, des compromis métiers, le projet devient un “dossier IT” plutôt qu’un projet d’entreprise. Les métiers, la sécurité, la conformité arrivent trop tard.
Nous conseillons de mettre en place une gouvernance transverse (IT, métiers, sécurité, juridique/compliance) dès le cadrage, avec quelques principes simples d’arbitrage, et s’appuient sur un partenaire externe pour apporter benchmark et neutralité.
Comment les organisations les plus matures sécurisent leur migration
Les organisations qui réussissent leurs migrations
Elles font généralement trois choses différemment :
1. Elles traitent la migration comme un programme de transformation de plateforme.
La migration est rattachée à des objectifs clairs :
- simplifier et standardiser la plateforme,
- réduire la dette technique,
- renforcer sécurité et conformité,
- accompagner la trajectoire Cloud globale.
Cela lui donne une vraie légitimité au niveau COMEX et offre un cadre pour trancher les arbitrages (apps, périmètre, calendrier) sans rester dans le registre purement technique.
2. Elles structurent le programme autour de quelques chantiers clairs.
Plutôt qu’un “gros projet fourre‑tout”, elles organisent le travail en 3-4 streams lisibles :
- Gouvernance & stratégie : cible, périmètre, sponsor, comité de pilotage, principes d’arbitrage.
- Plateforme & données : architecture cible, assainissement de l’existant, stratégie de migration.
- Sécurité & identité : SSO, MFA, comptes managés, contraintes réglementaires, modèles de permissions.
- Adoption & support : communication, formation, relais métiers, support renforcé post‑bascule.
Chacun a des objectifs, des livrables et un responsable, ce qui évite que tous les sujets remontent au même endroit en urgence.
3. Elles suivent un parcours en étapes, au lieu d’un “big bang” mal maîtrisé.
Même si le contexte varie, on retrouve souvent la même séquence :
- Assessment & cadrage : inventaire, analyse de risques, choix de cible validés en gouvernance.
- Design & remédiation : architecture détaillée, décisions sur les apps, nettoyage et standardisation.
- Pilotes & tests : migrations de test sur des périmètres représentatifs, ajustement du runbook.
- Migration de production : exécution orchestrée, pilotage dédié, plan de rollback prêt.
- Stabilisation & optimisation : support renforcé, mesure d’adoption, quick wins post‑migration.
Cette approche ne supprime pas les imprévus, mais elle change leur nature : moins de découvertes structurelles en production, plus d’ajustements maîtrisés.
Les indicateurs de succès que DSI et directeurs IT devraient exiger
Une migration peut être “réussie” techniquement, mais vécue comme un échec par les métiers.
Les organisations matures fixent donc dès le départ une grille d’indicateurs simple, lisible au niveau direction.
On peut les regrouper en trois axes : préparation, qualité de migration, adoption & valeur.
Indicateurs de préparation
Question clé : sommes‑nous vraiment prêts à migrer ?
1. Cadrage & inventaire
- % d’instances, projets Jira, espaces Confluence, files JSM cartographiés.
- % de ces éléments avec :
- propriétaire métier,
- criticité (critique / important / standard),
- dépendances majeures (apps, intégrations) identifiées.
Cela permet de sortir du “ressenti” et de voir si le périmètre réel est maîtrisé.
2. Maîtrise des apps & intégrations
- % des apps Marketplace inventoriées et classées (critique / important / optionnel).
- Pour les apps critiques :
- % avec une cible validée (Cloud/alternative),
- % avec un chemin de migration ou un plan B documenté.
- % des intégrations identifiées et évaluées.
On limite ainsi le risque de découvrir en production qu’un processus clé reposait sur une app non traitée.
3. Architecture, sécurité, identité
- Architecture cible (produits, instances, régions, options Enterprise/Isolated) validée.
- Modèle identité & accès figé :
- domaines d’email,
- IdP / SSO,
- MFA,
- principes comptes managés.
- Validation par sécurité / conformité / juridique pour les points réglementaires. Pour les organisations du secteur financier, ces contraintes sont particulièrement structurantes : nous avons détaillé dans un article dédié comment concilier migration Atlassian Cloud et exigences EBA, BaFin et DORA.
Cet ensemble garantit que la cible est acceptable au niveau COMEX, pas seulement côté IT.
4. Tests & runbook
- Nombre de migrations de test prévues vs. réalisées.
- % de scénarios métiers critiques couverts par des tests.
- Degré de complétude du runbook (séquence, durée estimée, rollback, points de décision).
L’objectif : savoir si l’on a “assez appris” avant de basculer la production.
Indicateurs de qualité de migration
Question clé : la migration se déroule‑t‑elle comme prévu ?
1. Qualité des migrations de test
- Taux de succès technique (projets/espaces migrés vs. prévus).
- Nombre et criticité des erreurs de migration, et leur statut (ouvert / corrigé / accepté).
- Écart entre durées mesurées et hypothèses initiales.
Ils servent à ajuster design et runbook avant la bascule finale.
2. Respect des fenêtres & engagements
Lors de la migration de production :
- Respect des fenêtres de coupure annoncées (heures, durée).
- Temps réel d’indisponibilité vs. cible / SLA internes.
- Nombre d’incidents majeurs liés à la migration dans les premières 24-48h.
C’est souvent ce que les métiers retiennent en premier.
3. Stabilité post‑migration immédiate
- Nombre d’incidents liés à la migration par jour + tendance (stabilisation).
- Temps moyen de résolution (MTTR).
- Points bloquants éventuels (processus impossibles ou très dégradés) et délai de correction.
L’enjeu n’est pas zéro incident, mais une maîtrise visible de la situation.
Indicateurs d’adoption & de valeur
Question clé : avons‑nous gagné quelque chose, au‑delà du “lift & shift” ?
1. Adoption des capacités de la cible
- Usage des nouvelles fonctionnalités de la plateforme (Cloud/Enterprise).
- % de projets/espaces sur des modèles standardisés vs. spécifiques.
- Réduction du nombre de patterns historiques qu’on cherchait à rationaliser.
Cela montre si l’on exploite réellement le potentiel de la nouvelle plateforme.
2. Expérience utilisateur
- Résultats de sondages post‑migration (accès, performance perçue, ergonomie, compréhension du changement).
- Volume et nature des tickets de support liés à la migration (questions d’usage vs. vrais problèmes).
On vérifie ici si le changement est accepté et si les irritants majeurs sont traités.
3. Gains concrets & trajectoire
- Réduction de la dette technique :
- instances consolidées,
- baisse de la complexité de configuration,
- charge de maintenance.
- Maîtrise renforcée :
- identité clarifiée,
- permissions mieux gouvernées,
- intégrations simplifiées.
- Impact sur les projets métiers / IT :
- time‑to‑market,
- industrialisation de processus,
- alignement avec la stratégie Cloud globale.
Ces indicateurs permettent de répondre factuellement à deux questions du COMEX :
- avons‑nous migré sans dégrader le service et la sécurité ?
- cette migration nous rapproche‑t‑elle de notre cible de modernisation ?
Le rôle d’un partenaire Platinum dans un projet de migration Enterprise
Au‑delà de 1 000 utilisateurs, une migration Atlassian devient un chantier hautement exposé (continuité, sécurité, conformité, adoption). S’appuyer sur un partenaire Platinum comme CBTW permet surtout de réduire l’incertitude et de maîtriser le risque.
Concrètement, CBTW apporte :
- des retours d’expérience sur des migrations déjà menées dans des contextes similaires,
- une méthodologie éprouvée (assessment, cartographie, runbook, checklists, plans de test et de cutover),
- une interface directe avec Atlassian sur les sujets sensibles (Cloud Enterprise, Isolated, Guard, licensing, limitations, escalades).
Pour un DSI, cela signifie un cadrage plus solide, des décisions mieux argumentées au COMEX et des équipes internes qui se concentrent sur l’essentiel (arbitrages métiers, sécurité, gouvernance), plutôt que sur l’invention de la méthode.
Dans un contexte français, un partenaire local maîtrise en outre les spécificités réglementaires et culturelles (secteurs régulés, souveraineté, conduite du changement), ce qui facilite l’acceptation de la migration à l’échelle de l’entreprise.
Conclusion : d’un risque projet à un levier de modernisation
Une migration Atlassian Enterprise n’est plus une simple opération technique. Pour un DSI, c’est un moment de vérité : faire évoluer une plateforme critique sans perdre en continuité, en sécurité ni en confiance métier.
Les projets qui dérapent se ressemblent : périmètre mal connu, dette fonctionnelle et technique migrée “as is”, arbitrages laissés trop longtemps à la seule DSI, conduite du changement traitée trop tard.
À l’inverse, les organisations qui réussissent :
- traitent la migration comme un programme de transformation de plateforme,
- structurent le chantier autour de quelques workstreams clairs (gouvernance, plateforme & données, sécurité & identité, adoption),
- s’appuient sur des migrations de test, un runbook éprouvé et des indicateurs de succès partagés avec la direction,
- mobilisent un écosystème élargi (métiers, sécurité, conformité, partenaire Platinum).
La vraie question n’est plus “comment éviter l’échec ?”, mais :
“Comment utiliser cette migration pour simplifier, sécuriser et moderniser durablement notre plateforme Atlassian ?”
C’est précisément sur ce terrain – cadrage, maîtrise des risques, valorisation post‑migration – qu’un partenaire Platinum comme CBTW peut vous accompagner, de l’évaluation initiale jusqu’à l’optimisation de votre nouvel environnement.