Document360 vs XWiki: which to choose

Document360 vs XWiki: which fits your documentation team

XWiki is the stronger fit when a large documentation team needs granular governance inside its own infrastructure: spaces that mirror business units, page rights set at the level of individual pages, and structured applications that turn content into records with defined fields. Document360 is the stronger fit when the team wants a vendor-run knowledge base with a managed publishing workflow and does not want to operate a Java application stack. The decision turns on four questions: how deep your permission model must go, who owns hosting and upgrades, whether your staff can run Tomcat, a relational database and extensions, and which vendor-run features, such as SSO connectors or support commitments, you must match on day one. Answer them before the Document360 renewal date, not after it.

Hosting ownership is the first constraint. The official XWiki Docker images, maintained by the XWiki Core Dev Team, come in MySQL, PostgreSQL and MariaDB variants, each running on Tomcat, for amd64 and arm64v8. Your platform team would own the container host, database backups, TLS, Tomcat tuning and every XWiki upgrade, and should decide which line to run (stable, LTS or the intermediate LTS) before choosing an image tag. XWiki is licensed LGPL-2.1, so the software carries no license fee, but the staff time to operate it is a recurring cost that a hosted Document360 subscription largely absorbs. XWiki Standard is free, while XWiki Pro adds business applications and connectors. Support subscriptions are tiered by user count, and XWiki SAS states that cloud and on-premises pricing is the same. Confirm which tier your user count falls into.

If you must match vendor-run features, get the price of each one in writing. XWiki SAS lists consulting at 1200 EUR per day, which requires a Business or Enterprise support plan, and training at 1500 EUR per day, according to its pricing page. Those rates are the cost of the help you buy, so compare them with the internal hours you would otherwise spend on setup, governance design and upgrades. Before you commit, export a representative sample of Document360 content and confirm which of its features your team relies on, such as multilingual publishing and approval workflows. Then test whether XWiki's apps and extensions cover each one, and record the gaps that would need a custom build or a paid engagement.

Which scenarios favor XWiki and which favor Document360

This table maps common documentation scenarios to the platform that usually fits better and the condition that decides it. Read each row against your own team size, data rules and publishing model. The main takeaway is that XWiki suits teams that want page rights, structured data and self-hosting, while Document360 suits teams that want a managed public knowledge base with less operational work.

Scenario	Better fit	Condition that makes it so
Multi-team spaces with strict page rights	XWiki	Your rights model needs space-level and page-level permissions that you can define and audit in your own environment.
Structured data applications such as registers, request logs or asset lists	XWiki	You need structured application data inside the wiki, and you have someone who can build and maintain those applications.
Data that must stay in your own cloud or data center	XWiki	Your policy requires documentation to remain in infrastructure you control, including air-gapped networks.
Team with no platform engineers	Document360	Nobody internal can own patching, backups, upgrades and database administration, and you do not plan to buy a support contract.
Customer-facing public docs with multilingual versions	Document360	Your main need is a public help site with published translations and a managed editing workflow, and you do not require self-hosting.
Team that values a managed vendor for uptime	Document360	Your service expectations depend on a vendor-run platform. Confirm uptime commitments and support terms in writing before you decide.
Self-hosted wiki with vendor support available	XWiki	You are willing to buy XWiki SAS professional support or a Pro subscription to cover features and operations you cannot staff.

Where your documentation data lives under each option

Document360 stores your documentation in a vendor-hosted service, so the questions shift when you move to XWiki. Each card below covers one place where documentation data sits, who controls it, and what your team must check before choosing a deployment.

Hosting location and control

Under Document360, the vendor hosts the content, so your data location follows their hosting arrangements. With self-hosted XWiki, the server, database and attachment storage sit in whichever cloud account, data center or air-gapped network you choose. The decision you need to make is whether XWiki runs in your infrastructure or on XWiki Cloud, which XWiki SAS hosts. Ask XWiki SAS and your own architects to confirm the exact regions and sub-processors before you sign anything.

Docker deployment and database variants

The official XWiki Docker images come in MySQL, PostgreSQL and MariaDB variants, each running on Tomcat, for amd64 and arm64v8. Your database choice decides where page history, rights and metadata physically live, so it should match your existing backup and database operations standards. Confirm which image tag your team will pin, and plan for how upgrades move between the stable, LTS and intermediate LTS lines.

LGPL-2.1 license and what it allows

XWiki and its official Docker image repository are both licensed under the LGPL 2.1. For most internal documentation deployments, this lets you run, modify and host XWiki without paying a per-user license fee. The copyleft obligation applies to changes to XWiki itself when you distribute them, so custom macros and applications should be reviewed with your legal team. Extensions have their own licenses, so check each one before installation.

Identity integration through SSO

Document360 SSO is a commercial feature that your quote may price separately, so compare that line item against XWiki's identity options. XWiki Pro lists Active Directory and Azure Active Directory SSO applications. The xwiki-contrib OIDC extension is an open-source route for OpenID Connect sign-in. Test group mapping, deprovisioning and session lifetime with your identity team, because access removal depends on how these integrations are configured.

Compliance evidence and certifications

XWiki Cloud runs on ISO 27001 certified infrastructure, which applies to the hosted service and not automatically to your self-hosted instance. A self-hosted deployment needs its own controls, access reviews, backup tests and logging, and you must produce the evidence yourself. DeployOpen can prepare controls and evidence for your assessment, but it does not issue audit reports or certifications. Independent auditors and certification bodies make those determinations.

XWiki Standard, XWiki Pro and XWiki SAS support explained

XWiki Standard is the free open-source version of the platform, licensed under the LGPL 2.1. It covers spaces, page rights, wiki structure, the page editors and the structured application model that large documentation teams usually build on. You run it on your own servers or in your own cloud account, using the official Docker images, which come in MySQL, PostgreSQL and MariaDB variants on Tomcat. Licensing is zero, so your costs are the infrastructure, the database, backups, upgrades and the staff time to operate them.

Core features: Spaces, page rights, templates and structured applications are part of the free edition.
Release lines: XWiki publishes a stable line, an LTS line and an intermediate LTS line, so you can pick the line that matches your upgrade cadence.
Docker images: Official images are maintained by the XWiki Core Dev Team and support amd64 and arm64v8.
Operating burden: You own patching, backups, Tomcat and database tuning, and any extension updates.
Extensions: Many add-ons are open source, but availability of a specific connector must be checked in the extension catalog.

Before committing, confirm with your team which features on your Document360 list are covered by the Standard edition and which need an extension or a paid add-on.

What drives the total cost of an XWiki deployment

The main cost question is who gets paid for what, and which costs recur. Document360 is priced by quote, so the subscription moves with seats, workspaces, languages and the features you enable, and the renewal is the recurring line you can renegotiate. XWiki Standard carries no license fee under the LGPL 2.1, which moves the recurring cost to your own team and infrastructure: virtual machines or containers for the Tomcat application server, a MySQL, PostgreSQL or MariaDB database, storage for attachments, backups, monitoring, and the time editors and administrators spend. Setup, migration and extension configuration are largely one-time costs. Hosting, database operations and upkeep recur every year you run the wiki.

Upgrades are the cost most often underestimated. XWiki publishes a stable line, a long term support line and an intermediate LTS line, and the official Docker images are maintained by the XWiki Core Dev Team. Choosing the LTS line lengthens the time between major moves but still requires patching and testing of your extensions on each release. Extension selection changes this further: if you need Active Directory SSO, connectors or business applications that XWiki Pro bundles, you either pay XWiki SAS for the Pro or support subscription or build and maintain the equivalent yourselves. Ask the vendor which tier applies to your user count, since XWiki SAS states that cloud and on-premises pricing is the same for each tier.

When you request a quote for an XWiki deployment, ask for each component as a separate line: the software tier and user band, the support plan and its response terms, consulting and training days at the listed daily rates, any Confluence Migrator Pro licenses, and the hosting and backup assumptions. Ask your implementation partner for a fixed-scope estimate with written deliverables, including who performs each upgrade and how much effort each extension needs. Confirm with your own finance and IT teams how the Document360 renewal, its add-ons and any data export work fit into a single comparison. Model the first year separately from later years, because one-time migration and setup effort usually falls in year one.

Cost components on each side and what moves them

Document360 is priced by quote, so its cost moves with the commercial terms you negotiate. XWiki is free to license under LGPL 2.1, so its cost sits in hosting, people and any paid support or extensions you choose. The cards below set out each component, who is paid for it, and what drives it up.

Software license

Document360 is a subscription priced by quote, and the drivers to confirm in writing are team accounts, workspaces, languages, SSO and AI usage. XWiki Standard carries no license fee under LGPL 2.1, so the license line on the XWiki side is zero. Ask Document360 which of those drivers are included in the base quote and which are add-ons, so the comparison uses the same scope.

Hosting and infrastructure

On the Document360 side, hosting is included in the subscription. On the XWiki side, you run the Tomcat application server and the database in your own cloud account, data center or air-gapped network, or you buy XWiki Cloud hosting from XWiki SAS. Sizing depends on page volume, attachments, concurrent editors and the number of spaces, so ask for a sizing estimate tied to your content before you commit.

Database and storage

XWiki's official images come in MySQL, PostgreSQL and MariaDB variants, so the database engine is a choice you make and pay to run. Attachments and page history grow storage over time, and that growth is recurring. Check whether your organization already runs a supported database platform, because a new database service adds licensing, patching and backup work.

Backups and disaster recovery

Document360 backups sit with the vendor, but you still need an exit copy of your content. With XWiki, you own backup of the database, attachments and the XWiki file system, and you own restore testing. Ask Document360 what it contractually guarantees for restore and export, then budget the storage, the backup tooling and the recurring restore tests on your side.

Upgrades and patching

XWiki publishes a stable line, a long term support line and an intermediate LTS line, so you choose which line to run and how often to move. Each upgrade needs a test environment, extension compatibility checks and a rollback plan. This work recurs for as long as you run XWiki, and it is the main component that a hosted product removes from your team.

SSO and connector extensions

Document360 charges for SSO as a feature in its quote, so confirm whether it is in your tier. XWiki Standard is free, but Active Directory and Azure Active Directory SSO, along with Google Apps, Office365 and OnlyOffice connectors, are listed as XWiki Pro features. The open-source oidc extension on GitHub is an alternative route to SSO, and it needs its own testing and maintenance.

Support subscription

XWiki Pro and support subscriptions are sold in Starter, Basic, Business and Enterprise tiers, and XWiki SAS states that cloud and on-premises pricing is the same. Starter is limited to 25 users and XWiki Cloud only, and Basic covers up to 1,000 users. Support is a recurring cost you can skip, but it is the path to a vendor-backed answer for production incidents, so decide before you go live.

Migration services and tooling

Migration is a one-time cost on both sides. XWiki SAS lists consulting at 1200 EUR per day for Business or Enterprise support plans (xwiki.com pricing), and Confluence Migrator Pro is priced from 2000 EUR (XWiki Store). Export effort on the Document360 side is driven by what the export leaves out, such as comments, attachments and private notes. Ask for a quote that names page counts, attachments and permission mapping.

Training and internal admin time

XWiki SAS lists training at 1500 EUR per day (xwiki.com pricing), which is a one-time cost for an initial cohort and a recurring one for new hires. The largest hidden cost is internal admin time for extensions, rights design and upgrades, which recurs every month. Document360 also takes editor and admin time, but its vendor handles platform upkeep. Estimate both sides from your own team's hours, not from a vendor average.

How a Document360 to XWiki migration typically runs

The sequence moves documentation from Document360 into XWiki in a controlled order, so each space, access rule and public URL is inventoried, mapped, tested with real users and cut over only after a parallel run confirms the content.

Inventory categories, content and access rules
Your content owner and an administrator list every category, article, version, translation, attachment and private note in Document360, and record who can read, edit and publish each category. Identify public URLs that customers or partners bookmark or link to. The output is a written inventory with counts per category and language, reviewed by the content owners. The step is done when every category has an owner and a named set of access rules.
Export content and verify what is omitted
Run the offline HTML export, the ZIP and JSON project exports, and compare them against the inventory. Document360 exports do not give you everything: confirm in your own export whether inline comments, attachments, private notes and version history are included, and record each gap. Confirm attachment history and version fidelity in the actual export, not in documentation alone. The output is an export log and a gap list that the content owners sign off.
Map categories and rights to XWiki spaces
Design the target structure in XWiki: spaces for each Document360 category or audience, and page rights and groups that reproduce the access rules recorded in the inventory. Decide which Document360 features, such as workflow states or multilingual layouts, will be rebuilt with XWiki pages, translations or applications rather than carried over. The output is a mapping document approved by the owners. This step is done when every category has a target space and every access rule has a corresponding right.
Convert and import into a test instance
Convert the export into XWiki content, using an import path that your team or implementation partner has tested in a non-production XWiki instance. Confirm that links, images, tables, code blocks and attachments survive the conversion, and that rights match the mapping. Repeat the import until errors are documented and fixed. The output is a test instance with a defect list, and the step is done when a sample of pages from each space matches the source.
Configure SSO and identity mapping
Connect XWiki to your identity provider and map directory groups to XWiki groups so that rights from the mapping apply to real users. Confirm the authentication method with your identity team and test sign-in, sign-out and group membership changes for each audience. XWiki's OpenID Connect extension is one option to evaluate, and you should confirm its fit with your identity provider. The output is a tested login flow and a documented group mapping.
Run a pilot with real users
Invite a small group of editors and readers from each audience to use the test instance for their actual tasks, and collect findings on search, navigation, editing and permissions. Fix issues in the mapping or the import and re-run the conversion where needed, recording each change. The output is a pilot report with resolved and open items, and the step is done when the content owners accept the structure for each space.
Cut over public URLs and set redirects
Plan the production import, freeze edits in Document360 for the cutover window, and run the final conversion. Set redirects from the old public Document360 URLs to the matching XWiki pages, and test a sample of the links that customers or partners use. Update internal references, search engine entries and any integrations that point to Document360. The output is a production XWiki site with a redirect table and a checked list of public links.
Parallel run until the contract ends
Keep Document360 readable while editors work in XWiki, and reconcile any content changed in either system during the overlap. Track content gaps, permission issues and user support requests, and close them before the contract ends. Confirm in writing with the vendor what access and export rights remain after termination. The output is a reconciliation log and a sign-off that XWiki is the system of record.

Questions buyers ask before switching from Document360 to XWiki

How much effort and time does a migration from Document360 to XWiki take?

The effort depends mostly on how much content you move, how many languages and versions it carries, and how much of it needs restructuring into XWiki spaces. No supplied figure sets a duration, so ask any implementation partner for a fixed-scope estimate built from your own content inventory. Drivers that push the timeline up include translated content that must be re-linked, custom Document360 widgets or embedded assets, and page rights that must be rebuilt by hand. Export your content early (see the Document360 export guidance on this site) so you can measure the real volume before agreeing a scope.

Can our own team migrate from Document360 to XWiki without outside help?

Yes, a team with Linux, container and database experience can install XWiki from the official Docker images, which come in MySQL, PostgreSQL and MariaDB variants running on Tomcat. The harder part is content and structure: mapping Document360 categories to XWiki spaces, rebuilding page rights, and checking translations. Outside help is most useful for hardening, backup design, SSO and the migration itself. Decide based on how many people can give the work sustained time, and ask any partner to state in writing what is included and what your team keeps.

What do our admins and editors need to do during the switch?

Admins own the platform: installation, database and file backups, upgrades, user directory integration and page rights design. Editors need time to review migrated pages, fix formatting that did not survive conversion, and learn XWiki's editor and structured applications. Plan for a parallel period in which both systems are reviewed, and assign a named owner for each content area. Confirm with your platform team how much of their week this will take before you commit to a date.

Do we need XWiki Pro or XWiki SAS support to match Document360 features?

Not necessarily. XWiki Standard is the free open source version, and many knowledge base needs, such as spaces, page rights and extensions, are part of the core platform. XWiki Pro adds business applications, connectors and XWiki SAS support, and lists SSO applications such as Active Directory and Azure Active Directory. Check each Document360 feature you rely on, such as customer-facing portal behavior, analytics or workflow, against the XWiki extensions available to you. Ask XWiki SAS for its Pro and support tier list and what each includes before you decide.

How does XWiki's LGPL 2.1 license affect embedding and redistribution?

XWiki is licensed under LGPL 2.1, and its official Docker image repository is also LGPL 2.1. In practice this lets you run XWiki internally and embed it in your products under the license terms, but modifications to the LGPL-covered library itself must be shared under the same terms. Extensions carry their own licenses, and paid extensions such as Confluence Migrator Pro come from XWiki SAS under separate terms. Have your legal team review the license of every extension and any product you plan to ship with XWiki included.

How should we handle customer-facing public documentation during the move?

Start by separating public pages from internal ones, since they usually need different access controls and publishing paths. XWiki can serve public spaces, but you must configure guest rights, public URLs and search exposure deliberately, and verify them with a test account outside your network. Keep Document360 live for public content until redirects, URLs and search indexing are tested. Ask your security team to review the public configuration and confirm your hosting and CDN plan, because these determine performance and exposure.

What should we ask for in a quote for this migration?

Ask for a written scope that lists the content volume, languages, spaces, page rights, integrations and extensions in scope, plus the deliverables and acceptance tests. Request separate line items for installation, hardening, migration, training, backups and post-go-live support, since these recur or stop at different points. Also ask what is excluded, such as custom development or third-party extension fees, and who holds the license for any paid component. Under DeployOpen's model, most engagements are fixed-scope with scope, deliverables and timelines agreed in writing before work starts.

How DeployOpen helps with evaluation, implementation and migration

The most useful first step for a team weighing XWiki against Document360 is a written, fixed scope that tests both platforms against your own content. DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks, and most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. For this comparison, that scope should name the decisions that matter: how spaces map to your Document360 categories and projects, which page rights model you need across internal and external audiences, whether you need structured applications for the content types you manage, and how translations will be handled. DeployOpen does not publish a price list, so the practical ask is a quote that follows from that written scope, with each line tied to a named deliverable.

Migration is where the scope has the most consequences. Document360 offers an offline HTML site, ZIP and JSON project exports, and the export guide covers what those formats leave out, such as inline comments, attachments and private notes, so confirm those gaps in your own export before estimating the effort. On the XWiki side, the Confluence Migrator Pro extension is the relevant reference only if your source is Confluence, and it does not apply directly to Document360 exports. For Document360 content, expect a conversion and validation step that DeployOpen can own: mapping links, rebuilding navigation, checking permissions and reconciling attachments. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications, so any review of access controls or retention on the new wiki remains with your independent auditor.

After go-live, the recurring costs shift to your team and any support contract. XWiki Standard is the free open-source edition, while XWiki Pro and XWiki SAS support subscriptions are priced by tier; confirm current tier limits and inclusions with XWiki SAS before deciding which features need vendor backing. DeployOpen offers ongoing support, upgrades and continuous testing as retainers, which can cover patching the XWiki platform and its extensions, testing backups and restoring them, and checking access rules after each release. Ask for a written plan that names who performs each upgrade, how a rollback works, and which environment proves a restore before you retire Document360.

How DeployOpen helps teams evaluate and move to XWiki

DeployOpen plans, implements, customizes, integrates, hardens, backs up, documents and supports self-hosted XWiki inside your own infrastructure. We start from the spaces, page rights and structured applications your documentation teams actually need, then agree the work in writing before anything is built.

How we scope

Inventory Document360 projects, versions, translations and private content to decide what moves to XWiki spaces
Map existing reader and editor groups onto XWiki page rights and group definitions in a written scope
Agree which vendor-run features need open extensions, XWiki Pro modules or XWiki SAS support before work starts

How we build

Deploy the official XWiki image variant that matches your chosen database, with the stable or LTS line you approve
Configure spaces, rights, templates and structured applications for your documentation teams
Test rights, search, translations and backup restores against the scope before sign-off

How we hand over

Document the installation, configuration, rights model and backup procedures for your platform and security teams
Run a handover session with administrators and content owners covering editing, review and extension management
Deliver migration mapping and verification records so you can confirm content moved as agreed

How we support

Engagements are fixed-scope, and ongoing support, upgrades and continuous testing are available as retainers
Retainers can cover XWiki version upgrades on the release line you choose, with testing before each change
Ask any quote to state which support, training and migration items fall outside the written scope

Document360 vs XWiki