What a Confluence to XWiki migration involves
Most moves start with one of four triggers: Confluence licensing changes or cost, data residency rules that require hosting in a specific jurisdiction, a requirement to self-host inside your own network, or a plan to consolidate several wikis into one. The migration covers the full path: inventory, mapping spaces and permissions, a pilot, the full run, validation and cutover. Confirm which trigger drives the move first, because it sets how strict the cutover window must be.
What transfers and what does not. Confluence Migrator Pro from XWiki SAS moves spaces, pages, users, groups, permissions, attachments and metadata, and it keeps page history. It does not keep attachment history, and macros and layout differences between the two editors need planned rework. Inventory the macros and attachment versions in each pilot space before estimating effort, and ask the vendor to confirm how each macro type maps in the XWiki version you plan to run.
In-house or partner. A team with Java, servlet container and database experience can run a pilot alone, which tests the tool, the mapping and the rework list on a few representative spaces. Teams with many spaces, complex permissions or a strict cutover window often bring in a partner for the mapping, rework and cutover. XWiki SAS also offers Confluence to XWiki migration services, so request that offer in writing and compare its scope with an independent plan.
What the work includes
The migration is delivered in ordered work packages, each closing with a written output the client can review. The list below shows what the partner covers and what the client should expect to receive.
Discovery and content inventory
We inventory the Confluence instance by space, page count, page tree depth, users, groups, permission schemes, attachments and installed apps. The output shows which content moves as-is, which needs rework and which is stale or out of scope. Check that the inventory covers every space owner's list, including personal spaces and archived spaces.
Target XWiki platform setup
We build the target on the official XWiki Docker images, choosing the stable, LTS or intermediate LTS line and the MySQL, PostgreSQL or MariaDB variant that runs on Tomcat. The choice of line affects how long the wiki receives support, so confirm it against the current XWiki release policy before build. The environment is set up in the client's own infrastructure.
Space and permission mapping design
We design how Confluence spaces, groups and page restrictions map to XWiki wikis, spaces, groups and rights. This includes which Confluence permission patterns need simplifying and who approves the mapping. The mapping document becomes the reference for every trial run and for the cutover.
Tooling setup and trial runs
We install and configure the migration tooling, then run trial imports against a copy of the source. Each trial produces a log of skipped items, warnings and failed pages. Confirm the trial limits of any licensed migration tool before planning volume, since trial scope can be smaller than the production content set.
Pilot spaces
We migrate a small set of representative spaces first, chosen to cover different page structures, macro use, attachments and permission patterns. Pilot users check content, links, search results and access. Findings feed back into the mapping document before the full run.
Macro and content rework
Confluence macros, such as table of contents, page includes, status lists and third-party app macros, often need a target equivalent or manual rewrite in XWiki. We log each rework item with its source page, the decision taken and the owner who signed off. Third-party app macros with no XWiki equivalent are flagged early.
Full migration rehearsals
We run complete migrations against a copy of production at least once before cutover. Each rehearsal measures item counts, broken links, permission differences and rework backlog against the inventory. Rehearsal results decide whether the cutover window is realistic, so record run times for planning.
Cutover and post-cutover checks
We execute the cutover from the runbook, including source freeze, final delta import, DNS or redirect changes and validation sign-off. Post-cutover checks cover search indexing, permission spot checks, redirects from old Confluence URLs and user access. The runbook includes a rollback plan with defined decision points.
Out of scope items
Unless agreed in writing, the work excludes archiving attachment history, which the migration tool does not carry over, and replacing third-party Confluence apps with XWiki extensions. Those items need separate scoping, with their own inventory, owner and acceptance criteria. Confirm this boundary during discovery so budget and timeline reflect it.
What drives cost and duration
This table lists the migration inputs that most change effort and schedule, why each one matters, and how to reduce its impact before the pilot begins.
| Driver | Why it matters | How to keep it down |
|---|---|---|
| Spaces and pages | Each space must be mapped, reviewed and tested, so total volume drives both migration runtime and review effort. | Archive or retire stale spaces first, and agree the space mapping list before any import starts. |
| Page history depth | Migrator Pro keeps page history, so long version chains increase data volume and the checks reviewers must perform. | Ask whether a version cutoff is acceptable, and document the retention rule for each space. |
| Attachment volume and history | Migrator Pro does not keep attachment history, so any required file versions need manual handling. | Migrate current attachments by default and record which files need separate version handling. |
| Macros and Confluence-specific apps | Each macro or app without an XWiki equivalent needs rework, and the effort grows with how widely it is used. | Inventory macros per space, remove unused ones, and agree a replacement pattern for each macro type. |
| Permissions and groups | Spaces, groups and page restrictions must map to XWiki rights, and mismatches usually surface late in testing. | Simplify groups before migration and confirm the rights model with a small test space. |
| User count and directory integration | Accounts, groups and identity links affect cutover timing and the login testing needed for each user group. | Choose the identity source early, and remove inactive or duplicate accounts before migrating. |
| Pilot rounds and rehearsals | Trial migrations are limited to 30 pages per migration, so pilot samples must cover macros, permissions and attachments. | Plan full dry runs before cutover. The vendor lists Migrator Pro from 2000 EUR, so confirm licensing early. |
| Integrations that must keep working | SSO and Office connectors need testing in each environment, and XWiki Pro connectors and applications are a separate choice that changes scope. | Map each Confluence integration to an XWiki option, and decide early whether Pro connectors are in scope. |
| Number of environments | Each environment needs its own migration run, configuration and validation before cutover. | Keep test, staging and production configurations aligned, and limit environments to those the plan requires. |
Migration phases and outputs
The sequence moves Confluence content into XWiki in controlled stages, with a named output at each phase so the team can confirm readiness before moving on.
Run discovery and inventory
Your team and ours list Confluence spaces, page counts, attachments, users, groups, permission schemes, macros in use and integrations that read from the wiki. The output is a written inventory with a space-by-space owner and a list of content that will need manual rework. Done when every space has an accountable business owner and the inventory is signed off.
Design the target XWiki
We document the target design: the XWiki line (stable or LTS), the database variant, the servlet container, the identity source and the permissions model. The output is an architecture and permissions design record that names each decision and its reason. Done when the platform owner and security lead approve it in writing.
Map Confluence spaces and rights to XWiki
Each Confluence space is mapped to an XWiki space structure, and Confluence users, groups and permissions are mapped to XWiki groups and rights. The output is a mapping sheet reviewed against the design record. Done when every space has a target location and every group has a documented rights outcome.
Trial the migration tooling
We run Confluence Migrator Pro against representative content. The trial is limited to 30 pages per migration, so it proves the mechanics on a sample rather than a full estate, and a licensed run is needed for the complete move. The output is a trial report listing what transferred, what did not and what needs rework. Confirm licensing and pricing with XWiki SAS before this step.
Pilot with business owners
Selected spaces are migrated into a non-production XWiki and reviewed page by page with their business owners. The output is a pilot acceptance log covering content accuracy, navigation, search results and rights. Done when owners sign off or the defects are logged and fixed.
Rework macros and attachments
Macros that do not carry over cleanly are rewritten or replaced, and attachments are checked for size, naming and links. Attachment history is not transferred by the migration tooling, so the team decides what history to keep as an archive. The output is a rework register with each item marked as fixed, accepted or retired. Done when no open item blocks a space.
Rehearse, cut over and support
Full rehearsals run the whole migration end to end until the runbook and timings are stable, then the production cutover runs inside an agreed freeze window on Confluence. Hypercare follows go-live with defect triage and access checks. The outputs are a tested runbook, a cutover record and a hypercare exit report. Ask for the phase plan in the written scope and confirm all timing against your own change calendar.
What usually goes wrong
Most migration problems come from content that the import does not carry over cleanly and from decisions made during mapping. Each risk below names the check that prevents it.
Macros that drop content silently
Confluence macros, including those for Jira issues, status lozenges and third-party plugins, may not translate into XWiki equivalents, and some content can disappear without an error. Build an inventory of macro usage per space, then compare a sample of rendered XWiki pages against their Confluence sources to confirm nothing is missing.
Attachment history assumed to move
Confluence Migrator Pro keeps page history, but attachment history is not carried over, so earlier file versions may never reach XWiki. Confirm the current transfer behavior with the vendor, decide whether older file versions must be archived separately, and keep Confluence read-only for a defined period so the source stays available for reference.
Access flattened or misread during mapping
Permissions can be flattened during mapping, and users and groups can be matched to the wrong directory identity or left unmatched. Reconcile users and groups against your directory before the first bulk import, then review restricted spaces and inherited rights page by page against the XWiki rights model.
Stale search and broken links
Imported pages stay out of search results until the index is rebuilt, so run a full reindex after import and test the queries users rely on most. Changed URL structures also break bookmarks and internal links. Map old Confluence paths to new XWiki addresses and test the redirects before cutover.
Pilots that skip the messiest spaces
A pilot limited to small, clean spaces shows little about the rest of the wiki. Include the largest spaces, heavy macro users and spaces with unusual permissions in the pilot, and record reconciliation counts for pages, attachments and users in each, so gaps appear before the full run.
Cutover without a tested rollback
A cutover plan needs a rehearsal that runs the full import, reconciliation and rollback steps against a copy of the production data. Define who decides to roll back, how long Confluence stays read-only, and what happens to edits made in XWiki during that window. Record how long each step takes so the schedule rests on measured results.
How the migration changes by starting point
A small wiki with few macros is the lowest-effort starting point. Discovery can usually be completed by one person working through the space list.
- Discovery: Inventory spaces, page counts and attachments, and confirm the few macros in use are standard ones.
- Mapping: Map Confluence spaces to XWiki spaces one to one, and confirm the user and group list is current.
- Rework: Expect small manual fixes to layout macros, then review the migrated pages in a pilot space.
- Confirm with the vendor: Ask whether the 30-page trial limit per migration covers your test runs before you buy a license.
Years of history and many personal spaces turn discovery into a triage exercise. Scope decisions matter more than tooling at this stage.
- Discovery: Identify stale spaces, personal spaces with departed owners, and content nobody uses, then decide what migrates at all.
- Mapping: Decide how personal spaces map to XWiki user areas, and agree permission rules with data owners before any batch runs.
- Rework: Plan migrations in waves by department so pilot findings improve later waves.
- Confirm with the vendor: Ask how the migrator performs at your page and history volume, and request a written scope that lists batches, exclusions and cutover steps.
A Confluence instance that depends on marketplace app macros needs the most mapping work, because the result in XWiki depends on what replaces each app.
- Discovery: List every app macro with its page count, and separate macros that render content from those that drive reports or workflows.
- Mapping: For each macro, choose between a native XWiki equivalent, an extension or XWiki Pro application, or a rebuild using structured data.
- Rework: Budget for manual rewriting of pages that depend on app behavior, and retest each page after every change.
- Confirm with the vendor: Ask which Confluence macros the migrator converts, which it carries over unchanged and which it cannot read, and get the answer in writing.
When auditors need attachment history, the design must cover a gap that the migration tooling does not close on its own. Page history transfers, while attachment history does not.
- Discovery: Identify which spaces hold regulated records, and whether auditors need earlier attachment versions or only the current files.
- Mapping: Decide how Confluence attachment history will be preserved outside XWiki, such as a read-only archive with an index, and name the owner who signs off on it.
- Rework: Add a verification step that compares attachment counts and file integrity for in-scope spaces before cutover.
- Confirm with the vendor: Confirm in writing what Confluence Migrator Pro transfers for attachments and what it leaves out, and agree the evidence package with your auditor. DeployOpen prepares evidence, but auditors assess it.
An air-gapped or on-premises target removes access to cloud tooling, which changes where discovery and mapping run and how software arrives.
- Discovery: Run inventory and review steps inside the isolated network, and confirm which Confluence export methods work without outside connections.
- Mapping: Keep mapping workbooks on the isolated side, and plan how approved files move in and out under your transfer rules.
- Rework: Stage XWiki images, extensions and the migrator in an internal registry or artifact store before the build, since public pulls may be blocked. The official XWiki Docker images are available in MySQL, PostgreSQL and MariaDB variants.
- Confirm with the vendor: Ask whether the migrator and its updates can be installed and validated without outbound connections, and what offline support is available.
What you need to provide
Start with access. The migration team needs admin rights on the source Confluence instance and a read-only export window, so every space, user, group and permission can be read without content changing during the run. Ask the Confluence administrator to confirm which spaces are in scope and to name a business owner for each one. Owners decide whether a space is archived, merged or migrated, which moves the scope more than page count does. Put the administrator and each owner's role in writing before work starts.
Decide now which history and attachments must be kept. Confluence Migrator Pro keeps page history but not attachment history, so if legal or records teams need earlier attachment versions, that work must be planned as a separate task and owned by the compliance or records lead. The tool is priced from 2000 EUR, and its trial is limited to 30 pages per migration, so the license tier belongs in the procurement decision before the pilot starts. Procurement and the platform owner should agree on it together.
Choose the target hosting location and database. XWiki's official Docker images come in MySQL, PostgreSQL and MariaDB variants, each running on Tomcat, and the choice should follow your database standards and backup tooling. Hosting in your own cloud account or data center is a different scope from XWiki Cloud, so the infrastructure owner must confirm it. Also provide identity provider details for user matching: the directory source, the attribute that links Confluence accounts to directory accounts, and how disabled users should be handled. The identity team should own this input.
Name pilot space owners and a sign-off approver before any content moves. Pilot spaces test macros, permissions and attachment handling on real content, and their findings set the rework estimate for the rest of the wiki. Each pilot needs a named approver, and one person should be accountable for go-live approval. Finally, agree a change window for cutover with the business, including when Confluence editing stops during the final sync. The service owner should book this window early so that it does not collide with other releases.
Costs before and after cutover
This table separates one-time migration costs from recurring running costs, with the vendor figures supplied for each and what to confirm before you sign a quote.
| Cost component | One-time or recurring | What drives it and what to ask for |
|---|---|---|
| Discovery and mapping | One-time | Inventory of spaces, macros, attachments and permissions. Ask for a fixed scope and a named list of spaces in it. |
| Migrator tooling licence | Confirm with XWiki SAS | Confluence Migrator Pro is priced from 2000 EUR per the XWiki Store. Confirm whether this is one-time or recurring, and the unit it is priced per. |
| Manual rework hours | One-time | Macros, layout fixes and attachment history that the migrator does not carry over. Driven by macro count and page complexity. Ask for hours per macro type. |
| Trial and rehearsal runs | One-time | The trial is limited to 30 pages per migration. Full rehearsals repeat until the data is clean. Ask how many runs the quote includes. |
| Hosting and backups | Recurring | Servers, storage, database and backup retention in your infrastructure. Ask for sizing assumptions and how restore tests are costed. |
| Platform patching | Recurring | Time to apply XWiki and servlet container updates and recheck extensions. Driven by release cadence and how many extensions are installed. |
| Support subscription (if chosen) | Recurring | Tiers by user count: Starter up to 25 (cloud only), Basic up to 1,000, Business up to 10,000, Enterprise unlimited. Confirm edition needs with XWiki SAS. |
| Consulting and training days | Recurring or per engagement | Consulting is 1200 EUR per day and requires a Business or Enterprise support plan. Training is 1500 EUR per day. Ask for the days you need. |
| Internal staff time | Recurring | Administrators, space owners and reviewers before and after cutover. Ask who signs off each migrated space and for how long. |
Frequently asked questions
Does Confluence Migrator Pro move attachment history and page history?
It keeps page history but does not keep attachment history, according to XWiki SAS's description of the tool. Attachments themselves move with their pages, so the file users see after cutover is the current version. If earlier attachment versions matter for records or audit, decide before the pilot whether to archive them separately. Confirm the exact behavior with XWiki SAS against your Confluence version and your attachment volumes.
Do Confluence macros convert to XWiki automatically during migration?
Do not assume they do. The supplied scope for Confluence Migrator Pro covers spaces, pages, users, groups, permissions, attachments and metadata, so macro conversion is a separate question to verify. Start by inventorying the macros in use, counting how often each appears and how much each matters to the business. Test each macro type on pilot pages, and plan manual rework for any macro without a working equivalent in XWiki.
Do Confluence permissions carry over exactly into XWiki?
The tool migrates users, groups and permissions, but exact carry-over depends on how your Confluence restrictions map to XWiki rights. Space-level restrictions, page-level restrictions, inherited settings and group membership all need checking. After each pilot run, compare sample pages in both systems as seen by representative users from each group. Get the mapping rules in writing before cutover, and treat every mismatch as a defect to fix in the migration design.
How can we pilot a Confluence to XWiki migration within the trial limit?
The trial of Confluence Migrator Pro is limited to 30 pages per migration, so a trial pilot can only sample your content. Choose a small set of spaces that covers your macro types, large attachments, restricted content and key user groups. Run each pilot as a repeatable migration, log defects, fix the mapping and rerun. XWiki's store lists the tool from 2000 EUR, so confirm license terms with XWiki SAS before planning the full run.
What happens to search and links after a Confluence cutover?
Old Confluence URLs are unlikely to resolve to XWiki pages unless you plan redirects. Bookmarks, external links and links inside migrated pages need an inventory so you know what breaks. XWiki search only returns content it has indexed, so confirm the index is built and healthy on migrated data before users go live. Ask your implementer for a link inventory, a redirect approach and a search test plan, and verify each one during the pilot.
How do in-house and partner costs compare for a Confluence to XWiki migration?
Published XWiki figures give two reference points: Confluence Migrator Pro from 2000 EUR, and XWiki SAS consulting at 1200 EUR per day, which requires a Business or Enterprise support plan (XWiki's pricing page). In-house work costs staff time for mapping, macro rework, testing and cutover, plus any tool license. Duration depends on page and attachment volume, macro rework, permission complexity, pilot rounds and the cutover window. DeployOpen agrees a fixed written scope before work starts, so request scope, deliverables and timeline in writing before comparing.
How DeployOpen delivers XWiki migrations
DeployOpen plans and runs Confluence to XWiki migrations inside infrastructure you control, starting with a written scope that separates what the migration tool transfers from what needs manual rework. Each phase ends with a checkpoint your team can review before the next one begins.
How we scope
- The written scope lists which Confluence spaces, pages, users, groups and permissions move, and which are excluded.
- We inventory macros, attachments and page history to flag items that need manual rework or a decision before cutover.
- Engagements are fixed-scope, so deliverables, pilot spaces and timelines are agreed in writing before any migration work starts.
How we build
- We stand up the target XWiki environment in your infrastructure and run a pilot migration on selected spaces first.
- We test migrated pages, permissions and attachments against the source, and document the mapping and gaps for each space.
- We plan the cutover sequence, including the final sync, freeze window and rollback steps, and rehearse it before go-live.
How we hand over
- Your team receives the runbook, migration reports, mapping decisions and a list of items that were rewritten or left behind.
- We document the configuration, backup routines and the steps needed to repeat or verify a migration batch later.
- Handover includes a walkthrough with administrators so your team can operate the new wiki without outside help.
How we support
- Ongoing support, upgrades and testing are available as a retainer after go-live, covering issues that surface once users arrive.
- We help you plan staying on a supported XWiki release line and test extensions before each upgrade.
- Support scope, response expectations and review cadence are written into the agreement so both sides know what is covered.
