Migrer vers Atlassian Cloud ne consiste pas seulement à transférer des projets, des utilisateurs et des données. Il faut décider ce qui doit migrer, adapter ce qui ne peut pas être repris à l'identique, sécuriser la bascule et préparer les nouveaux usages. BleuLemon accompagne les organisations dans leur migration de Jira, Jira Service Management, Confluence et des autres outils de l'écosystème vers Atlassian Cloud, depuis l'analyse de l'existant jusqu'à la mise en production, l'adoption et le run.
Atlassian Platinum Solution Partner · ITSM Specialized · Depuis 2008 aux côtés des DSI · Paris et Lyon
Atlassian a publié un calendrier précis de fin de vie du Data Center.
Fin des ventes Data Center aux nouveaux clients, début des changements de licences.
Dernier achat ou dernière extension pour les clients existants.
Fin de vie effective, bascule en lecture seule.
Le périmètre couvre Jira Software, Jira Service Management, Confluence, Bamboo, Crowd et les apps Data Center. Jira Align Data Center et Bitbucket Data Center restent hors périmètre.
Cette échéance ne signifie pas qu'il faut migrer dans l'urgence. Au contraire : le temps disponible est un atout stratégique.
Une instance ancienne se nettoie, se simplifie et se prépare beaucoup mieux sur plusieurs exercices budgétaires que dans les derniers mois avant l'échéance.
Attendre réduit progressivement les options : les éditeurs d'applications investissent davantage sur leurs versions Cloud, les équipes continuent à consacrer du temps aux montées de version Data Center et les nouvelles fonctionnalités Atlassian arrivent prioritairement dans le Cloud.
| Critère | Jira Cloud | Jira Data Center | Jira Server |
|---|---|---|---|
| Hébergement | Infrastructure Atlassian | Votre infrastructure ou votre hébergeur | Votre infrastructure |
| Exploitation, mises à jour | Atlassian | Vos équipes | Vos équipes |
| Personnalisation profonde | Encadrée par les API, la Forge ou les Apps | Ouverte, jusqu'au code des plugins | Ouverte |
| Résidence des données | Régions au choix selon formule et produit | Là où vous l'installez | Là où vous l'installez |
| Apps du Marketplace | Catalogue Cloud avec équivalences parfois partielles | Catalogue Data Center | Catalogue figé |
| Horizon de licence | Pas de terme annoncé | Dernier achat 30 mars 2028, lecture seule 28 mars 2029 | Hors support |
Deux programmes Atlassian accompagnent la bascule : FastShift, qui ramène une migration typique de 12 à 16 mois à 2 à 6 mois, à partir de 1 000 utilisateurs avec souscription Cloud, et Ascend, qui fournit ressources, calendriers et documentation. Nous mobilisons l'un et l'autre selon votre éligibilité.
Notre démarche en cinq temps, comprendre, cadrer, déployer, faire adopter et faire vivre, reste le fil conducteur. Pour une migration Atlassian Cloud, elle se décline en 12 étapes opérationnelles, de l'inventaire de l'existant jusqu'à l'adoption et au Run.
L'objectif n'est pas seulement de réussir la bascule technique, mais de maîtriser le périmètre, préparer les équipes et assurer la continuité de service avant, pendant et après la migration.
Produits, versions, nœuds, volumétrie, intégrations entrantes et sortantes.
Nous recensons chaque app, son éditeur, son usage réel et surtout le processus qu'elle supporte. Le sujet n'est pas seulement de savoir si une app existe en Cloud, mais de comprendre ce qu'elle fait réellement dans votre organisation.
Nous analysons les écarts fonctionnels, les contraintes techniques, les risques et les points de blocage éventuels. Cette analyse permet d'identifier ce qui pourra être repris directement et ce qui devra être adapté.
Nous décidons avec vous ce qui migre, ce qui s'archive, ce qui se décommissionne et ce qui doit être retravaillé.
Standard, Premium ou Enterprise, utilisateurs réellement actifs, région de résidence des données et besoins de sécurité. Les licences sont dimensionnées sur le périmètre cible, pas simplement sur l'existant.
Comptes dormants, projets clos, pièces jointes orphelines, doublons, champs personnalisés devenus inutiles. Une migration est aussi l'occasion de simplifier.
Annuaire, authentification unique, provisionnement automatique, groupes et rôles.
Workflows, automatisations, rapports, scripts ou apps sans équivalent direct doivent être adaptés au modèle Cloud. Nous cherchons à préserver l'usage, pas nécessairement à reproduire à l'identique le mécanisme technique historique.
Nous réalisons une première migration complète en environnement de test. Elle permet de mesurer la durée réelle, de détecter les anomalies et de vérifier les écarts entre la théorie et le comportement réel de l'instance.
Nous répétons la migration autant que nécessaire jusqu'à obtenir un résultat suffisamment stable et prévisible. Nous cherchons à arriver à la bascule avec une procédure éprouvée, pas avec une procédure supposée fonctionner.
Big bang ou migration par vagues, fenêtre de gel, communication, transfert des dernières données et recette. La stratégie dépend du périmètre et du niveau d'interruption acceptable.
Formation, accompagnement des utilisateurs, traitement des irritants, mise à jour de la connaissance, décommissionnement du Data Center et suivi après la mise en production.
Une migration réussie ne se juge pas uniquement au fait que les données soient arrivées dans le Cloud. Elle se juge aussi à la capacité des équipes à reprendre leur activité efficacement.
Les tirs de migration : ce qui sécurise réellement la bascule
Les étapes de test sont souvent sous-estimées. Pourtant, une date de bascule n'est réellement crédible que lorsqu'on sait combien de temps dure la migration, quelles actions échouent, comment corriger les problèmes, combien de temps prend la recette et comment réagir en cas d'imprévu.
Chaque tir permet de réduire l'incertitude.
La continuité opérationnelle ne se décrète pas. Elle se prépare.
La durée dépend principalement de la taille de l'instance, du nombre d'applications, du niveau de personnalisation et des contraintes de sécurité.
| Phase | Étapes | Ce qui en sort | Durée observée |
|---|---|---|---|
| Cadrage | 1 à 4 | Périmètre arrêté, sort de chaque app tranché, trajectoire chiffrée | De 2 à 4 semaines selon la taille de l'instance |
| Préparation | 5 à 8 | Données nettoyées, identités alignées, adaptations réalisées | De 4 à 8 semaines, apps comprises |
| Tirs et bascule | 9 à 11 | Durée de migration mesurée, anomalies traitées, recette signée | De 2 à 4 semaines, tirs de migration compris |
| Adoption et Run | 12 | Équipes accompagnées, Data Center décommissionné | De 4 à 6 semaines après bascule |
L'accompagnement observé va de 15 à 40 k€ HT selon le palier d'utilisateurs ; le remplacement des apps du Marketplace représente 20 à 30 % du budget. Ceci est indicatif et nécessite d'être validé lors de la proposition.
Chez un éditeur de logiciels international, la bascule de Jira, Jira Service Management et Confluence a demandé environ six mois. Bitbucket est resté hors périmètre, par choix du client. Un périmètre assumé vaut mieux qu'un périmètre subi.
Toutes les apps Data Center ne disposent pas d'un équivalent Cloud et, lorsqu'un équivalent existe, le fonctionnement ou le modèle de données peut être différent. Nous commençons donc par comprendre le processus porté par chaque app. Certaines seront migrées. D'autres remplacées. Certaines fonctionnalités pourront être reprises nativement dans Atlassian Cloud et d'autres devront être repensées.
Une ancienne instance Data Center porte souvent des comptes dormants, des groupes historiques et des droits hérités au fil des années.
Le Cloud facture notamment sur la base des utilisateurs actifs : le nettoyage des identités est donc à la fois un sujet de sécurité, d'organisation et de licences.
Le nombre de sièges doit être décidé avant la migration, pas découvert sur la première facture.
Migrer vers un service Cloud change la nature du dossier de sécurité. Journalisation, restrictions d'accès, chiffrement, jetons d'API, identité, localisation des données et applications tierces doivent être analysés dans le nouveau contexte.
Chaque app ajoute également un fournisseur supplémentaire dans la chaîne de traitement. Pour les organisations soumises à des exigences réglementaires particulières (DORA, NIS 2), ces sujets se travaillent dès le cadrage avec les équipes sécurité et conformité.
Ce que ça donne sur le terrain
Chez un client de la logistique, dont le cas reste anonymisé, des composants gérés par script ont laissé place à une matrice Assets. Un blocage a demandé près d'un an, dont neuf mois auprès d'un développeur Atlassian sans solution. D'où l'étape 2, jamais la veille de la bascule. Sur ce volet, nous travaillons notamment avec Appfire et XBlend.
Voir Licences Atlassian.
Atlassian Cloud est un service en ligne exploité par Atlassian. Cette phrase fixe la limite de l'exercice.
Ce qui est possible. Selon les produits et les formules, il est possible notamment de :
Notre solution Aquarius permet par exemple d'extraire et d'archiver des projets Jira sensibles dans une archive autonome.
Ce qui ne l'est pas. Atlassian Cloud n'est pas un Cloud exploité par l'hébergeur de votre choix.
Une donnée dont les contraintes imposent qu'elle reste dans un environnement spécifique ne peut donc pas être transférée mécaniquement dans Atlassian Cloud.
Dans certains projets, la bonne réponse peut être de conserver temporairement un périmètre en dehors du Cloud ou de choisir une autre solution pour certaines données. Nous avons déjà maintenu deux espaces Confluence en interne, par choix stratégique du client, à côté d'un périmètre migré.
La migration doit donc être décidée périmètre par périmètre, et non comme une action monolithique de toute l'organisation.
La résidence des données est proposée en Union européenne, à Francfort et Dublin, pour Jira, Confluence et Jira Service Management en formules Standard, Premium et Enterprise. Atlassian publie ses attestations SOC 2 et ISO 27001.
La souveraineté juridique porte sur le droit applicable. La souveraineté opérationnelle porte sur autre chose : continuer à fonctionner sans son fournisseur.
Le vrai test de souveraineté n'est pas l'entrée chez un fournisseur. C'est la sortie.
BleuLemon, cabinet de conseil français (Paris, Lyon), Atlassian Platinum Solution Partner depuis 2008. Six variables déterminent le coût et la durée de votre migration.
Deux formats d'entrée les mettent à plat. Choisissez selon l'ampleur du sujet.
Notre environnement Atlassian est-il encore adapté à nos usages et à nos enjeux ?
Comment sortir du Data Center Atlassian sans rupture de service ni perte d'efficacité ?
Notre cadre tient en cinq temps : comprendre, cadrer, déployer, faire adopter, faire vivre. Une migration se juge sur le dernier.
Une question qui ne trouve pas sa réponse ici se traite en trente minutes d'échange, sur votre contexte réel plutôt que sur un cas général.
Échanger avec un expertUne migration vers le Cloud ne reproduit pas nécessairement l'environnement Data Center à l'identique.
Certaines fonctions existent différemment, certaines applications doivent être remplacées et certaines personnalisations doivent être repensées.
C'est précisément pour cette raison que le travail commence bien avant la bascule.
Le coût dépend du nombre d'utilisateurs, des volumes, des apps installées, du niveau de personnalisation, des contraintes de sécurité et de la stratégie de bascule.
Nous commençons donc par qualifier ces variables avant de chiffrer la migration.
Une migration peut durer de quelques mois à davantage pour les environnements les plus complexes.
Le facteur déterminant n'est pas seulement la volumétrie : les apps, les intégrations, les droits, les personnalisations et les exigences de sécurité pèsent fortement sur le planning.
Nous les analysons une par une.
Certaines disposent d'un équivalent Cloud direct, d'autres nécessitent une autre app ou une reconstruction, et certaines fonctionnalités peuvent désormais être couvertes nativement par Atlassian.
Le bon objectif est de préserver le processus utile, pas nécessairement l'app historique.
Atlassian propose des possibilités de résidence des données selon les produits et les formules souscrites.
Le choix doit être étudié avec vos exigences de sécurité et de conformité, ainsi qu'avec les apps tierces utilisées.
Oui.
Une migration peut être organisée en une seule bascule ou en plusieurs vagues selon les produits, les populations, les dépendances et la tolérance à l'interruption de service.
Le choix se fait pendant le cadrage.
Nous commençons par déterminer lesquels répondent encore à un besoin réel.
Ceux qui doivent être conservés sont adaptés aux possibilités du Cloud ; ceux qui ne sont plus utiles peuvent être simplifiés ou supprimés.
Une migration est aussi l'occasion de ne pas reproduire dans la cible toute la complexité de l'existant.
Pour aller plus loin : Conduite du changement·Archivage Jira avant migration·Le partenariat Atlassian
