Décider de migrer vers le Cloud est une chose ; réussir la migration en est une autre. Une fois la décision prise, le risque ne vient plus de la stratégie mais de l'exécution — des données qui ne passent pas, des apps sans équivalent, des utilisateurs qui perdent leurs accès.
On ne migre bien que ce qu'on connaît. La première étape est un inventaire exhaustif : nombre d'utilisateurs et de groupes, projets et espaces, workflows et champs personnalisés, apps installées, intégrations externes (CI/CD, SSO, outils tiers). Cet inventaire révèle souvent des surprises : des projets dormants, des apps que plus personne n'utilise, des intégrations oubliées.
C'est aussi le bon moment pour faire le ménage. Migrer dix ans de configuration inutile, c'est payer pour transporter des boîtes qu'on n'ouvrira jamais. Archiver et nettoyer en amont allège la migration et améliore la performance de la nouvelle instance.
C'est ici que la plupart des migrations dérapent. Une app Data Center n'a pas forcément d'équivalent Cloud, et quand elle en a un, les données ne migrent pas toujours automatiquement.
L'évaluation des apps doit se faire au tout début, pas la veille de la migration. Une seule app critique sans chemin de migration peut justifier de repenser tout le calendrier.
Sur Data Center, les utilisateurs viennent souvent d'un annuaire LDAP/Active Directory. Sur Cloud, l'identité passe par Atlassian Account et, idéalement, par un fournisseur d'identité (SSO/SAML) avec provisionnement automatique.
Les points sensibles : la correspondance des comptes (un même utilisateur ne doit pas être dupliqué), la préservation des appartenances de groupe (dont dépendent toutes les permissions), et la gestion des comptes inactifs qu'on ne veut pas faire migrer ni facturer. Une migration d'identité bâclée se paie en tickets de support le jour du lancement.
On ne migre jamais directement en production. Les outils d'Atlassian (Jira Cloud Migration Assistant, Confluence Cloud Migration Assistant) permettent de lancer une migration vers un site Cloud de test.
Cette migration test sert à mesurer la durée réelle (déterminante pour planifier la fenêtre de bascule), valider que les données arrivent intactes, repérer les écarts de configuration, et entraîner l'équipe. On la répète jusqu'à ce que le résultat soit conforme et le déroulement prévisible.
La migration de production se fait en gelant l'ancienne instance (lecture seule) pendant le transfert, pour éviter que des données créées pendant la migration ne soient perdues. La durée de ce gel — quelques heures à un week-end selon le volume — doit être communiquée largement et planifiée hors des pics d'activité.
Un plan de retour arrière (rollback) doit exister : si quelque chose tourne mal, on sait comment revenir à l'instance Data Center sans perte. On ne décommissionne l'ancienne instance qu'après validation complète, jamais le jour même.
Le travail ne s'arrête pas quand les données sont passées. Il faut valider méthodiquement : les utilisateurs peuvent se connecter (SSO), les permissions sont correctes, les apps fonctionnent, les intégrations (CI/CD, notifications) sont reconnectées, les automatisations tournent, les rapports affichent les bonnes données.
Les premiers jours sont critiques : prévoir un support renforcé, un canal dédié pour remonter les anomalies, et une personne responsable de chaque catégorie de problème. C'est ce filet qui transforme une migration techniquement réussie en migration vécue comme réussie par les équipes.
La technologie de migration est mûre ; les outils d'Atlassian fonctionnent. La différence se joue sur la préparation : l'inventaire, l'évaluation honnête des apps, les migrations test répétées et un plan de bascule sans angle mort.
Chez Nimbax, nous accompagnons chaque migration de bout en bout — de l'inventaire à la validation post-bascule — avec un plan documenté, des fenêtres réalistes et un retour arrière toujours possible. Une migration ne devrait jamais être un saut dans le vide.
