Confluence cost vs self-hosted XWiki: where the money goes
A renewal, a Data Center end-of-life deadline or a Cloud export change usually starts the cost review, so the first question is what each option actually bills. XWiki Standard carries no license fee, because the core is licensed under LGPL-2.1. Self-hosting XWiki therefore costs hosting, the one-time migration, ongoing administration, and any optional support or training you buy from XWiki SAS. Confluence costs a subscription or license, plus your own hosting where you run Data Center. This section uses only the prices and dates we can source, and it states no DeployOpen or Atlassian price. Atlassian's published timeline matters here: new Data Center subscriptions for new customers end on March 30, 2026, and Data Center licenses become read-only on March 28, 2029.
Among the costs that are not licenses, the migration is the largest one-time item you can price in advance. XWiki SAS prices its paid Confluence Migrator Pro from 2000 EUR, and its trial is limited to 30 pages per migration, so a full import needs the paid extension or your own engineering against the open-source Confluence XML filter that the extension builds on. Confirm with XWiki SAS which backup formats and Confluence editions the current version reads, and whether your attachment history must survive, because the extension keeps page history but not attachment history. Hosted XWiki Cloud and on-premises support are quoted differently, and XWiki SAS states its cloud and on-premises pricing is the same. Ask for the tier that matches your user count before you compare totals.
Recurring costs decide the comparison over time. Consulting is listed at 1200 EUR per day and requires a Business or Enterprise support plan, while training is listed at 1500 EUR per day, so an in-house team that can run XWiki on its own may need only a fraction of those days. Your administration hours, server or cloud spend, backups and upgrades remain yours in every scenario. Ask any implementation partner for a written scope with named deliverables, and ask XWiki SAS to confirm which support tier, user band and day rates apply to your organization. Do the same for Atlassian, asking for a Confluence quote that states the Data Center or Cloud term and any hosting you must buy separately.
Which cost components change when you move from Confluence to XWiki
This table compares each cost component on the Confluence side with its counterpart on a self-hosted XWiki deployment, and marks whether each cost is one-time or recurring. Read it as a checklist for a quote: the largest differences usually sit in admin time and migration work, not in the software license. Confluence Data Center licenses become read-only on March 28, 2029, which changes the timing of the decision more than its price.
| Cost component | Confluence (Atlassian and partners) | Self-hosted XWiki (you and your providers) |
|---|---|---|
| Subscription or license | Recurring fee to Atlassian for Cloud or Data Center, paid per user or tier; Data Center purchases for new customers end March 30, 2026 | XWiki is LGPL 2.1 with no license fee; recurring only if you buy XWiki SAS support or Pro subscriptions |
| Infrastructure | Included in Atlassian Cloud; for Data Center, your own servers, database and storage paid to your cloud or hardware vendors | Recurring compute, database, storage and backups in your cloud account or data center; sized by user count and attachment volume |
| Migration tooling | Export is largely free through Confluence admin tools, but XML export reaches end of life December 1, 2026 per Atlassian | One-time: open-source XML filter (free) or XWiki's paid Confluence Migrator Pro, priced from 2000 EUR per XWiki Store |
| Implementation and configuration | Mostly internal or partner time for Marketplace app setup and space structure, one-time at rollout | One-time: integrator fees for installation, macro mapping, SSO and permission design, quoted from written scope |
| Support | Recurring vendor support included in the Atlassian subscription | Optional recurring XWiki SAS support tiers; consulting is 1200 EUR per day and training 1500 EUR per day per XWiki's pricing page, which lists the same prices for cloud and on-premises |
| Upgrades and testing | Atlassian applies Cloud upgrades; Data Center upgrades are run by your team | Recurring internal or retainer time to test and apply XWiki stable, LTS and intermediate LTS releases, plus extension updates |
| Backups and recovery | Cloud site backups from the admin backup manager; Data Center backups handled by your operators | Recurring: you run database, attachment and disaster recovery backups and restore tests, with storage costs |
| Internal admin time | Recurring admin effort for spaces, permissions and Marketplace apps, lower for Cloud | Recurring admin effort for hosting, patching, user management and macro maintenance; usually the largest ongoing item to estimate |
What you pay for on the Confluence side and on the XWiki side
On the Confluence side, the main recurring cost is the subscription or license term, and who carries the rest depends on the deployment model. In Confluence Cloud, Atlassian hosts the service and you pay a subscription, so infrastructure, patching and uptime are in the vendor's scope while your team still administers spaces, users and permissions. In Data Center, you pay for licenses and for the servers, storage, database, load balancing and staff that run it in your own environment. Atlassian's own timeline matters for that second model: new Data Center subscriptions for new customers end on March 30, 2026, and Data Center licenses expire and become read-only on March 28, 2029. Exporting content also has a cost in staff time. Space admins can export spaces in several formats, and site admins can take a full site backup, but Confluence Cloud XML export reaches end of life on December 1, 2026, so a migration plan should not depend on it. Ask your Atlassian account team which of these dates applies to your contract.
On the XWiki side, the core software is free under the LGPL 2.1 license, so the cost is in what surrounds it. Your organization pays for infrastructure (servers or cloud accounts, database, backups, monitoring), for implementation and configuration, and for the Confluence migration itself. The Confluence migration can be done through XWiki SAS's paid Confluence Migrator Pro, which XWiki SAS prices from 2000 EUR and which offers a trial limited to 30 pages per migration, or through the open-source Confluence XML filter that the migrator builds on. Support, training and some business extensions are sold by XWiki SAS, with the support tiers and day rates published on its pricing page, and a partner or internal team can also provide these services. Upgrades remain your responsibility unless you contract for them. When requesting quotes, ask each vendor to separate one-time migration work from recurring hosting, support and upgrade effort, and confirm which user tier applies to your headcount.
What moves the Confluence vs XWiki cost comparison
The cost gap between Confluence and self-hosted XWiki is shaped less by the license line and more by a few variables that you can measure before you ask for a quote. The cards below cover the drivers that move the total up or down, and what to confirm for each in your own environment.
User count sets support tier
XWiki Pro and support subscriptions are sized by user tiers: Starter for up to 25 users (XWiki Cloud only), Basic for up to 1,000, Business for up to 10,000 and Enterprise for unlimited users. XWiki SAS states that cloud and on-premises pricing is the same, so the tier, not the hosting model, is the number to compare. Count active users, not licensed seats, and ask the vendor how it counts guests and service accounts.
Attachment history and data volume
Storage and migration effort grow with the size of the Confluence site, its attachment count and how much version history you keep. Confluence Migrator Pro keeps page history but not attachment history, so teams that rely on old attachment versions should decide whether to archive them separately. Ask for an export size estimate from your own site before scoping the migration, and confirm how the chosen hosting handles backup of the attachment store.
Confluence apps and macros to rebuild
Each Marketplace app or heavily used macro in your Confluence site is a potential rebuild item in XWiki, where equivalents may be native, available as an extension or absent. XWiki Pro lists connectors such as Google Apps, Office365 and OnlyOffice, but none of that replaces a custom internal app. Inventory the apps your spaces depend on, then ask each vendor for a written equivalence list before the scope is fixed.
Edition and extension choices
The free LGPL-2.1 XWiki core carries no license fee, but the Confluence Migrator Pro extension is a paid product from XWiki SAS, priced from 2000 EUR with a trial limited to 30 pages per migration. Support, consulting and training are separate lines. Decide early which of these you need, because a migration can run on the open-source Confluence XML filter that the Migrator Pro builds on, at a different effort level.
Availability and compliance requirements
Uptime targets, backup frequency, audit logging and evidence for assessors all add cost on the self-hosted side, because you own them. Clustered databases, tested restores and monitoring cost more than a single Tomcat instance, and each requirement changes the hours needed for operations. Write down the availability and retention obligations first, then ask both the platform operator and any hosting provider which of them are included in their quote.
In-house XWiki skills
The main recurring cost is often staff time. Teams that already run Tomcat, PostgreSQL or MySQL, and can manage XWiki's Java-based platform, customize macros and apply upgrades, carry less external spend than teams that must buy training or consulting. XWiki SAS lists training at 1500 EUR per day and consulting at 1200 EUR per day, which requires a Business or Enterprise support plan. Estimate your internal skill gaps before choosing between internal ownership and a fixed-scope partner engagement.
How to build the cost model with your own numbers
This sequence turns a vague comparison into a side-by-side model of your current Confluence spend and a self-hosted XWiki run, built from your own user counts, rates and written quotes. Each step produces a figure you can defend in a renewal or budget discussion.
Inventory users, spaces, attachments and apps
Export the counts that drive both sides of the model: active and licensed users, groups, spaces (including personal spaces), total attachment storage, page count and the Marketplace apps that your teams use for macros, diagrams or approvals. Assign an owner to the inventory, usually a Confluence site admin working with someone from the business owners of the content. The step is done when every line has a number, a source and a date, and when apps are marked as needed, replaceable or unused. Unused apps often drop out of scope entirely, which changes the migration cost.
Collect current subscription terms and renewal date
Ask Atlassian or your account team for the current Confluence subscription or Data Center license terms, the tier, the user band, the support level, the renewal date and any notice period. Confirm in writing how the price changes if user counts rise or fall during the term. Record the Atlassian end-of-life dates that apply to your deployment, including the Data Center timeline in the Atlassian Ascend announcement and the Cloud XML export end of life, because they set when you must decide. The step is done when you hold a document that lists every recurring charge and its renewal date.
Choose hosting and estimate infrastructure
Decide where XWiki will run: your existing cloud account, your own data center, an air-gapped network or a managed hosting provider. Ask your infrastructure team to price the compute, database, storage, backup, load balancer and monitoring for a production and a non-production environment, using your own cloud or data center rates. Include the XWiki Docker images as a starting point, noting that the official images come in MySQL, PostgreSQL and MariaDB variants on Tomcat. The step is done when each infrastructure line has a rate, a quantity and an owner, and when the hosting option is named for both the base case and a growth case.
Scope the migration with and without Migrator Pro
Build two migration estimates. The first assumes you use the open-source Confluence XML filter stream and your own engineers, with effort for mapping macros, permissions, attachments and any custom content. The second assumes XWiki's paid Confluence Migrator Pro, which the XWiki Store lists from 2000 EUR and which keeps page history but not attachment history. Ask XWiki for a written quote for the Migrator Pro scope against your inventory, and ask whether the trial limit of 30 pages per migration fits your test plan. The step is done when both estimates list what is kept, what is lost and what must be rebuilt by hand.
Add support tier and training options
Select the XWiki SAS support tier that matches your user count, and compare it with running support internally. XWiki Pro and support subscriptions come in Starter, Basic, Business and Enterprise tiers, and the XWiki pricing page states that cloud and on-premises pricing is the same. Consulting is listed at 1200 EUR per day and requires a Business or Enterprise support plan, and training is listed at 1500 EUR per day. Also price any third-party implementation partner, including DeployOpen, from a written scope. The step is done when every support, consulting and training line is marked as optional or required, with a quote behind it.
Assign monthly admin and content owner hours
Estimate the hours each month that your team will spend on patching, upgrades, backups, restore tests, access reviews, extension updates, and answering user questions, and separately the hours content owners spend on page cleanup after migration. Use the XWiki release cadence and your change process to set the patching frequency. Name the role that carries each hour, such as platform engineer, security engineer or documentation lead, and use your own loaded rate. The step is done when the hours are listed by role and month, and when the same hours are applied to the Confluence side for admin tasks you will still perform, such as user management.
Compare one-time and recurring totals over one period
Put both options on the same timeline, starting with the migration, setup and training as one-time costs and then listing subscriptions, hosting, support, admin hours and backups as recurring costs per year. Use the same period for Confluence and XWiki, such as three or five years, and include the Confluence renewal price changes you were quoted. Run a sensitivity check on user growth and on the cost of a delayed migration. The step is done when you have a single table showing one-time, recurring and total cost for each option, and a list of assumptions that a finance or procurement reviewer can challenge.
How the migration path changes the one-time cost
This path uses XWiki Standard under the LGPL-2.1 license and the open-source Confluence XML filter stream, which is the component the paid migrator builds on. The software itself carries no license fee. The one-time cost is the internal engineering time to install XWiki, run the import, map Confluence spaces and macros to XWiki equivalents, and check the results by hand. Your staff or contractors are paid for that time, and the work is not fixed in scope unless you define it.
- Licence cost: None for XWiki Standard. Confirm that your chosen XWiki version and any extensions you add carry the licenses you expect.
- Engineering time: Mapping spaces, permissions, users and groups, and checking macros that do not convert cleanly. This is usually the largest line item.
- Attachment and history gaps: Confirm how the open-source filter handles attachment history and page history for your export, since the paid migrator documents that it keeps page history but not attachment history.
- Export format: Plan around the Confluence XML export end of life on December 1, 2026, and test whether your backup format is still supported when you run the import.
- Validation: Budget time for sampling pages, links and permissions across every space, which the internal team must do without vendor support.
Ask your internal team to estimate the hours for each step and to name who owns the validation sign-off.
This path adds the paid Confluence Migrator Pro extension from XWiki SAS to the same XWiki Standard installation. The extension imports XML and CSV backups from Confluence Server, Data Center and Cloud, including pages, spaces, attachments, permissions, blog posts, and users and groups. The migrator is priced from 2000 EUR according to XWiki's store listing, and its trial is limited to 30 pages per migration, so you should test the full workflow against a representative sample before buying a license.
- Licence cost: The migrator is priced from 2000 EUR per the XWiki Store listing. Confirm the current price and the license terms for your user count and environment before budgeting.
- Kept: Page history, spaces, attachments, permissions and users and groups, according to the XWiki Store description.
- Lost: Attachment history. Plan how you will archive old attachment versions if your compliance rules require them.
- Trial limit: The trial is capped at 30 pages per migration, so a full-site import needs a purchased license and an internal test plan.
- Remaining effort: The license reduces import work but does not remove the need to review macros, layouts and internal links after the migration.
Ask XWiki SAS for the current price, the license scope, and written confirmation of which content types the migrator keeps for your export format.
This path hands the whole migration to an implementation partner under a written, fixed scope. The cost covers planning, environment build, import, mapping, hardening, validation and handover, and it is paid as one agreed deliverable set rather than hours spent by your team. XWiki SAS also offers its own Confluence to XWiki migration services, and consulting is listed at 1200 EUR per day for Business or Enterprise support customers, so compare any quote against that reference.
- What you pay for: Scoped deliverables such as environment setup, migration runs, a validation report and documentation for operators.
- What recurs: Hosting, licenses for any paid extension, and support or retainers if you want them after handover.
- Kept and lost: Set in the written scope, which should state exactly which content types, attachment history and macros are covered.
- Effort drivers: Number of spaces and pages, custom Marketplace apps, permission complexity, and the number of validation rounds you require.
- Acceptance: Agree in writing how sample pages will be checked and who signs off.
Ask each provider to list what is excluded from the scope, including attachment history, Marketplace apps and post-migration fixes.
Frequently asked questions about Confluence and XWiki costs
Does XWiki have a license fee?
No. XWiki is licensed under the LGPL 2.1, so the core platform can be downloaded, installed and run in your own infrastructure without a license fee. The official Docker images are also LGPL 2.1. Your recurring costs are the servers or cloud resources that host it, the database, backups, and the staff time to administer it. Paid items come from XWiki SAS only if you choose them: support subscriptions, the Confluence Migrator Pro extension, XWiki Pro business applications, consulting and training. Ask your team to confirm the license terms of any extension before installing it, since extensions carry their own licenses.
What does Confluence Migrator Pro cost, and what does it leave out?
XWiki SAS sells Confluence Migrator Pro as a paid extension, priced from 2000 EUR according to the XWiki Store listing, with a trial limited to 30 pages per migration. It imports spaces, pages, users, groups, permissions, attachments and metadata, and keeps page history. It does not keep attachment history. Confirm with XWiki SAS whether the quoted price covers your deployment size and the Confluence edition you export from, and check how it handles macros and Marketplace apps, which often need manual rework. The open-source Confluence XML filter it builds on is available if you prefer to handle the migration yourself.
How long does a Confluence to XWiki migration take?
No migration duration was supplied for this page, so treat any number you hear with caution. The effort depends on the number of spaces and pages, the size of attachments, how many macros and Marketplace apps your content uses, how much permission mapping you need, and how much cleanup your editors accept. Ask any provider, including DeployOpen, for a written scope that lists the spaces in and out, a test migration on a sample set, the acceptance criteria, and the deliverables. DeployOpen works on fixed-scope engagements agreed in writing before work starts, and quotes follow from that scope.
Can our own team run XWiki without outside help?
Often yes, if you have people who can administer a Java web application on Tomcat with a relational database. The official Docker images come in MySQL, PostgreSQL and MariaDB variants and run on amd64 and arm64v8. Your team will need to own upgrades, backups, TLS, authentication setup and monitoring, and to choose between the stable line, the long term support line and the intermediate LTS line. Estimate the ongoing admin time honestly, because it is the cost most often underestimated. Outside help can cover installation, hardening, documentation and runbooks, or be retained for ongoing support.
What do XWiki support subscriptions add?
Support subscriptions add vendor-backed help from XWiki SAS, and they are priced by user tier: Starter for up to 25 users (XWiki Cloud only), Basic for up to 1,000 users, Business for up to 10,000 users and Enterprise for unlimited users, according to XWiki's pricing page, which states that cloud and on-premises pricing is the same. XWiki SAS lists consulting at 1200 EUR per day for Business or Enterprise support plans and training at 1500 EUR per day. Subscriptions do not change the license of the core software. Compare them against what your own team and an independent implementation partner could cover, and ask XWiki SAS what response levels each tier includes in writing.
How does the XML export end of life on December 1, 2026 affect our plan?
Atlassian ends support for Confluence Cloud XML site and space export on December 1, 2026. After that date the features still work, but Atlassian will no longer fix bugs or accept support tickets for them, and it recommends CSV export instead. If your migration depends on XML, schedule the full export and test restore before that date and keep the archive as a fixed snapshot. XWiki's Confluence migrator reads both XML and CSV backups, so confirm with XWiki which formats your edition and extension version support before you choose the path. Finishing the export early also reduces pressure on the content freeze.
What should we ask for in a quote for this migration?
Ask for a written scope that separates one-time and recurring costs. One-time items usually include the assessment, the installation and configuration, the Migrator Pro license if used, the migration runs and cleanup, testing, documentation and training. Recurring items usually include hosting, backups, support subscriptions, upgrades and retained operations. Ask which spaces, apps and macros are included, how attachment history and permissions are handled, what acceptance tests apply, and how changes to scope are priced. DeployOpen does not publish a price list, so expect a quote that follows from the written scope.
What to ask for in a written quote before you compare
A quote is only comparable if every bidder prices the same work, so ask for the same line items from every vendor, including DeployOpen. Start with scope: the number of pages, spaces, page trees, attachments and users in the source Confluence site, whether attachment history must come across, and which apps or macros from the Marketplace are in or out. Then ask for the migration method. The XWiki Confluence Migrator Pro reads XML and CSV backups and keeps page history but not attachment history, while a route built on the open-source Confluence XML filter is a different piece of work. Name the export format in the quote, because XML site and space export reaches end of life on December 1, 2026, and the format determines what is in scope.
Next, pin down the hosting environment: your cloud account, your data center, or an air-gapped network, plus the database variant and the XWiki release line (stable, intermediate LTS or LTS) the quote assumes. Ask for the support tier and the user count it covers, and whether those figures match XWiki SAS's published tiers if you compare against them. Add training in days, the named roles trained (space admins, page editors, platform operators), and whether training is delivered on site or remotely. Finally, require acceptance criteria written as checks you can run, such as a sample of migrated pages compared against the source, permission tests per space and a restore test of the backup, and a handover package listing runbooks, configuration, credentials ownership and upgrade steps. A fixed-scope written agreement from DeployOpen lists each of these items, and you should ask any other vendor to do the same.
How DeployOpen scopes a fixed-price XWiki implementation
DeployOpen plans, implements, integrates, hardens, backs up and documents self-hosted open-source platforms inside the client's own infrastructure, including XWiki for teams weighing Confluence costs. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
How we scope
- We start by listing which Confluence editions, spaces, users and apps are in use today.
- We record which Marketplace apps and macros need an XWiki equivalent, a replacement or retirement.
- The written scope names hosting location, database variant, SSO integration and the migration method agreed in advance.
How we build
- We deploy XWiki in your cloud account, data center or air-gapped network, using the database variant your standards require.
- We configure authentication, groups, permissions and backups to match the access model documented during scoping.
- We test a sample of migrated spaces, attachments and permissions against the source before any production cutover.
How we hand over
- You receive documentation covering the architecture, configuration, backup and restore steps, and upgrade procedure.
- We document which Confluence content was migrated, which was not, and what users must check by hand.
- Handover includes a walkthrough with your administrators so they can operate the wiki after the engagement ends.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- A retainer can cover XWiki version upgrades, patch review and periodic restore tests on your schedule.
- Confirm with us in writing which support tasks sit inside the retainer and which are quoted separately.
