En combien de temps migrer vers le cloud Atlassian ?

Chaque migration vers le cloud Atlassian, quelle que soit sa taille, suit les mêmes phases principales. Seules la durée et la complexité de chaque phase varient.

Les phases se présentent comme suit :

1. Évaluation et analyse : auditez vos instances Jira et Confluence actuelles (applications, intégrations, utilisateurs, volume de données et personnalisations). C’est à cette étape que vous déterminerez précisément votre environnement de travail.
2. Planification et définition du périmètre : définissez votre approche de migration, sa séquence et ses critères de réussite. Identifiez les responsables de l’intégration et les dépendances à résoudre avant la migration.
3. Exécution : le travail de migration proprement dit — migration des données, basculement de l’application, transition des utilisateurs et tests.
4. Mise en production et assistance renforcée : migration vers le cloud, surveillance étroite et accompagnement des utilisateurs pendant la période de transition.

Le nombre d’utilisateurs est un indicateur initial utile de la complexité, même s’il ne donne pas une image complète — nous aborderons les autres variables dans un instant.

Les petites organisations dont les instances sont relativement simples sont souvent les meilleures candidates pour une migration rapide. Si vous avez un nombre gérable d’applications Marketplace, peu de scripts personnalisés et des données propres, une migration bien menée peut être rapide.

Qu’est-ce qui allonge la durée d’une migration dans une petite organisation ?

• Un grand nombre d'applications tierces, notamment celles qui n'ont pas d'équivalent direct dans le cloud.
• Des flux de travail ou des automatisations fortement personnalisés, mis en place au fil des années.
• Capacité informatique interne limitée pour gérer le projet en parallèle des tâches quotidiennes.
• Nettoyage des données à effectuer avant la migration (utilisateurs inactifs, projets archivés nécessitant des décisions).

Même au niveau des petites organisations, le fait de ne pas réaliser d’évaluation coûte généralement plus de temps que l’évaluation elle-même.

C’est là que la complexité se manifeste véritablement. Les entreprises de taille moyenne utilisent souvent simultanément Jira Software, Jira Service Management et Confluence, ce qui implique une plus grande quantité d’applications, davantage d’intégrations avec d’autres outils d’entreprise et un plus grand nombre d’intervenants dans le processus de validation.

À cette échelle, la phase d’évaluation se complexifie considérablement. Vous serez probablement amené à collaborer avec plusieurs chefs de projet ayant leurs propres méthodes de travail, des responsables d’intégration à consulter et une liste d’applications dont la compatibilité avec le cloud doit être soigneusement vérifiée.

Ce qui prolonge les délais dans cette plage :

• Migrations de Jira Service Management (celles-ci ont tendance à être plus complexes que les migrations de logiciels ou de projets d'entreprise).
• Intégrations avec les systèmes RH, les fournisseurs d'identité ou les outils de sécurité d'entreprise.
• Plusieurs unités commerciales présentant différents niveaux de préparation à la mise en service.
• Planification de la migration progressive à travers les segments d'instance.

Une approche progressive — migration par équipe, domaine de produit ou segment d’instance — est courante à ce niveau et justifie généralement le surcoût de planification.

Les migrations d’entreprise constituent une catégorie de projet différente. À cette échelle, il faut souvent gérer de multiples instances Atlassian réparties entre les différentes unités commerciales ou zones géographiques, un écosystème d’applications vaste et diversifié, des exigences complexes en matière de gestion des identités et des accès, ainsi qu’une cartographie des parties prenantes qui dépasse largement le cadre de l’équipe informatique.

La phase de planification à elle seule peut prendre deux à trois mois. Développer les capacités internes du projet, aligner les parties prenantes au sein de l’organisation et séquencer la migration de manière à minimiser les perturbations pour les équipes actives prennent du temps.

Ce qui est typique à l’échelle de l’entreprise :

• Une équipe projet interne dédiée, souvent accompagnée d'un partenaire de migration.
• Exécution progressive sur 6 à 12 mois, avec la mise en service de différentes équipes ou instances à des moments différents.
• Un travail important de développement et d'intégration d'applications est nécessaire avant que la migration puisse commencer.
• Une période de surveillance intensive de 4 à 8 semaines après la mise en service est nécessaire avant que le projet ne soit considéré comme achevé.

Il convient également de noter que les migrations à l’échelle de l’entreprise qui débutent en 2026 sont très différentes de celles qui débutent en 2028. La fin de vie d’Atlassian Data Center étant prévue pour mars 2029, les organisations de ce niveau réduisent les risques opérationnels en commençant leur migration plus tôt.

Le nombre d’utilisateurs vous donne une fourchette approximative. Ce sont ces variables qui vous font vous situer à l’intérieur de cette fourchette, ou au-delà.

Chaque application de votre instance actuelle doit être évaluée : existe-t-il un équivalent dans le cloud ? Ses fonctionnalités sont-elles identiques ? Une migration est-elle possible, ou faut-il exporter, transformer et réimporter les données ? Pour les organisations disposant de 20 à 50 applications, voire plus, ce travail peut à lui seul rallonger la phase d’évaluation de plusieurs semaines.

Les scripts ScriptRunner, les post-fonctions, les validateurs personnalisés et les workflows Jira fortement personnalisés ne sont pas automatiquement transférés. Il est nécessaire de les inventorier, de les examiner, puis de les recréer ou de les remplacer. Plus les personnalisations se sont accumulées au fil des ans, plus cette opération est longue.

Les connexions aux systèmes RH, aux fournisseurs d’identité, aux pipelines CI/CD et autres plateformes d’entreprise doivent souvent être reconfigurées ou reconstruites pour le cloud. Identifier rapidement les responsables de l’intégration et obtenir leur engagement sur le projet est l’un des aspects les plus souvent sous-estimés par les organisations.

Migrer des années de données historiques est gérable. Migrer des années de données désorganisées, en revanche, est beaucoup plus complexe. Les utilisateurs inactifs, les projets non archivés et les configurations dupliquées rallongent les délais d’évaluation et d’exécution. Les organisations qui nettoient leurs données avant la migration partent avec un avantage considérable.

On néglige souvent cet aspect. Une migration bien planifiée peut néanmoins s’éterniser si l’équipe interne doit gérer d’autres priorités. Obtenir l’engagement de temps dédié au projet — de la part du service informatique, des responsables d’applications et des parties prenantes chargées de l’approbation — est aussi important que le travail technique lui-même.

La manière dont vous migrez a presque autant d’impact sur votre calendrier que la taille et la complexité de votre instance.

Le « lift-and-shift » consiste à migrer l’ensemble des données en une seule opération. Cette méthode est généralement plus rapide à mettre en œuvre et plus simple à gérer, puisqu’elle évite de maintenir deux environnements parallèles. Elle convient parfaitement aux instances plus petites et moins complexes où le risque lié à une seule migration est gérable.

La migration par étapes consiste à migrer par segments : par équipe, par type de projet, par unité commerciale ou par instance. La durée totale est généralement plus longue, mais chaque migration est plus courte et moins risquée. Les perturbations pour les équipes actives sont mieux maîtrisées et vous pouvez tirer des enseignements des phases précédentes avant d’aborder les plus complexes.

Pour la plupart des entreprises de taille moyenne et des grandes entreprises, une approche progressive justifie le surcoût de planification. La question n’est pas seulement « comment migrer vers le cloud ? » mais « comment y parvenir sans incident majeur qui compromette le projet pour l’entreprise ? »

Peu importe où vous en êtes dans le processus de planification, vous pouvez dès maintenant prendre des mesures qui réduiront directement le délai de migration par la suite.

• Commencez l'audit de vos applications. Récupérez la liste complète de vos applications Marketplace et vérifiez la compatibilité de chacune avec le cloud. Vous pouvez commencer cet audit avant même le lancement d'un projet officiel, et les résultats obtenus influenceront la suite.
• Identifiez les responsables de vos intégrations. Cartographiez tous les systèmes connectés à vos outils Atlassian et identifiez les responsables de chacun. Impliquer ces personnes dès le début permet d'éviter les retards les plus fréquents en cours de projet.
• Nettoyez vos données. Archivez ou supprimez les projets obsolètes, désactivez les utilisateurs inactifs et corrigez les problèmes de qualité des données connus. La migration de données propres est plus rapide et réduit le risque de problèmes lors des tests.
• Obtenez l'aval du responsable interne du projet. Les migrations sont bloquées lorsque les approbations et les décisions ne sont pas clairement attribuées. Faites confirmer et définir le soutien de la direction avant le début des travaux.
• Commencez à planifier dès maintenant, pas en 2028. Les organisations qui anticipent le processus avec deux ou trois ans d'avance ont le luxe de bien faire les choses. Celles qui attendent devront se disputer les partenaires de migration, prendre des décisions précipitées et supporter le coût d'un projet bâclé.

Une fourchette est utile pour planifier les discussions. Un calendrier précis, basé sur votre parc applicatif réel, la complexité des instances et la capacité de votre équipe, est indispensable pour s’engager pleinement dans un projet.

Notre évaluation de migration du centre de données vers le cloud vous offre précisément cela :

• Un examen structuré de votre environnement actuel.
• Un calendrier de migration réaliste, adapté à votre organisation.
• Une analyse des écarts en matière d'applications et d'intégrations.
• Une image claire de ce à quoi ressemble réellement votre passage au cloud.