Migrate from Gliffy to draw.io: what the move involves
The diagram move is mainly conversion and checking, and the effort depends on whether Confluence is also leaving. If your team renews Gliffy, faces new terms, or needs diagram data on its own servers, you can keep the diagrams and change only the editor, provided Confluence stays in place. If the wiki is also leaving, the diagrams have to travel twice, so plan the work as one project. Internal Confluence or Jira administrators usually do the conversion, while an implementation partner handles the self-hosted parts such as the draw.io Docker deployment, storage integration and the wiki migration.
The draw.io side of the work is mostly configuration. The jgraph/drawio Docker image runs on your own server, and draw.io's privacy policy says diagrams are saved where the user chooses, so you decide whether files sit on a local device or a connected storage service. Ask whether your Atlassian sites and the draw.io Confluence app can reach the self-hosted instance, and confirm the app's current licensing and integration terms with the vendor, since the app is sold through the Atlassian Marketplace. The mass conversion of existing Gliffy diagrams is a separate step, so test it on a copy of a space before running it on production content.
The main risk is a diagram that looks right in a list but is wrong when opened. Build a sample set that covers complex flowcharts, custom shape libraries, linked pages and diagrams embedded in many pages, then compare each converted diagram with the original. Record which items need manual fixes, and assign an owner to sign off. Confirm with your security or compliance lead which evidence they expect for the converted diagrams, such as a record of the comparison and the storage location. Keep the original Gliffy files until the sign-off is complete, because rollback is simpler while both sources exist.
Which Gliffy capabilities map cleanly to draw.io
This table compares each Gliffy capability with its closest draw.io equivalent and marks it as clean, needs rework or gap. Use it to decide which diagrams can move as they are and which need checks, especially where Confluence or Jira runs as Data Center or Cloud. The main takeaway is that importing and editing map well, while shape libraries, Jira attachments and export settings need confirmation in your own environment.
| Gliffy capability | draw.io equivalent and what to confirm | Fit |
|---|---|---|
| Diagram editing | Browser-based editor for diagrams. Test complex diagrams after import to confirm layout and connectors hold. | Clean |
| Importing Gliffy diagrams | draw.io imports Gliffy diagrams directly. Spot-check fonts, colors and connector routing on a sample set first. | Clean |
| Shape libraries | Visio stencils import as shape libraries. Confirm how your custom Gliffy shape libraries convert before planning the move. | Needs rework |
| Confluence embedding | draw.io app for Confluence is sold through the Atlassian Marketplace. Confirm the edition that matches your Data Center or Cloud site. | Clean |
| Jira use | draw.io app for Jira is also on the Atlassian Marketplace. Confirm it covers your Jira deployment and how diagrams attach to issues. | Needs rework |
| Storage of diagram data | draw.io saves diagrams where you choose, not on draw.io servers. Confirm where Confluence or Jira attachments will live after the change. | Needs rework |
| Export to PDF and images | The self-hosted Docker image has no export server, so PDF export uses the browser print dialog unless one is configured. | Needs rework |
| Hosted export and real-time collaboration | These features process diagrams temporarily on Cloudflare servers. Teams with strict data rules should confirm whether this is acceptable. | Gap |
What data moves, and which integrations need rebuilding
A Gliffy move touches more than the diagram files. Diagrams sit inside Confluence pages, attachments, shape libraries and macros, and links from Jira issues can point at them too. Map each of these before conversion so nothing is left pointing at a removed app.
Gliffy diagram files and embedded pages
Each diagram may exist as a Gliffy object stored in a page and as an attachment that the page renders. draw.io imports Gliffy diagrams, so the conversion should be tested on a sample from each space first. Check that multi-page diagrams, layers and text labels survive, because a converted diagram that looks right is not yet a verified diagram. Compare each one against the original before the Gliffy app is removed.
Attachments and version history
Confluence attachments hold the diagram source and any exported images. Confirm with Gliffy or Perforce whether its export options return the full diagram source and history, since this document does not confirm what Gliffy's own export produces. Record which attachments are source files and which are rendered images, and keep both until the converted diagrams are signed off.
Shape libraries and custom stencils
Teams often keep custom shapes, templates and company icon sets in Gliffy. draw.io supports importing Visio stencils as shape libraries, but Gliffy's own library format is not covered by a documented import path here. Inventory each custom library, rebuild the shapes that matter as draw.io libraries, and confirm how icon sets with their own licence terms should be stored in your environment.
Macros and embedded diagram references
Pages that embed Gliffy through a macro will show a broken block once the Gliffy app is removed. Search the Confluence space for Gliffy macros and list every page that uses them, including pages in archived spaces. Replace each macro with the draw.io app's diagram or a re-embedded image, then test the page view, since a diagram that renders only in the editor will not show to readers.
Jira links and cross-product references
Jira issues, Confluence pages and external documents often link to Gliffy diagrams by URL. Those links break when the source is removed or the diagram moves. Build a link list from Jira and Confluence search, then update references to the new location. Confirm how your Atlassian instance handles broken links before cutover, so your team is not chasing them after go-live.
Where the draw.io app runs
The draw.io app for Confluence and Jira is sold through the Atlassian Marketplace, so it still depends on Atlassian. A self-hosted draw.io instance can be used with a wiki such as XWiki, which breaks that dependency. Decide before conversion which target you need, because the link rebuild differs for each.
Migration sequence from inventory to decommission
This sequence moves Gliffy diagrams to draw.io in controlled stages, so every diagram is accounted for, checked against its original and retired only after the team signs off. Each step produces a record that the next step depends on.
Inventory every diagram and the pages that embed it
Start by listing every Gliffy diagram across the Confluence spaces and Jira projects in scope, along with the page or issue that embeds each one, its owner, its last edit date and whether it is still in use. Export or record the list in a diagram register that can be reviewed by the content owners. The step is done when every space owner has confirmed the register for their spaces and any unreferenced diagrams are either marked for archive or flagged for deletion. Ask your Atlassian administrator to confirm which spaces and attachments are in scope, because the register is only as complete as the search that produced it.
Run a pilot conversion on a sample space
Pick one representative space that contains simple flowcharts, complex diagrams with many shapes and at least one diagram embedded in a page with other macros. Convert these with the draw.io Confluence app or by importing the Gliffy files, then record what changed in a pilot checklist covering layout, text, connectors, colors, fonts, links and any shapes that did not map. Use the checklist to decide whether conversion needs manual rework or a different approach for certain diagram types. The pilot is complete when the checklist is filled in for every sample diagram and the owners agree on the rework rules.
Run a parallel period with both tools available
Keep Gliffy available while teams start converting spaces and editing in draw.io, so that no diagram is lost if a conversion is incomplete. Track each converted diagram in the register with its status, the person who checked it and the date of the check. Watch for diagrams edited in both tools, since the two copies will then diverge, and agree on a rule for which copy is authoritative during this period. The step is done when all diagrams in the register have either a converted version or a documented reason to keep the original.
Cut over space by space with visual sign-off
Move one space at a time from Gliffy to draw.io, starting with the lowest-risk spaces from the pilot. For each space, the content owner compares every converted diagram with its original side by side, checks text against the source, confirms any linked pages still display correctly and then signs off in writing in the register. Keep the Gliffy originals in place until the sign-off is recorded. The cutover for a space is complete when the sign-off is on file and the team has confirmed where the diagram now lives and who can edit it.
Decommission Gliffy and record the retirement
Once every space in scope has signed off, remove the Gliffy app from the Confluence and Jira instances, following your Atlassian licensing terms and your change management process. Retain an archive of the original Gliffy files and the register according to your records retention policy, since these are the evidence that each diagram was checked. Write a retirement record that lists the apps removed, the date, the approvers and where the archive is stored. The sequence is complete when the retirement record is approved and the archive can be retrieved on request.
How the move differs for Confluence-only and Confluence-leaving teams
Teams that keep Confluence as their wiki stay inside the same page and permission model, so most of the change happens in the diagram editor. draw.io is available for Confluence through an app sold on the Atlassian Marketplace. The main work is deciding which diagrams to convert, in what order, and who signs off on each result. Confluence administrators and the owners of key spaces need to be involved early, because they control app installation and page ownership.
- App installation: Confluence administrators install and license the draw.io app, so procurement and the Atlassian admin role come first.
- Inventory: List the spaces and pages that embed Gliffy content, since those pages define the conversion scope.
- Conversion order: Convert low-risk, widely viewed pages first, then move to pages that feed approvals or audit evidence.
- Ownership: Assign a named reviewer per space to confirm that layout, labels and links still read correctly after conversion.
- Gliffy retirement: Keep the Gliffy subscription active until every page is verified, then plan its removal.
Before you start, confirm with draw.io and Atlassian how the app handles existing Gliffy content, and what happens to page history and attachments during conversion.
Some teams keep Gliffy diagrams outside Confluence, or need only a handful moved, so they import files one at a time into draw.io. draw.io lists Gliffy diagrams among its supported import formats. The work is per file: open, import, review and save. Because each check is manual, the quality of the result depends on the person reviewing it, and the team should agree on that standard before the first file moves.
- Supported formats: draw.io imports Gliffy and Lucidchart diagrams and Visio files, so confirm the exact export format your Gliffy files use before you start. The draw.io import formats page lists what is supported.
- Storage choice: draw.io saves diagrams where the user chooses, on a device or in a connected storage service, so pick the target folder or repository first.
- Visio side effects: If any source files are Visio files, expect differences in appearance and possibly lost interactive behavior, and review those diagrams in full.
- Register: Keep a simple log of file name, owner, import date and reviewer so that every diagram has an audit trail.
- Retention: Keep the original Gliffy exports until reviewers sign off on the imported copies.
Ask the team that owns the source files to confirm which export format they hold before anyone starts importing, because that choice sets the review effort for the whole batch.
When Confluence is leaving as well, diagrams move together with the pages that contain them. XWiki is a self-hostable wiki licensed under the LGPL 2.1, and its official Docker images come in MySQL, PostgreSQL and MariaDB variants on Tomcat. draw.io lists XWiki among its integrations, so diagrams can be edited in the wiki environment after the move. XWiki SAS offers Confluence Migrator Pro, which moves spaces, pages, users, groups, permissions and attachments. It keeps page history but not attachment history.
- Macro mapping: Confirm how the migrator treats Gliffy content and draw.io diagrams in pages, since every diagram reference must still resolve after the move.
- Attachment history: Plan for losing attachment history, and archive older versions if audit or legal hold requirements apply.
- Trial limits: The trial is limited to 30 pages per migration, so test a representative sample before a full run. XWiki Store lists the migrator from 2000 EUR, and that license is a separate cost from the wiki itself.
- Hosting: Choose the database variant and image tag from the official library, and decide whether XWiki runs in your infrastructure or on XWiki Cloud.
- Users and access: Verify group and permission mapping with the identity team before cutover, because access errors are harder to spot than layout errors.
Ask XWiki SAS to confirm in writing how each migration step treats diagrams, attachments and permissions for your Confluence version.
What usually goes wrong when diagrams are converted
Converting Gliffy diagrams to draw.io rarely fails all at once. The problems are quiet: shapes shift, links break, and diagrams nobody checked get treated as correct. Each card below names one risk and the check that prevents it.
Visual drift after conversion
An imported diagram can look different from the Gliffy original. Fonts, connector routing, line spacing and shape sizing may shift, and a diagram that reads correctly in Gliffy can become hard to follow. draw.io warns that Visio imports may look different from the original, and the same caution applies to Gliffy files. Export a sample of converted diagrams to PNG or PDF, place them beside the Gliffy originals, and compare every connector and label before you approve a batch.
Lost interactive behavior
Gliffy diagrams often carry links, hover data or other interactive behavior that a reader depends on. draw.io's own documentation says Visio imports may lose interactive behavior, so treat Gliffy imports the same way. Before migration, list every diagram that contains hyperlinks or interactive elements, then open each converted version and click through the links. Record any that no longer work and rebuild them by hand in draw.io.
Broken macro and page references
Gliffy diagrams embedded in Confluence pages are referenced by the page, not stored only as image files. When a diagram is replaced, the page macro can point to a missing or stale object, and a diagram embedded in several pages may appear in some and not others. Inventory the pages that embed each diagram, convert them in the same batch, and open a sample of pages after the change to confirm that each embed renders the expected diagram.
Unverified diagrams left behind
Teams often convert the diagrams they use and leave the rest in the old system. Old diagrams then become unverified copies that people still search for and sometimes edit. Assign each diagram an owner, mark it as converted, verified, archived or retired, and set a date for decommissioning the Gliffy source. Archived diagrams should stay readable in their original format until that date, so nothing is lost in a rushed cleanup.
Cutover before users are trained
If the switch happens before editors know where diagrams live and how draw.io saves them, people will create new diagrams in the wrong place or edit the converted copy while others edit the original. Train editors on opening, saving and storing diagrams in draw.io, and confirm which storage location is approved. Run a short pilot with a small group, then switch the remaining teams once the pilot team reports no storage or editing confusion.
What drives cost and duration in a Gliffy migration
This table lists the factors that change how much internal time, partner scope and verification work a Gliffy to draw.io move needs. Read each row as a lever: the first column names the driver, the middle column explains why it moves cost, and the last column gives a way to keep it under control. The main takeaway is that inventory and the audit verification depth matter more than the conversion tool itself.
| Driver | Why it moves cost or effort | How to keep it down |
|---|---|---|
| Diagram count | Every converted diagram needs a check that shapes, connectors and labels survived, so review time grows with the number of files. | Inventory all Gliffy diagrams first, then retire unused or duplicate ones before conversion starts. |
| Page count and macro placements | Diagrams embedded in many pages must be checked in each location, and a single diagram reused across pages can multiply review work. | Count placements, not only diagrams, and confirm which pages still render correctly after conversion. |
| Number of Confluence spaces | Each space has its own owners, permissions and page trees, so coordinating sign-off across spaces adds internal time. | Group spaces by owner and migrate one owner group at a time, with a named reviewer for each. |
| Custom shape libraries and stencils | Custom shapes may need to be recreated or imported as draw.io libraries, which is design work rather than file conversion. | Catalog custom shapes early and decide which ones are still used before rebuilding any of them. |
| Jira usage | Diagrams attached to Jira issues or used in Jira apps need separate testing, since the Jira app and its storage differ from Confluence pages. | Confirm with the Jira owners which issues hold diagrams, and include them in the same inventory. |
| Whether Confluence is leaving | If Confluence is also moving to a self-hosted wiki such as XWiki, diagrams must move twice (conversion and page migration), and the wiki's diagram integration must be tested. | Decide the wiki target before converting, so diagrams are converted once into the final storage location. |
| Verification depth required by audit | Auditors may ask for evidence that diagrams are complete and unchanged, which means sampling, comparison records and sign-off, not just a successful import. | Agree the sampling method and evidence format with the auditor before the work starts, and keep a conversion log. |
| Hosting of the draw.io instance | A self-hosted draw.io needs a server, a web tier and updates, which are recurring costs whether or not the migration is large. | Use the existing platform team's container and patch process, and ask the partner to quote hosting as a separate line. |
| Support and ongoing upgrades | Upgrades, security fixes and user questions after cutover are recurring effort, and their size depends on how many teams depend on the diagrams. | Ask for a written support scope and decide internally who owns draw.io after go-live. |
Questions teams ask before moving Gliffy diagrams
Can our team move Gliffy diagrams to draw.io without outside help?
Yes, most teams can convert and check diagrams with their own staff, but the work is easier to plan when you know the volume and the wiki you will run afterward. Individual Gliffy files can be imported into draw.io, and draw.io's documentation lists Gliffy among the formats it imports. The deciding factors are how many diagrams you have, whether they are tied to Confluence pages or other content, and whether someone on your team can own the self-hosted draw.io or wiki setup and its backups. If those skills or hours are scarce, a fixed-scope engagement can take that work off your plate, with scope and deliverables agreed in writing before work starts.
What drives the effort and time for a Gliffy to draw.io migration?
The main drivers are diagram count, how many diagrams need manual checking, and how deeply they are embedded in pages. Converted diagrams are not always identical, so each one needs a visual review, and draw.io's documentation warns that imported Visio diagrams may look different and may lose interactive behavior. Other drivers include the number of Confluence spaces involved, how many people must approve diagrams, and whether you also need a self-hosted wiki. Ask any provider for a written inventory of diagrams and spaces, a checking method for each diagram type, and the milestones they will deliver before they quote a timeline.
What does the migration need from our Confluence and infrastructure admins?
Admins typically need to approve installed apps, provide access to the Confluence spaces that hold Gliffy diagrams, and decide where diagram files will be stored. The draw.io app for Confluence is sold through the Atlassian Marketplace, so purchasing and app installation go through your Atlassian administrators. If you run draw.io yourself, the official jgraph/drawio Docker image is built on Tomcat, so your platform team will need to provide a host, TLS, backups and upgrades. Confirm these responsibilities with your admins before work starts so that no step waits on an approval.
Does draw.io keep our diagrams on our own servers?
Diagrams can stay on your own servers if you deploy draw.io yourself, because draw.io's privacy policy says diagrams are saved where the user chooses, on a device or in a connected storage service, and never on draw.io's servers. The policy also notes that hosted export and real-time collaboration process diagrams temporarily on servers run by Cloudflare, so you should decide whether those features are in use. A self-hosted image does not include an export server, so PDF export uses the browser print dialog unless you configure one. Review the trust page with your security team and map each feature you use to where its data goes.
Do we need a self-hosted XWiki if we leave Confluence?
You do not need XWiki to use draw.io, since draw.io integrates with several wikis and storage services, and XWiki is one of the listed options. Choose XWiki if you are also moving pages off Confluence and want a self-hosted wiki to hold them. The official XWiki Docker images come in MySQL, PostgreSQL and MariaDB variants and run on Tomcat, and XWiki Standard is the free open source version. XWiki SAS offers a Confluence to XWiki migration service and a Confluence Migrator Pro extension, which keeps page history but not attachment history, so check which attachment history your records require.
What is included in a fixed-scope engagement for this migration?
A fixed-scope engagement covers the work listed in the written scope, such as the planned deliverables, the diagrams or spaces in range, the self-hosted draw.io or wiki setup, and the checks agreed for converted diagrams. Most engagements are fixed-scope, so deliverables and timelines are agreed in writing before work starts. Ask the provider to list what is excluded, including Confluence app purchases, licensing for Atlassian or XWiki products, hardware, and ongoing support. Ongoing support, upgrades and continuous testing are available as separate retainers, so ask which items follow the migration and which need a retainer.
What does a Gliffy to draw.io migration cost to run each year?
Costs come from the Atlassian app or the self-hosted infrastructure, plus the people who convert, check and maintain the diagrams. The draw.io Confluence app is licensed through the Atlassian Marketplace, while the open source draw.io source is Apache 2.0, so self-hosting avoids an app subscription but adds hosting, backups and upgrade work. Recurring costs include hosting, staff time for upgrades and security patches, and any support plan you buy. One-time costs include conversion, visual checking and documentation. Ask any provider for a quote that separates one-time work from recurring costs, and confirm the Atlassian and XWiki license terms with the vendors directly.
How DeployOpen scopes and runs a Gliffy to draw.io migration
DeployOpen plans, implements, integrates, backs up, documents and supports self-hosted draw.io and, where a wiki is also moving, self-hosted XWiki, inside your own infrastructure. That covers the draw.io deployment from the official jgraph/drawio Docker image or Desktop installs, the connection to your storage and wiki, the backup routine for diagram data, and the runbook your administrators will use after handover. Most engagements are fixed-scope, so the scope, deliverables and timelines are agreed in writing before any work starts. A quote follows from that written scope, and DeployOpen does not publish a price list. Before you request a quote, decide which of three paths applies: the draw.io Confluence app from the Atlassian Marketplace if Confluence stays, a self-hosted draw.io instance linked to your own storage, or a move to a self-hosted wiki that also needs its pages and attachments migrated.
The scope conversation usually turns on a few facts about your estate. Confirm how many Gliffy diagrams exist, which spaces and Jira projects hold them, whether any diagrams embed Visio images or depend on Gliffy-specific links, and who owns the review of converted diagrams. Ask whether any diagrams must be kept in Gliffy's native format for records, since the converted copies will be new files. For each diagram category, record a sample set for checking, because draw.io's Visio import documentation warns that layout and interactive behavior may change. Ask the team to confirm which storage location will hold the diagrams, since draw.io saves files where the user chooses, and that choice determines where your data sits in the self-hosted setup.
A written quote should separate one-time work from recurring cost. One-time items typically include the environment build, the conversion run and checks, integration with your wiki or storage, hardening, and documentation. Recurring items include upgrades, backups, monitoring and support, which DeployOpen offers as a retainer. Ask for each item to be priced separately, and ask how the scope changes if the diagram count or the number of wiki spaces grows. Also request a statement of what the client team must provide, such as administrator access, a test wiki and named reviewers. Clear inputs keep the fixed scope accurate and make the handover to your internal team straightforward.
