Gliffy cost vs draw.io: where the money actually goes
In a Confluence-heavy organization, the renewal conversation usually starts with one line item: the per-user Gliffy subscription for Confluence. Self-hosted draw.io removes that recurring per-user fee, because the source code is licensed under the Apache License 2.0 and the Docker image can run on your own server. It does not remove cost. It moves cost from a vendor invoice to your payroll, your infrastructure and your change calendar. Gliffy's price and the draw.io Confluence app's price are not part of the material behind this page, so take both figures from your own Gliffy quote and from the Atlassian Marketplace listing for the draw.io app, and compare them with the same user count, the same Confluence deployment type and the same term.
The recurring costs on the draw.io side are the ones to model. The first is hosting: the official jgraph/drawio Docker image runs on Tomcat, so you need a host, a TLS endpoint, backups and a patch routine that tracks the image releases. The second is the export path. The image does not include an export server, so PDF export uses the browser print dialog unless you configure one, and that choice affects how many users can export without friction. The third is the integration layer, meaning the connection between draw.io and the wiki or Atlassian product your teams use. Ask whoever will own that connection how many hours a quarter they expect it to take, and record the answer as an assumption.
The one-time costs are conversion and checking. draw.io imports Gliffy diagrams, but converted diagrams still need a review pass, and the Gliffy-to-draw.io migration is the largest single effort in this comparison. Budget the people who will check diagrams, the time to fix converted shapes, and the work of deciding which diagrams to retire. Ask any implementation partner, including DeployOpen, for a fixed-scope written quote that lists the diagram count, the hosting model, the conversion and checking tasks, and the support level, so that you can compare it line by line with the Gliffy renewal.
Cost components on each side and what recurs
This table lists each cost component of running Gliffy and of running draw.io, who is paid for each one, and whether it is one-time or recurring. Use it to build a like-for-like comparison, then ask vendors and your own teams for the figures that the researched facts do not include.
| Cost component | Gliffy side | draw.io side | One-time or recurring |
|---|---|---|---|
| Software licence or subscription | Paid to Perforce per user through the Atlassian Marketplace for Gliffy for Confluence. Confirm current tiers and whether Zero Egress is included in your Atlassian edition. | Free self-hosted draw.io under Apache License 2.0 with no licence fee. The Confluence app is a paid listing on the Atlassian Marketplace, so confirm its per-user or tier terms there. | Recurring for Gliffy and for the draw.io Confluence app if chosen. Free self-hosted draw.io has no recurring licence cost. |
| Infrastructure | Runs inside Atlassian Cloud or your Data Center, so no separate servers are needed for the diagramming function itself. | Your own servers or cloud account running the official jgraph/drawio Docker image, or desktop installs. Costs depend on hosting choices and the number of instances you run. | Recurring. Driven by hosting model, backup and monitoring of the container. |
| Implementation | Mostly administrative: app installation and permissions within Confluence, handled by your Atlassian admins. | Deploying the container, connecting it to Confluence or another wiki, configuring storage, and setting up updates. Paid to your staff or to a implementation partner under a written scope. | One-time, with ongoing work for upgrades. Scope depends on how many wikis and storage targets you connect. |
| Conversion of existing diagrams | No conversion needed while you stay on Gliffy. Cost arises only if you later move away. | Mass conversion through the draw.io Confluence app or individual imports of Gliffy files. Paid as internal time or as a fixed-scope service. Converted diagrams need checking by the owners. | One-time. Driven by diagram count, complexity and how many owners must review results. |
| Integration with Confluence or another wiki | Built into Confluence through the Gliffy app, so integration is covered by the licence. | Requires connecting draw.io to Confluence, XWiki, MediaWiki or another wiki. Confirm supported integrations in the draw.io integrations documentation for your wiki version. | Setup is one-time. Maintenance recurs whenever the wiki or draw.io changes. |
| Support | Included in the vendor's support terms for the paid subscription. Confirm response times and severity terms in your contract. | Community support for the open-source project, with no vendor support contract unless you buy one. Paid support or a retainer comes from a provider such as DeployOpen, scoped in writing. | Recurring if you buy a retainer. Free community support has no fee but no contractual response time. |
| Upgrades and patching | Delivered as vendor app updates, applied by your Atlassian admins under your change process. | You test and apply new draw.io image versions, such as the Docker image updates the project publishes, and rebuild your deployment. Internal or contracted staff carry this work. | Recurring. Frequency and effort depend on your release cadence and testing rules. |
| Internal skills | Low. Users and admins work within familiar Atlassian tooling. | Container operations, reverse proxy and TLS, storage and backup skills are needed. Confirm skills exist in-house or budget for training or contracted help. | Largely one-time for learning, recurring for keeping skills current. |
| Training | Vendor documentation and standard Confluence user onboarding. | Short user guidance on saving diagrams to approved storage and import checks. Confirm how your teams will learn the editor and the storage rules. | One-time for initial rollout, with recurring onboarding for new staff. |
What moves the Gliffy versus draw.io comparison
The cost gap between Gliffy and draw.io depends less on the tool than on how your organization is set up. Editor counts, diagram volume, Confluence plans, deployment model, residency rules and in-house skills each push the total in a different direction, so test them against your own numbers before you compare quotes.
Confluence editors and viewers
Gliffy for Confluence is priced per user, so the number of people who edit diagrams and the number who only view them both feed the bill. Ask Atlassian and Perforce how viewers are counted on your site. The draw.io Confluence app is also sold through the Atlassian Marketplace, so compare its per-user terms on the same basis, including viewers, rather than only editors. Small editor groups with many readers often favor a different model than a few heavy editors.
Volume and complexity of existing diagrams
A large Gliffy estate raises migration effort more than license cost. Count diagrams, note which ones use custom shapes, embedded images or macros, and sample them for layout drift after conversion. Simple flowcharts usually move quickly. Diagrams with dense linking or many pages of embedded content need manual checks, and that review time is the main one-time cost on the draw.io side.
Whether Confluence is staying
If Confluence remains your wiki, draw.io can run as an app inside it, and the license and support decisions stay with Atlassian. If you plan to move pages to another wiki, the Gliffy export and the draw.io diagram files become the portable assets, and a standalone draw.io setup avoids paying for an app tied to a platform you are leaving. Confirm the exit timeline before you buy anything that only works inside Confluence.
Data Center or Cloud deployment
Your Atlassian deployment type changes which apps and which Gliffy edition apply, and it affects whether a self-hosted draw.io Docker service needs to sit beside a Data Center instance. Confirm with Atlassian which Gliffy and draw.io app builds support your deployment, since app availability and versions can differ between Cloud and Data Center. Mismatches here cause rework that no license comparison will show.
Required data residency
Gliffy Zero Egress keeps diagram data within Atlassian Cloud, which may or may not meet your residency or audit rules. Self-hosted draw.io stores diagrams where you choose, on a device or storage service you control, and the draw.io trust page says diagrams never sit on draw.io's servers. Hosted export and real-time collaboration do pass through Cloudflare servers temporarily, so check whether those features are in scope before you rely on them.
In-house skills for a Docker service
Self-hosting draw.io means running the official jgraph/drawio Docker image, keeping it patched, and maintaining TLS, backups and access control. If your platform team already operates containers, this cost stays small. If not, budget for training or a support retainer, and ask any implementation partner for the written scope of upgrades and updates before work starts.
How conversion work changes the one-time cost
Moving from Gliffy to draw.io replaces a recurring license with a one-time piece of work. draw.io imports Gliffy diagrams, so the cost to plan for is the effort of converting and checking existing diagrams, plus the time to get people comfortable with the editor. That work is paid once, either by your own team or by an implementation partner under a written scope. Once it is finished, the draw.io side carries no per-user fee in the way Gliffy for Confluence does, although the Confluence or Jira app you choose may still carry its own licensing terms, which you should confirm with the Atlassian Marketplace listing before you budget.
Four things drive the size of this effort: the number of diagrams in scope, how many of them depend on custom shapes or shape libraries, how many are linked from pages and macros that must keep working, and how much checking the converted output needs. A count of diagrams is the first number to pull from your Confluence or wiki export. Diagrams built from standard shapes usually move with little change, while heavily customized ones need a closer look. Ask whether a conversion is planned in bulk or diagram by diagram, because the two approaches have very different review loads.
Test a representative sample before you estimate anything. The draw.io documentation warns that imported diagrams may not look the same as the originals and that some interactive behavior can be lost, which is documented for Visio imports and is a good prompt to test Gliffy output the same way. Pick a sample that includes your most complex diagrams, convert them, and compare them side by side with the originals in Confluence. Record what breaks, how long each fix takes, and whether the fixes repeat. That sample gives you a defensible basis for a quote, and it is the number to request from any partner in place of an assumed duration.
How to build the comparison with your own numbers
This sequence turns vague pricing impressions into a three-year cost view built from your own user counts, invoices, quotes and internal rates, so both options are compared on the same basis. Each step produces a document you can show finance and security.
Inventory users and diagrams
Start by counting the people who create, edit and only view Gliffy diagrams, split by Confluence space or Jira project. Then count diagrams and attachments, note which ones are referenced by live pages, and flag any that are tied to audit evidence or architecture records. The output is a single sheet with user counts by role, diagram counts by space, and a list of high-value diagrams that need extra checking during conversion. You know this step is done when the platform owner and a space administrator have both signed off on the numbers.
Pull current Gliffy and Atlassian invoices
Collect the latest invoices and order forms for Gliffy for Confluence and any related Atlassian subscriptions, including the user tier, the billing period, the renewal date and any add-ons such as Zero Egress. Ask procurement to confirm whether the price is per user, per tier or a combination, and whether discounts expire at renewal. The output is a one-page summary of what you pay today, what recurs and what changes at the next renewal. Confirm the figures against the contract, not against memory or a pricing page.
Get a written scope and quote for conversion and hosting
Ask a implementation partner and, if you use one, the draw.io app vendor for written pricing for two items: converting existing Gliffy diagrams and, if you self-host, standing up draw.io on your own servers or desktops. Ask each party to state assumptions, such as the number of diagrams, the wiki platform, the authentication model and whether export server work is included. Ask whether quotes are fixed scope and what is excluded. The output is a comparable written scope from each source. Do not rely on public figures for either option, because the value depends on your environment and the work you actually need.
Price internal hours at your own rates
Estimate the internal effort your team will spend on pilot testing, user communication, checking converted diagrams, updating links in wiki pages and handling support questions. Multiply the hours by the loaded hourly rates your finance team uses for engineers, administrators and content owners. Keep the hours separate for the one-time migration and for the recurring work that continues after go-live. The output is two tables, one for one-time labor and one for recurring labor, each with a stated basis. Record which assumptions are estimates so reviewers can challenge them.
Add a recurring line for upgrades and support
On the self-hosted side, list the recurring tasks that someone must own: applying draw.io releases, testing them against your wiki version, patching the host operating system and container runtime, monitoring availability, and handling access changes. Decide whether these come from internal staff, a support retainer or both, and ask for written terms for any retainer. On the Gliffy side, keep the Atlassian renewal and any add-on fees as recurring lines. The output is a recurring cost table for both options with the same time period. Check that the self-hosted line includes backup and recovery testing, not only the hosting bill.
Build a three-year view on both sides
Place the one-time costs in year one and the recurring costs in each of the three years, then add up each option. Include the Gliffy renewal increases you have been told to expect only if they are in writing. Show a sensitivity line for the two drivers you are least sure about, usually user count and internal hours, so the result is shown as a range rather than a single figure. The output is one comparison sheet that a finance reviewer and a security lead can both read. You know this step is done when the people who own the numbers have each reviewed their own lines.
Check the comparison against non-cost requirements
Before a decision, review the cost sheet against the requirements that cost alone does not capture: where diagram data is stored, which auditors will ask questions, how converted diagrams will be validated, and what happens to diagrams that do not convert cleanly. Confirm the answers with your security team and, where relevant, with your compliance lead. The output is a short sign-off note that lists the cost result, the open assumptions and the requirements each option meets. Keep this note with the quotes so the decision can be reviewed later.
Confluence app, self-hosted Docker or desktop: which cost profile fits
The draw.io apps for Confluence and Jira are sold through the Atlassian Marketplace, so the purchase runs through your Atlassian account rather than a separate contract with the draw.io project. Your Atlassian administrator buys and assigns the app, and the cost follows the Marketplace listing and the Atlassian deployment you already run. Confluence Cloud and Data Center are both possible paths, and the app's fee structure and tier names should be read from the listing on the day you buy, because they change.
- Who pays: Your organization pays the Marketplace fee for the app, and Atlassian stays the billing and support channel for the app itself.
- What recurs: The app subscription renews on the Marketplace term, and Confluence hosting or Data Center infrastructure costs continue under your existing Atlassian arrangement.
- Skills needed: Atlassian administration is enough for installation and user assignment, so no separate server operations team is required.
- Data path: Diagrams are stored as Confluence attachments or page content, so diagram data stays inside your Atlassian tenant.
- Cost driver: Your Confluence edition and the Marketplace tier you select set most of the recurring spend.
Confirm with your Atlassian partner or the Marketplace listing whether the app supports your Confluence deployment type, and ask for the current renewal terms in writing.
The official jgraph/drawio Docker image runs draw.io on your own infrastructure, and it is kept up to date with the production app at app.diagrams.net. It pairs well with a self-hosted wiki such as XWiki or BookStack, both of which draw.io integrates with. The software itself carries no license fee because the source is Apache 2.0, so the cost sits in hosting, operations and the wiki integration work.
- Who pays: Your organization pays for the server, the network path, certificates and the staff who patch and monitor the container.
- What recurs: Hosting, backups, image updates and the time to test each release recur, along with any wiki maintenance.
- Skills needed: Container operations, TLS configuration and wiki administration. Integration work with XWiki or BookStack is a one-time task that may need a developer.
- Export limitation: The Docker image does not include an export server, so PDF export uses the browser's print dialog unless you configure one. No diagram data leaves the server for an export.
- Cost driver: The number of users and the internal support you can staff set the total more than the software does.
Ask your platform team to confirm the export approach your users need before rollout, since print-dialog PDF export changes the workflow for teams that expect a one-click file.
draw.io Desktop suits individual users who draw on their own machines and do not need a shared team space. Diagrams are saved to the device or to a storage service the user chooses, which keeps diagram data under the user's control. Because there is no central server, there is no server cost, but there is also no central place to share, version or review diagrams.
- Who pays: The organization pays only for distribution and any endpoint management it already uses, since the desktop app is open source.
- What recurs: Application updates recur, and each user or IT team must install new versions. Storage costs depend on the cloud or file share you choose.
- Skills needed: Basic endpoint deployment through your existing software management tool is usually enough.
- Sharing gap: Teams must export files or use a connected storage service for sharing, so review and version control need a separate process.
- Cost driver: The number of users and how many diagrams must be shared across teams shape whether desktop alone remains practical.
Confirm with your security team whether desktop installs are permitted on managed endpoints and where your policy expects diagram files to be stored.
Questions buyers ask before comparing Gliffy and draw.io costs
Is draw.io really free to run in our organization?
The draw.io source code is licensed under the Apache License 2.0, so the software itself carries no license fee for self-hosting. The costs sit elsewhere: the server or desktop rollout, the time your team spends on updates and backups, and any paid Confluence or Jira app from the Atlassian Marketplace if you choose that route. Ask your team to list each component separately, since a free license still leaves the operating effort to be paid for. Note that the draw.io Confluence and Jira apps are sold through the Atlassian Marketplace, so pricing for those follows Atlassian's terms rather than the license of the source code.
How long does converting Gliffy diagrams to draw.io take, and who does the work?
The effort depends mainly on the number of diagrams, how many are business-critical, and how much checking each one needs. draw.io's Confluence app offers a mass conversion route, while individual Gliffy files can be imported directly. draw.io's import documentation confirms that Gliffy diagrams are supported, so the main variable is review, not conversion itself. Internal staff can do the conversion, or you can scope it as a fixed engagement with a provider. Ask for a written inventory of diagrams, a sample test set and a named owner for sign-off before agreeing on effort.
Can an in-house team run a self-hosted draw.io image?
A small platform team can usually run the official jgraph/drawio Docker image, which is based on Tomcat and kept up to date with the production app, provided it has container and reverse proxy skills. The skills needed include updating the image, configuring TLS and storage integrations, and deciding how PDF export will work, since the image does not include an export server. Without a configured export server, PDF export relies on the browser's print dialog. Ask your team to document the upgrade routine and to confirm who is on call for the service before deciding whether to keep it in-house.
What support is available if draw.io does not accept pull requests?
The project's core team develops draw.io and does not accept pull requests, so you cannot count on contributing fixes upstream. Support therefore has to come from your own team, from a commercial agreement with a provider, or from the community around the project. Confirm what each path covers, including response expectations, before you rely on it. Keeping a tested upgrade path for each release matters more when the upstream fix cycle is outside your control.
Do Gliffy Zero Egress and self-hosted draw.io cost differently for regulated teams?
They differ in what you pay for and in where diagram data goes. Gliffy Zero Egress is an Atlassian Cloud arrangement with its own licensing, while self-hosted draw.io shifts cost toward your infrastructure, staff and documentation for auditors. draw.io's privacy policy says diagrams are saved where the user chooses and never on draw.io's servers, though hosted export and real-time collaboration process diagrams temporarily on servers run by Cloudflare, so you should check those features against your requirements. Ask your compliance lead to define which evidence the auditors need before comparing totals. The companion page on regulated teams covers the data flow in more detail.
What should we ask for in a quote for this migration?
Ask for a written scope that names the diagrams in scope, the hosting model, the number of users and the integrations to be configured, such as your wiki or storage service. The quote should separate one-time work (conversion, review, rollout, documentation) from recurring work (upgrades, backups, support and monitoring). Ask which items depend on your environment, such as existing Atlassian licenses, server capacity or export requirements, and how the provider handles changes to scope. DeployOpen plans and implements self-hosted platforms in your own infrastructure and delivers under a fixed-scope agreement, so the written scope is the basis for any quote.
What to ask for in a written scope and quote
A fixed-scope draw.io engagement for a Gliffy estate should itemize its work so that each line can be checked against the delivered result. Start with discovery of the diagram estate: the number of Gliffy diagrams, the Confluence spaces and pages that embed them, any Jira issues that reference them, and the diagrams that are linked from other systems. Ask the implementer to state how discovery is done, which diagrams are in and out of scope, and what happens to diagrams that are found after the scope is signed. Next, the scope should cover conversion and checking, separating the bulk conversion from the review of individual diagrams, because Visio and Lucidchart imports can differ from the originals and the review effort is where scope often grows. The quote should also name the hosting and backup setup for the chosen draw.io deployment, including who configures the storage location and how backups of diagram data are tested. The remaining items are integration with the wiki (confirm which app or self-hosted integration is in use and who maintains it), handover documentation (runbooks for upgrades, storage, and user guidance), and an optional support retainer. DeployOpen does not publish prices. A quote follows from the written scope, so the cost drivers are the diagram count, the share of complex diagrams that need manual rebuilding, the number of environments, and whether a move off Confluence is also in scope. Ask the vendor to separate one-time work from recurring work and to name who pays for licenses, infrastructure and any Atlassian Marketplace purchases.
Ongoing support, upgrades and continuous testing are available as retainers, and they are a separate decision from the migration itself. A retainer covers work after handover, such as applying draw.io releases on your schedule, reviewing the hosted image after updates, and handling user questions. Ask whether the retainer has a stated response model and what it excludes. Confirm with the vendor and your own change board how upgrades are tested before they reach production. Because draw.io's project does not accept pull requests, upgrade planning depends on the release cycle and on your own test environment, so ask how that is handled in the retainer. Before signing, ask for the acceptance criteria in writing: which diagrams must open correctly, which exports must be produced, and who signs off. Ask for the handover package to be delivered in a form your team can keep, and confirm who owns the configuration files and documentation at the end of the engagement. Finally, compare the written scope with your own estate inventory. If the scope does not match what you found in discovery, the quote will not reflect your real cost, so resolve that gap before accepting any figure.
How DeployOpen scopes a fixed-price draw.io implementation
DeployOpen is a Chainscore Labs company that plans, implements, integrates, hardens, backs up and documents self-hosted open-source platforms inside your own infrastructure. For Gliffy cost vs draw.io, we start with a written scope that sets out which diagram sources, wiki or Confluence instances and hosting options are in play, so your cost comparison rests on your environment rather than on assumptions.
How we scope
- Inventory how many Gliffy diagrams exist, where they live and who edits them.
- Confirm whether draw.io runs inside Confluence, on a self-hosted wiki or as Desktop.
- Agree in writing the deliverables, timelines and exclusions before any work starts.
- Ask for quotes that itemize conversion, hosting, testing, documentation and handover.
How we build
- Deploy the official jgraph/drawio Docker image or the chosen app inside your environment.
- Configure storage integrations and export behavior to match your data residency rules.
- Convert a sample of Gliffy diagrams first and review fidelity with your diagram owners.
- Test access controls, backups and update steps against the scope before handover.
How we hand over
- Document the architecture, configuration, backup routine and upgrade procedure in writing.
- Provide a conversion log listing diagrams converted, flagged for manual review and retired.
- Walk administrators through patching, version updates and rollback steps.
- Deliver evidence of configuration and testing to support your internal compliance reviews.
How we support
- Engagements are fixed-scope, and ongoing support is available as a separate retainer.
- Retainers can cover upgrades, monitoring, periodic testing and changes to the integrations.
- Confirm response expectations and support hours in the written scope before signing.
- Scope any later Confluence or wiki migration as its own fixed-scope piece of work.

