When a Gliffy alternative makes sense and when Gliffy still fits
Gliffy fits teams whose diagrams can stay inside Atlassian Cloud or Data Center and who want diagramming in the same apps as their Confluence pages and Jira work. draw.io fits teams that need diagram data on their own servers or desktops, under Apache 2.0 code they can deploy and inspect themselves. A renewal, an Atlassian licensing change, a data residency rule or a plan to depend on fewer vendors usually starts the review, so first write down which of those applies. The decision then turns on three questions: where diagram data may be stored, whether the wiki is leaving Confluence at the same time, and who will run the platform once it is live.
Gliffy still fits when Atlassian's hosting satisfies your data rule and Confluence and Jira are already your system of record. In that case the cost of change is mostly migration effort and retraining, and diagramming stays inside one administrative boundary with a single set of users, permissions and support contacts. Before you decide, confirm with Atlassian and Perforce where Gliffy stores diagram data for your deployment type, which controls apply to Data Center compared with Cloud, and whether your auditors accept that location. Those answers should carry more weight than the feature list.
draw.io fits when diagram data must stay on infrastructure you control. The jgraph/drawio source is Apache 2.0, the official Docker image can run on your own servers, and the desktop app saves files wherever you choose. Your team then owns the operating work: applying new image versions, backing up the storage location, and deciding whether to configure an export server, since the image does not include one and PDF export otherwise uses the browser's print dialog. The project does not accept pull requests, so fixes depend on its maintainers and releases. Plan for that dependency before you commit, and review the draw.io deployment documentation with the engineers who will run it.
Which option fits each scenario
This table matches common team situations with the option that usually fits better and the condition that decides it. Read each row against your own platform, hosting rules and staffing, because the right answer changes when one condition changes. Confirm Gliffy's hosting and data handling options with Atlassian before deciding on any row that depends on residency.
| Scenario | Better fit | Why and the condition that applies |
|---|---|---|
| Confluence Cloud team with no residency rule | Either, based on cost and support | If diagrams only need to live in Confluence and no regulator or customer requires specific storage, staying with Gliffy avoids conversion work. Consider draw.io if licensing per user is the main pressure and you accept its Marketplace app terms. |
| Regulated team that must keep diagram data on its own servers | draw.io, self-hosted | draw.io saves diagrams where the user chooses, and the self-hosted Docker image keeps diagram handling on your infrastructure. Confirm with Atlassian whether any Gliffy option keeps data in a location you control before you rely on it. |
| Data Center customer | Confirm before choosing | Check the draw.io app versions available for your Data Center release with the Atlassian Marketplace listing. If you run Data Center on your own servers, a self-hosted draw.io instance can align with that model, but confirm Gliffy's Data Center support status with Atlassian. |
| Team leaving Confluence for a self-hosted wiki such as XWiki or BookStack | draw.io | draw.io integrates with XWiki and BookStack, and it imports Gliffy diagrams, so existing diagrams can move with the wiki. Plan the conversion as a separate step from the wiki migration and check each converted diagram. |
| Desktop-only team | draw.io Desktop | draw.io Desktop runs locally without a server, which suits teams that edit files on their own devices. Files are saved to the local disk or a storage service you choose, so you control where they sit. Real-time collaboration is not the goal of this setup. |
| Organization with no internal platform staff | Gliffy, or draw.io through a managed partner | Running a self-hosted draw.io instance means someone patches, backs up and upgrades it. If no one owns that work, keep the hosted option or contract the operation to a provider, and ask for the support and upgrade scope in writing. |
How draw.io runs inside Confluence, on a wiki or on a desktop
draw.io is available for Confluence through apps sold on the Atlassian Marketplace. Diagrams sit inside Confluence pages, so editing feels like the rest of the wiki and existing page permissions apply. Where the diagram data is stored depends on the app and on the Atlassian deployment you run, so confirm the storage location in writing before rollout.
- Storage: Diagrams are kept with the Confluence content in your Atlassian deployment. Ask the vendor whether any diagram data, previews or exports leave that deployment.
- Hosting model: Confirm whether you run the app in your own Atlassian Data Center or use Atlassian Cloud, since that decides who operates the underlying platform.
- Storage integrations: draw.io lists Google Drive, OneDrive, SharePoint, GitHub, GitLab, Nextcloud and ownCloud as services for saving or linking diagrams. Confirm which of these your app configuration allows.
- Privacy statement: draw.io's trust page says diagrams are saved where the user chooses and never on draw.io's servers. It also says hosted export and real-time collaboration process diagrams temporarily on servers run by Cloudflare.
- Licensing: Apps are bought through the Atlassian Marketplace, so ask for the license tier and renewal terms in your quote.
Check which features are enabled, where diagram data and exports go, and whether your security team accepts a Cloudflare dependency for hosted export or collaboration.
draw.io also integrates with wikis outside Atlassian, including XWiki, Wiki.js, BookStack and MediaWiki. Organizations that are leaving Confluence, or that already run an open wiki, can keep diagrams inside a wiki on their own servers. Integration depth differs by wiki, so confirm the exact mechanism for each one before you commit to it.
- XWiki: Listed among draw.io's integrations. Confirm the supported XWiki version and whether diagrams are stored as wiki attachments or in a connected service.
- Wiki.js, BookStack and MediaWiki: Each appears on draw.io's integrations list. Confirm whether the integration embeds diagrams from the wiki's own storage or from a separate storage integration.
- Storage integrations: Nextcloud, ownCloud, ONLYOFFICE, GitLab and GitHub are listed as storage options, so diagrams can sit beside documents or source code if your wiki uses them.
- Export path: Export depends on how draw.io is served. Confirm whether PDF or image exports run in the browser or through a server you operate.
- Migration sequencing: If Confluence is also leaving, move pages, attachments and diagrams together so links and embedded diagrams are checked as one set.
Check the wiki version, the integration method and the export path against your records requirements before you pick this option.
The official jgraph/drawio Docker image runs draw.io on your own server. It is based on Tomcat and is kept up to date with the production app at app.diagrams.net. Your team hosts the editor, controls the network path and decides which storage services users may connect to, which is the setup most often chosen by teams that need full control.
- Image and updates: The image is Tomcat-based and tracks the production app. Compare your image tag and update schedule against the release history on the jgraph/drawio releases page.
- Storage choice: Diagrams are saved to the device or to a connected storage service the user selects, such as Nextcloud or ownCloud, so the storage decision stays with your organization.
- Export: The image does not include an export server. PDF export uses the browser's print dialog unless you configure an export server, and no diagram data leaves the server for an export.
- Outbound calls: Confirm with the vendor which hosted features, if any, your self-hosted instance calls, and make sure your firewall rules match that answer.
- Ongoing ownership: The project does not accept pull requests, so your team carries patching, backups and upgrade testing for the instance.
Check the image version, the storage services you allow and the outbound call list with your security team before you approve the deployment.
draw.io Desktop runs on the user's computer, so diagram editing does not depend on a web service. Files are saved where the user chooses, which suits teams that need offline work or that run in restricted networks. Collaboration usually happens through shared folders or repositories rather than a live editing session, so plan the sharing method before rollout.
- Storage: Per draw.io's privacy statement, diagrams are saved on the device or in a connected storage service the user picks, never on draw.io's servers.
- Shared files: Teams often share .drawio files through a file share, Nextcloud, ownCloud or a Git repository. Confirm how versions are tracked and who can overwrite a file.
- Imports: The desktop app supports the same import formats as the web editor, including Visio .vsdx files, Gliffy and Lucidchart diagrams. Review the Visio import differences before relying on converted files.
- Endpoint management: Installing and updating the app on managed laptops is your responsibility, so check that your endpoint tooling can deploy and patch it.
- Offline work: Confirm which features need a network connection in the version you deploy, especially for export and sharing.
Check the sharing method, the endpoint rollout plan and the offline feature list with your security and endpoint teams before you choose this path.
How Gliffy and draw.io compare on capabilities and licensing
This table compares Gliffy and draw.io on licensing, maintenance, file import, export and self-hosting. Where the documented facts stop, the Gliffy column tells you what to confirm with Atlassian or Perforce rather than assuming an answer. The main takeaway is that draw.io's licensing and self-hosting terms are published, so the open questions for a switch sit mainly on the Gliffy side.
| Capability | Gliffy | draw.io |
|---|---|---|
| Source license | Commercial product from Perforce. Confirm license terms and any self-hosted rights in writing. | Source code under the Apache License 2.0. Icon sets, stencil libraries and templates have separate terms. |
| Maintenance model | Maintained by Perforce. Confirm release cadence and support terms in your contract. | Developed by a core team. The project does not accept pull requests from outside contributors. |
| File import | Confirm which external formats Gliffy opens, since the supplied facts do not cover this. | Imports Gliffy and Lucidchart diagrams, Visio .vsdx, .vsd and .vst, and .vssx and .vss stencils. |
| Formats not imported | Confirm with Atlassian whether Gliffy handles these formats. | Does not import Visio 2003 to 2010 XML or LibreOffice Draw files. Plan a manual rebuild for these. |
| Visio import fidelity | Confirm how Gliffy handles Visio files and embedded images before relying on it. | Layout may differ, interactive behavior may be lost, and embedded EMF images are not imported. |
| Export options | Confirm export formats and how diagrams appear in Confluence pages with Atlassian. | PDF export uses the browser print dialog unless an export server is configured. Hosted export runs on Cloudflare servers. |
| Self-hosting options | Confirm which Data Center or self-managed deployment options apply to your Atlassian edition. | Official Docker image based on Tomcat, kept in step with the hosted app, or the draw.io Desktop app. |
| Where diagram data is saved | Confirm storage location within your Atlassian deployment and its residency terms. | Saved where the user chooses, on a device or connected storage, and not on draw.io servers per its privacy policy. |
Where diagram data lives and who controls it
Gliffy and draw.io differ mainly in where diagram files physically sit and who can reach them. Each card below covers one layer of that question, from storage and hosting to identity and audit evidence, so you can map your own data flows before deciding.
Diagrams inside Atlassian's platform
Gliffy diagrams are stored within the Atlassian product that hosts the page, so the data location follows your Confluence or Jira deployment. Under Atlassian Cloud, that means Atlassian's infrastructure. Confirm with Perforce and Atlassian which regions, subprocessors and retention terms apply to diagram attachments and exports for your plan before you record the answer in your data inventory.
Files saved to a storage service you choose
draw.io saves diagrams where the user chooses, on the device or in a connected storage service, and its privacy policy states diagrams are never kept on draw.io's servers. Your data location is therefore set by the storage target you configure, such as Nextcloud, SharePoint or GitLab. Document which target each team uses and who administers it.
Self-hosted Docker image on your servers
The official jgraph/drawio Docker image runs on infrastructure you operate, whether in your own data center or your cloud account. Diagram data stays on that server, and your team owns patching, TLS, backups and access logs. Ask your platform team to confirm the image version, the update cadence they will follow and where server logs are retained.
Draw.io Desktop with local files
draw.io Desktop keeps diagrams as local files on the user's computer, which suits teams with no shared server or strict offline needs. The trade-off is that backup, access control and version history depend on the endpoint and the file share used. Include desktop installs in your asset inventory, since diagram files will otherwise sit outside your managed storage.
Cloudflare processing for hosted features
draw.io's privacy policy says hosted export and real-time collaboration process diagrams temporarily on servers run by Cloudflare. If you use the public app at app.diagrams.net, that processing is part of your data flow. A self-hosted image without an export server exports through the browser print dialog, so no diagram data leaves your server for export. Confirm which features your users rely on and document each one.
Access control and evidence for auditors
In Confluence, Gliffy inherits page permissions and Atlassian identity settings, while draw.io self-hosted inherits access from the wiki or storage service it connects to and the SSO you configure in front of it. Auditors will typically ask for the access list, the logging of changes and the documented data flow for each diagram store. Prepare those artifacts for both options before the migration, and treat any compliance outcome as the auditor's decision.
What the cost of each option is made of
The cost of staying on Gliffy, moving to the draw.io Confluence app, or running free self-hosted draw.io is made of different components, and only some of them show up on an invoice. Gliffy for Confluence is a recurring subscription that Atlassian bills, typically priced per user, so the main cost driver is how many people edit or view diagrams inside Confluence and Jira. The draw.io apps for Confluence and Jira are bought through the Atlassian Marketplace, which means a separate recurring line item with its own renewal date and its own per-user or tier terms. Ask Atlassian and the app vendor for the current price tables in writing, and compare them against your actual seat count rather than the headline rate.
Free self-hosted draw.io has no license fee, but it is not free to run. The recurring costs are the servers or virtual machines that host the jgraph/drawio Docker image, backups of your configuration and any diagram storage you connect, upgrades when new releases ship, and monitoring of the container so that a broken image does not stop editing. Those costs are paid to your own staff or to a partner on a retainer, and they grow with the number of environments, not with the number of users. Confirm who owns patching, who approves upgrades and whether your current hosting team already runs Docker, because the answer changes the recurring line more than the software does.
One-time costs sit underneath every option. Conversion of existing Gliffy diagrams, checking converted diagrams against the originals and rebuilding shape libraries and templates all take staff time, and the amount depends on how many diagrams you have, how much Visio content is mixed in, and how many custom stencils your teams rely on. Visio imports may look different, lose interactive behavior and skip embedded EMF images, so budget review time for any diagram that a regulator, customer or architect depends on. If you need an audit trail of who changed a diagram and when, add time to set up storage and access logging. Request a written quote from any partner that lists each of these components separately, including the recurring support or retainer, so you can compare it line by line with the Atlassian invoice.
What moving from Gliffy to draw.io involves
The sequence turns Gliffy diagrams into editable draw.io diagrams in a place the organization controls, with each step ending in a check that the diagrams, links and access still work before Gliffy is switched off.
Inventory Gliffy diagrams and the pages that use them
Someone with Confluence or Jira admin access lists every Gliffy diagram, the page or issue that embeds it, the space it sits in, and who edits it. Include diagrams stored as attachments, diagrams embedded in templates and diagrams that are referenced from other pages. Export a copy of each source file as a backup before anything changes. The step is done when the list has one row per diagram, each row names its owning page and editors, and the backup set is stored outside the Gliffy app.
Decide where draw.io will run
Choose one of three deployment paths: the draw.io app inside Confluence and Jira from the Atlassian Marketplace, a self-hosted draw.io instance from the official jgraph/drawio Docker image connected to a self-hosted wiki, or draw.io Desktop for individual users. Record who holds the decision, where diagram files will be saved, and whether any diagram data may leave your network. Confirm the current licensing and support terms for the Marketplace app with Atlassian and the draw.io team before committing. The step is done when a written decision names the deployment path and the storage location for diagram files.
Run the conversion for Gliffy diagrams
Install the chosen draw.io deployment in a test space first, then convert a small set of representative diagrams. Gliffy diagrams are supported by draw.io's import, so convert them through the Confluence app's mass conversion or by importing individual Gliffy files, depending on the path chosen. Keep the original Gliffy diagrams untouched until the checks in the next step pass. The step is done when the test space holds converted copies of the sample diagrams and the conversion log shows no failed items.
Check converted diagrams for layout and links
Compare each converted diagram with its Gliffy original side by side. Check shape positions, text wrapping, arrow connections, colors, layers, hyperlinks, and any custom shape data. Visio imports can differ from the original and may lose interactive behavior, so apply the same scrutiny to any diagram that came from Visio stencils. Record every difference in a tracking sheet with a decision: accept, fix or rebuild. The step is done when every sampled diagram has a signed-off comparison and the list of accepted differences is approved by the diagram owners.
Move shape libraries and Visio stencils
Identify the custom shape libraries, Visio stencils and templates that teams rely on. draw.io imports .vssx and .vss stencils as shape libraries, so load them into the chosen draw.io instance and confirm that shapes appear in the library panel for each user group. Keep a copy of the source files and note any stencil that could not be imported, since those need manual rebuilding. Check the licensing terms of any icon set or stencil before sharing it across the organization, because third-party libraries can carry separate terms. The step is done when each library loads for a test user and the exceptions are listed.
Update page embeds and permissions
Replace Gliffy macros on each page with the draw.io equivalent, then confirm that the diagram opens for the readers and editors who need it. Match space and page permissions to the original, paying attention to restricted pages and to templates that other spaces reuse. Test edit and view rights with a non-admin account in each group. The step is done when a sample of pages from every space renders the draw.io diagrams and a test account can view or edit only what its role allows.
Move the wiki if Confluence is also leaving
This phase applies only when the organization is moving its wiki as well. Treat it as a separate project with its own inventory, because page content, attachments and permissions must move before diagrams can be embedded in the new wiki. draw.io integrates with self-hosted wikis such as XWiki, Wiki.js, BookStack and MediaWiki, so confirm the target wiki and the draw.io integration method for it. Test the diagram links and embeds on the new wiki with the same sample set used earlier. The step is done when the new wiki renders the sample diagrams and permissions match the approved matrix.
Retire Gliffy after checks pass
Once all sampled and remaining diagrams have passed their checks, announce a cutover date to page owners and set the Gliffy app to read-only where the platform allows it. Keep the Gliffy backup and the tracking sheet for a retention period your records policy sets. Remove the Gliffy app from Confluence only after the owners confirm that no page still depends on it, and record the removal in the change log. The step is done when no page renders a Gliffy macro, the backup is stored and the change log records the removal.
Questions buyers ask before choosing draw.io over Gliffy
How much does switching from Gliffy to draw.io cost?
The cost depends on which components you buy and who does the work, so there is no single figure to compare. Gliffy costs are per-user Confluence licensing, which you stop paying after cutover. draw.io costs depend on the path you choose: the Confluence and Jira apps are sold through the Atlassian Marketplace, while the self-hosted Docker image or desktop app carries no license fee for the core editor. One-time costs include conversion, checking converted diagrams and training. Recurring costs include hosting, patching, backups and support. Ask for a quote that lists each of these separately, and confirm current Marketplace pricing with Atlassian.
How long does a Gliffy to draw.io migration take?
The pace is set by the number of diagrams, how many use Gliffy-specific shapes or links, how many need manual checking, and how much review time your diagram owners can give. Whether the wiki is also moving changes the schedule, because a Confluence-only move differs from a move to another wiki. No duration can be stated without an inventory of your diagrams. Ask DeployOpen for a timeline in writing, as part of a fixed-scope agreement with milestones for inventory, a pilot conversion, owner review and cutover. Timelines are agreed before work starts.
Can our own team migrate Gliffy diagrams without a partner?
A team can do it alone if the inventory is small and the diagrams use simple shapes. The team needs Confluence administrator rights to run any mass conversion, someone who can deploy the official jgraph/drawio Docker image or install draw.io Desktop, basic Tomcat and container operations for a self-hosted instance, backup and restore procedures, and named diagram owners who check the output. Larger inventories, custom shape libraries and compliance evidence usually need more hours and clearer ownership. Ask an implementation partner for a written scope if your team lacks any of these skills.
Do draw.io apps for Confluence keep diagrams inside Atlassian?
The Confluence and Jira apps are sold through the Atlassian Marketplace and run as Atlassian apps, so the purchase and installation path stays within Atlassian. Where the diagram data is stored and which services process it are separate questions. Confirm with draw.io and Atlassian whether the app stores diagram XML in Confluence, whether any hosted export or collaboration service is involved, and which Data Center or Cloud versions the app supports. Put the answers in writing before you approve the purchase, because data location is what most compliance reviews will ask about.
What happens to Visio and Lucidchart diagrams already stored?
draw.io imports .vsdx files directly, converts .vsd and .vst files in the browser, and imports .vssx and .vss stencils as shape libraries. Lucidchart diagrams move by copying everything in Lucidchart with the keyboard shortcut and pasting into the draw.io online editor. draw.io does not import Visio 2003 to 2010 XML or LibreOffice Draw files, so those need another route. draw.io warns that imported Visio diagrams may look different, may lose interactive behavior, and do not import embedded EMF images. Plan a visual review of each converted diagram, and treat embedded images as a manual task.
Does the Apache 2.0 license let us change draw.io internally?
The Apache License 2.0 allows you to modify draw.io and use the modified version inside your organization, provided you keep the license notices. Two points need attention. The jgraph/drawio maintainers do not accept pull requests, so your changes stay in your own fork and your team carries the merge work on each new release. Icon sets, stencil libraries and templates have separate terms, so check each library you plan to use. Have your legal team review both before you start customizing.
Will an independent auditor accept a self-hosted draw.io setup?
Independent auditors decide whether your setup meets their scope, and DeployOpen does not issue audit reports, attestations or certifications. DeployOpen can prepare systems, controls and evidence for an assessment. The facts that matter most are where diagrams are saved and what services touch them. draw.io's privacy statement says diagrams are saved where the user chooses and never on draw.io's servers, but hosted export and real-time collaboration on the public service process diagrams temporarily on Cloudflare servers. Ask your auditor early which of these paths is in scope, and document the self-hosted configuration you chose.
How DeployOpen helps evaluate, implement or move to draw.io
DeployOpen is a Chainscore Labs company that plans, implements, integrates, hardens, backs up and documents self-hosted open-source platforms inside the client's own infrastructure. For Gliffy vs draw.io, we work from a written scope that covers where diagrams will be stored, which wiki or storage services they connect to, and how the team will use them day to day.
How we scope
- We document which Confluence, Jira or self-hosted wiki pages hold Gliffy diagrams today and how many teams depend on them.
- We agree in writing where draw.io will run, either as a self-hosted Docker deployment or as desktop installs, and where files will be saved.
- We confirm which Visio, Lucidchart or Gliffy source files need conversion and which ones can be retired without loss.
How we build
- We deploy the official jgraph/drawio Docker image inside your environment and connect it to your chosen storage or wiki integrations.
- We configure export behavior, including whether a PDF export server is needed, so no diagram data leaves your servers unexpectedly.
- We test converted diagrams against a sample set, checking shapes, links and layout, and record which imports differ from the originals.
How we hand over
- We deliver the written configuration, deployment steps, user guidance and a log of conversion results for your review.
- We document the upgrade path for new draw.io releases, since the project does not accept outside pull requests and you will track its releases yourself.
- We provide a handover session so your administrators can operate the deployment, back it up and restore it without us.
How we support
- Ongoing support, upgrades and periodic testing are available as a retainer after handover.
- We can prepare configuration and evidence that your internal or external auditors may request, without issuing any audit opinion.
- We review each new draw.io release against your configuration and test it before you roll it out to production.
