Migrate from Confluence with complete data fidelity

Most commonly, organizations plan their migration per team or per department.

For example, in week 1, the Confluence spaces used by the Sales department are set to read-only, exported from Confluence, and migrated to XWiki.

Then the Sales team switches to XWiki for editing and creation of new pages, while their Confluence spaces are kept in read-only for reference. Depending on the size of your Confluence site, you may also be able to do the migration in one shot using the backup export.

The migration typically works like this:

Export from Confluence: Use Confluence's native export mechanisms — space by space (XML) or a full site XML backup. You don't have to stop Confluence to create exports.

Import into XWiki: Install the Confluence Migration Toolkit on XWiki. Go to the Confluence Migrator UI and upload the XML export or select it from your server. Run the migration per space, in batches, or on the full backup. The migrator will import pages, attachments, comments, users, groups, permissions, and more, according to the parameters you set.

Post-migration steps: After import, the tool produces a report of everything imported and any issues identified (e.g. macros without equivalents, broken links). Most standard content comes through well since the toolkit covers history, attachments, labels, users, groups, permissions and many macros.

The recommended approach is iterative: export a space or set of spaces, import to XWiki, review, then plan a cutover. XWiki can handle very large imports — migrations involving terabytes of data have been completed. The main considerations are memory and timeout settings and proper environment setup.

Most teams group multiple Confluence spaces into one XWiki wiki. Subwikis are "buckets" for when you need stronger separation — typically a small number aligned to real boundaries like a department, business unit, region, or security domain. Creating one subwiki per Confluence space rarely makes sense at scale.

It is also completely possible to migrate all Confluence spaces into XWiki's main wiki. The choice between "only a main wiki" versus "a few subwikis as buckets" depends on the kind of content you are migrating and how much separation you actually need in day-to-day operations.

We highly recommend understanding the current workflows and usage of Confluence before starting the data migration. Here is a shortlist of things to consider:

• Decide on the metadata and page assets you want to keep (history, attachments, creator).
• Decide whether you will migrate users and plan their migration.
• Decide upon authentication for the new wiki system.
• Review the macros you are using and check which ones are available in XWiki.
• Set up an XWiki instance with enough resources to execute the migration.
• Stop using the Confluence instance during migration to avoid having to re-run it on the same space multiple times.
• Migrate in batches, per team, and run test migrations before committing to the final production migration.
• Switch teams to XWiki incrementally, starting with the power users, in order to gather feedback and create training materials that ease the transition for the users that will follow.

There are multiple variables that can make a migration complex. The most common ones are:

• number of macros used
• number of page versions
• 3rd party plugins used
• usage of custom macros
• number of users and permissions setup

XWiki SAS offers the full suite of professional services for migrations, from installation and setup to training, consulting, migration execution, and finally long term technical support. Most commonly, organizations prefer to migrate themselves, on their own timeline, and the XWiki SAS architects or partners assist with initial setup, consulting during the migration phase, and long term support once the migration is done.

We encourage organizations to create a free cloud demo to run test migrations and reach out to contact@xwiki.com for any questions related to migration projects.

Yes, but we highly advise using it as part of the Confluence Migration Toolkit, which bundles all the apps (including macros) and services needed to quickly transfer data and benefit from long-term technical support. What you'll find in the Toolkit:

• Confluence Migrator (Pro) for a seamless migration;
• Confluence-specific bridge macros;
• Task Manager (Pro) to keep action items and daily productivity immediately after migration;
• and long-term technical support on the core product, Pro Apps, recommended extensions, and community extensions.

Links to content not yet imported will not work until the target page is created in XWiki, but the issue will not persist after all data has been migrated. If links are still broken after migrating all content, you can fix them using the dedicated "Post migration fixes" included in the migration tool.

There is no need to do so, as permissions can be migrated independently from users. After migrating your pages, you can run a separate migration for users and/or permissions (via the Advanced parameters of the migration), and access rights will be correctly applied. You can even migrate permissions without the users present on the wiki yet — they will apply as soon as the users are created in XWiki.

A fully REST API-based import is not recommended, as some resources are not easily accessible and compatibility issues can arise depending on the Confluence version. You can, however, create scripts to export from Confluence spaces one after the other, organise them in batches, and then use the Confluence Migrator (Pro) to setup batch migrations.

In this way, the migrations will run one after the other and you will be able to review the reports as they are being completed. This method also ensures sufficient resources and produces a report for fixing broken pages after import.

Yes, you can organise your space exports in batches, which will trigger the migration of each space one after the other. Also, if you have a fairly small instance, you can use Confluence's backup export, export the whole confluence site, and migrate the full site in one run in XWiki. All three options (single space, batch, and backup export) are available in the Confluence Migrator (Pro).

Yes, you can re-run migrations on the same space if there's a new version of the content. Pages that did not change will be skipped and pages that have updates will be imported. Alternatively, you can run migrations in batch and move one team/department at a time from Confluence to XWiki.