Comment migrer draw.io du Data Center vers le Cloud

Pourquoi draw.io mérite une attention particulière dans votre plan de migration

Si vous planifiez une migration Atlassian Data Center vers le Cloud, la liste est longue : contenu Confluence, configurations de projets Jira, automatisations, intégrations, scripts personnalisés et applications. draw.io est une de ces applications qui ne peut pas être traitée comme un détail secondaire.

L’outil de Cloud Migration Assistance (CMA) d’Atlassian prend en charge l’essentiel du travail lors du passage du Data Center vers le Cloud. Mais les applications ne migrent pas toujours proprement d’elles-mêmes, et draw.io est un cas où la migration standard transfère la majorité des données tout en laissant quelques éléments qui demandent une attention manuelle.

La bonne nouvelle : le processus de migration de draw.io est bien documenté et l’outillage est solide. Comprendre ce processus en amont fait la différence entre une bascule propre et une session de nettoyage post-migration dans l’urgence.

Si vous n’avez pas encore mené de préparation plus large en amont de la migration, notre article sur les délais de migration détaille notamment le nettoyage des données à effectuer au préalable. Remettre vos espaces Confluence et vos projets Jira en ordre avant la migration réduit la complexité sur tous les plans, y compris pour draw.io.

Ce que signifie la fin de vie de Data Center pour vous

Atlassian a fixé une feuille de route de fin de vie claire pour Data Center :

• 30 mars 2026 (déjà passé) : arrêt des ventes de nouvelles licences pour les nouveaux clients
• 30 mars 2028 : arrêt des ventes de licences pour les clients existants
• 28 mars 2029 : dernier jour de support de Data Center

Notre calendrier complet de fin de vie de Data Center détaille chacune de ces échéances et les options pour s’y préparer.

Cette dernière échéance peut sembler lointaine, mais les migrations à grande échelle demandent du temps à planifier et à exécuter. Les organisations comptant des milliers d’utilisateurs, plusieurs instances Atlassian ou des dépendances applicatives complexes commencent généralement à planifier 12 à 18 mois avant la date de mise en production cible. Si vous êtes dans cette fenêtre, la migration de draw.io devrait déjà figurer sur votre liste.

Pour les équipes qui évaluent leurs options d’accompagnement, Atlassian propose une assistance par paliers : outillage en libre-service pour les équipes de moins de 1 000 utilisateurs, programme FastShift pour 1 000 à 5 000 utilisateurs, et Solution Design Acceleration pour les organisations de plus de 5 000 utilisateurs. Nous avons détaillé FastShift et ses alternatives si vous pesez le pour et le contre.

Que devient réellement vos diagrammes draw.io ?

Les données de vos diagrammes draw.io ne sont pas stockées dans une base séparée, et elles ne sont jamais envoyées aux serveurs de draw.io lors de l’enregistrement d’un diagramme. Elles vivent à deux endroits :

• Les pièces jointes : les fichiers de diagramme eux-mêmes, stockés comme pièces jointes de page Confluence ou de ticket Jira
• Les macros : les références intégrées dans les pages et les tickets qui affichent ces diagrammes

Le comportement pendant la migration diffère entre Confluence et Jira, mieux vaut donc comprendre chacun séparément.

Dans Confluence : la migration standard Atlassian transfère automatiquement les pièces jointes et les macros. Vos diagrammes ne disparaissent pas. Le problème, c’est que les identifiants de page changent dans l’instance Cloud. Si certains de vos diagrammes contiennent des liens vers d’autres pages Confluence, ou si vous utilisez la macro d’intégration de draw.io pour afficher un même diagramme sur plusieurs pages, ces références doivent être mises à jour pour refléter les nouveaux identifiants.

Dans Jira : le défi est structurel. Data Center stocke les diagrammes draw.io sous forme de paquets binaires versionnés qui incluent l’historique complet des révisions de chaque diagramme. L’API de Jira Cloud ne peut pas lire ce format : une étape de conversion est donc nécessaire avant la migration. Cette conversion est à sens unique, sans retour arrière possible, ce qui augmente l’enjeu de la préparation.

Migration draw.io de Data Center vers le Cloud dans Confluence : étape par étape

La documentation officielle décrit deux approches selon votre environnement.

Option 1 : la méthode de préservation des identifiants de page (recommandée)

Dans certains scénarios de migration, l’outillage d’Atlassian préserve les identifiants de page d’origine de votre instance DC. Dans ce cas, les liens internes des diagrammes se résolvent correctement dans le Cloud sans étape supplémentaire côté draw.io. C’est l’approche à privilégier, en particulier lors d’une migration depuis d’anciennes versions DC ou Server.

Option 2 : l’outil de migration draw.io

Si la préservation des identifiants de page n’est pas possible, draw.io propose un outil de migration dédié. À n’utiliser qu’après avoir confirmé avec le support draw.io que c’est la solution adaptée à votre configuration.

1. Arrêter le service Synchrony pour suspendre l’édition collaborative
2. Aller dans la configuration draw.io, ouvrir l’onglet Cloud Migration et cliquer sur Start
3. Télécharger le rapport de migration et copier la commande de configuration linkAdjustments
4. Exécuter la migration Confluence Atlassian standard
5. Vérifier les permissions d’espace dans le Cloud : les administrateurs ont besoin d’un accès en écriture, les utilisateurs d’un accès en lecture
6. Coller le code de configuration linkAdjustments dans les paramètres draw.io de votre instance Cloud
7. Lancer une réindexation pour valider tous les liens de diagrammes

Besoin d’aide pour votre migration Confluence ? Contactez notre équipe pour voir comment nous pouvons accompagner draw.io et l’ensemble de votre migration Atlassian.

Migration draw.io de Data Center vers le Cloud dans Jira : étape par étape

Le guide de migration Jira détaille le processus de conversion, mais un point prime sur tous les autres.

1. Dans votre instance Jira DC, aller dans Settings > Apps > draw.io Configuration et ouvrir l’onglet Server to Cloud migration
2. Cliquer sur Migrate pour convertir tous les diagrammes au format compatible Cloud
3. Télécharger et conserver le rapport de migration pour référence en cas de problème
4. Effectuer la migration Jira Atlassian standard vers le Cloud
5. Dans votre instance Jira Cloud, aller dans Settings > Apps > draw.io Configuration et cliquer sur Start Indexing

Sur le timing : exécutez la migration draw.io de Jira juste avant votre bascule, pas plusieurs jours à l’avance. Passez votre instance sur site en lecture seule dès que la migration est lancée. Tout nouveau diagramme créé dans DC après la conversion ne sera pas transféré au format compatible Cloud.

Avant de commencer : ce qu’il faut absolument bien faire

Quelques points qui prennent régulièrement les équipes au dépourvu pendant la migration draw.io :

• Vérifier la compatibilité des versions en premier : confirmer que draw.io respecte les prérequis de version minimum avant toute autre chose
• Tester sur un clone de production : non négociable pour Jira, fortement recommandé pour Confluence
• Intégrer la fenêtre de migration dans le planning : la conversion de format Jira ajoute du temps au processus de bascule
• Conserver les deux rapports de migration : les outils Confluence et Jira génèrent chacun un rapport précieux pour le dépannage post-migration
• Caler le timing sur Jira : l'outil de migration draw.io doit tourner le plus près possible de la bascule, pas plusieurs jours avant

Si vous consolidez également plusieurs instances Atlassian dans le cadre de cette migration, gardez à l’esprit que les étapes de migration de draw.io s’appliquent instance par instance — ce contexte est directement pertinent pour planifier votre séquence de bascule.

Comment Seibert Solutions peut vous accompagner

draw.io n’est qu’une pièce d’une migration bien plus vaste. Pour les DSI qui planifient le passage d’Atlassian Data Center vers le Cloud, la couche applicative est souvent l’endroit où les migrations se complexifient — et celui où la bonne préparation permet d’économiser le plus de temps et de coûts.

Seibert Solutions fait partie de Seibert Group, l’entreprise à l’origine de draw.io. Cela signifie que lorsque les questions sur draw.io dépassent ce que couvre la documentation, notre équipe a un accès direct aux ingénieurs qui l’ont conçu. Cas particuliers, configurations inhabituelles, comportements spécifiques à une version : nous pouvons obtenir des réponses que d’autres partenaires ne peuvent pas obtenir.

Mais nous intervenons sur l’ensemble de la migration, pas seulement sur draw.io. Dans le cadre de notre accompagnement à la migration cloud, nous menons une analyse applicative sur l’ensemble de votre environnement Atlassian. Cela signifie passer en revue chaque application actuellement en service sur Data Center et évaluer ce que vous utilisez réellement. Il est courant que des organisations paient des licences pour des applications qu’elles n’utilisent plus activement, des outils redondants qui remplissent la même fonction, ou des applications sans équivalent Cloud qui nécessitent une stratégie de remplacement.

Cette analyse révèle généralement des économies substantielles : licences à abandonner, outils à consolider, et paliers de tarification Cloud mieux adaptés à votre usage réel. Pour les équipes présentes sur Data Center depuis plusieurs années, ce recalibrage de la couche applicative compense souvent une part significative de l’investissement de migration.

Que vous en soyez au stade de la planification ou en pleine migration, nous pouvons intervenir à vos côtés.