This article was written by Kamil Beer, an Atlassian Engineer at iDalko.
Welcome to Part II of the “Migrating Atlassian Apps from Server to Cloud” series! Our first article covered how the add-on deployment types differ (in the example of Scriptrunner) and some tips on how to migrate the plugin and its features’ behavior when moving to the Atlassian Cloud.
We started with Scriptrunner as it was the top-selling app for On-Prem, and thus frequently deployed.
This time, we will be looking at the two most popular Confluence diagramming add-ons – Gliffy and Draw.io, the dominant players in the Atlassian tools’ diagramming field.
Let’s start with Gliffy Diagrams for Confluence. Deployed on over 20,000 instances, it’s safe to say that it will be migrated to the Cloud heavily. What should you know when you’re transferring it?
Gliffy’s developers state that the app has a complete On-Prem / Cloud feature parity, which certainly isn’t easy for an add-on to achieve. This means that after the migration, the diagrams will work the same.
There are very minor issues related to Gliffy Cloud, and unlike Scriptrunner, it doesn’t have any convoluted system integrations, it operates simply via a macro and two attachments.
When you use Gliffy on a Confluence page and save it, two files appear; a GLIFFY DIAGRAM and a GLIFFY IMAGE file. The IMAGE file shows the picture of the graph you can also use someplace else, and the DIAGRAM file works as the internal app file.
And this is the catch: When either is deleted, the macro won’t work.
Despite Gliffy having complete feature parity, it will fail if you don’t copy the relevant attachments to Cloud – if they’re forgotten, removed, or damaged. This becomes an issue when you for example reach the 250 GB limit on Standard when migrating, and decide to delete some files to save space.
The Way to Migrate Gliffy is either with the Migration Assistant or via Site import while making sure you transfer all (relevant) attachments.
When the app fails to run on a Cloud page, try troubleshooting the issue with these steps (in this order).
- Do you have Gliffy installed? (Sometimes it’s easy to forget the add-on itself)
- Was the diagram working on-prem?
- Can you see a Gliffy macro on the page?
- Is there a GLIFFY IMAGE and a GLIFFY DIAGRAM attachment used for the graph that gives the error?
- If you have multiple macros on one page, you can find the right file+chart combination by name, which should be identical (careful with renamed diagrams, their attachments sometimes retain the old name).
- Page links in transferred diagrams aren’t copied, so you need to recreate them manually. You can recognize these graphs with a link icon in the lower right corner. If there is a text link used by the macro, it will have a blue underline.
- Custom shape libraries (when you create a shape and use it as a part of the diagram) aren’t migrated and need to be re-created on Cloud.
- If you’d like to change your visualization app to Draw.io, it might be better to do so while still on-premise, as usually, you have more options to work with the app data there than on Cloud.
Draw.io, Gliffy’s main competitor, is ranked as the 5th top-selling app. Gliffy is positioned as #2.
Let’s see if there’s a different approach in migrating them.
Platform differences lie mainly in the ongoing interest of Seibert Media, the add-on’s developer, in Cloud. This means that there are features that weren’t available on Server, like collaborative editing, diagram styling, importing Visio .vsd or PlantUML files, mathematical typesetting, and listing of all graphs you use in a certain space in its left bar.
You can also change app data residency including canceling any transfers outside of Draw.io/ Confluence.
The process of transferring draw.io is similar to Gliffy and manageable via the Migration Assistant or Site Import. Yet again, page links break after the migration, which includes connections between Linked Diagrams (when a graph placed on page A is visible on page B).
Thus, you need to take one extra step to preserve the references (called pageIDs). Export the data from your On-Prem instance in the app settings, as seen below, and re-import them on Cloud. Read more on this topic here.
Just like in Gliffy, the diagrams are represented by three objects – a picture, an app file, and a macro. Again, you must copy all relevant attachments to Cloud to ensure the add-on works as before.
Other than that, there aren’t any outstanding problems on the Atlassian tracker, so the plugin should be ready for migration.
The example of Gliffy and Draw.io shows another interesting perspective of migrating apps on Cloud. It’s not always about having different features than on-prem, as was the case of Scriptrunner, but also with the reliance of the add- ons on other objects, like attachments. To ensure a smooth transfer to Cloud, it’s better to migrate all of them. If you can’t, perhaps because of storage limitations on Cloud Standard, then we recommend doing cleanup while still on-prem, as you can discover possible problems and fix them before you move.
- The 2021 Guide to Migrating Jira: Preparation, Planning, Testing, and Execution
- How to Prepare and Validate your Jira Test Instance after Changes or Migration
- Migrating Atlassian Apps from Server to Cloud – Part I: Migrate Scriptrunner
- Migration to Cloud: How to Tackle it for Small and Medium-Sized Businesses (Podcast)