Migrate from MediaWiki to XWiki

Plan users, groups and rights as a separate workstream from content import. A MediaWiki XML export carries page text, revisions and attachments, but you should not assume that accounts, group memberships and rights arrive in XWiki in a form you can rely on. Treat the account and permission model as something you map on paper, recreate deliberately and then test with real users before cutover.

Start with an inventory of the MediaWiki side. List the user accounts that have edited or are expected to edit content, and list every group in use, including built-in groups such as sysop, bureaucrat and the anonymous and logged-in classes, along with any custom groups your site added through its configuration. For each group, record what it can actually do on your wiki, which namespaces or pages it touches and who owns it. Then decide, group by group, whether it becomes an XWiki group, a role on a space or a rule that does not need to exist at all. Avoid a one-to-one copy of every MediaWiki group, because many were created for MediaWiki-specific rights that have no direct XWiki equivalent.

Next decide where each permission should live. In XWiki, rights can be granted at the wiki, space or page level, and lower levels can inherit from higher ones unless you override them. Set broad read and edit rights on spaces that match your team structure, and reserve page-level rights for the small number of pages that genuinely need different treatment, such as restricted HR or finance pages. Each page-level override is a maintenance cost, so keep a short written register of them. Confirm the exact right names, inheritance behavior and any administrator-only rights against the XWiki version you are deploying, using its administration documentation rather than memory of an older release.

Identity is the other decision. Existing MediaWiki passwords are generally not something you should migrate directly, so decide early whether XWiki accounts will be local, or whether sign-in will be delegated. If you want XWiki users to authenticate against an existing provider, the xwiki-contrib OpenID Connect extension (xwiki-contrib/oidc) can authenticate XWiki users against an external OpenID Connect provider, and it can also make XWiki act as a provider itself. Check its compatibility with the XWiki version you select, test it with a non-production account set and confirm how it maps identity claims to XWiki users and groups. Active Directory and Azure Active Directory SSO are offered as applications in XWiki Pro, which is a separate paid product choice. Confirm with XWiki SAS whether that product fits your environment, licensing and support model before you assume it is part of the plan.

Finish with a validation pass. Create a test set of accounts and groups, sign in as representative users from each group, and check read, edit, comment and administrative actions on sample pages in each space. Record the results against your permission register, fix mismatches, and repeat the check after the final import. Include orphaned edits and former accounts in the review so that attribution questions do not surface after go-live. Document who owns group membership changes after cutover, because the access model is only as good as the process that maintains it.

The validation work after a MediaWiki import answers three questions before any user is switched over: are the pages all there, do the links still lead somewhere, and does the converted syntax still render the way content owners expect. Treat these as separate checks with separate evidence, because a clean page count can hide broken internal references, and a clean link crawl can hide tables that collapsed into plain text. Start with inventory. Compare page counts and attachment counts per space between the MediaWiki XML export and the XWiki target, using the same namespace-to-space mapping you agreed during the test import. Mismatches usually come from pages skipped by the export, redirects handled differently from articles, or files whose names were altered during import. Record each difference and its cause. Do not accept a total that matches only because one space gained pages and another lost them. Next, crawl internal links. The key point is that link rewriting depends on how the source links were formed. Links written with a plain page title, links that use namespace prefixes, links to files, and links built from templates or external links behave differently in the filter and converter. Do not assume the importer rewrote them correctly. Run a test import, crawl the result for broken references, and confirm for each link form in your own wiki whether it resolved, pointed at the wrong space, or stayed as the original text. Templates that generate links deserve their own check, since the generated output can change even when the stored source looks unchanged. Spot-check converted syntax by hand. Sample tables with merged cells, images with sizes and captions, heading hierarchies, and any macros or parser functions your MediaWiki pages used. Compare each sample with the source rendering side by side. Templates whose output changed should be reviewed as a group, with the content owner confirming that the new output still says what the page is meant to say. Syntax gaps are expected for some constructs, so the goal is an agreed list of accepted differences, not zero differences. Sign-off belongs to the wiki owner for content accuracy, with the platform team confirming the technical checks. Content owners should receive, for each space they maintain, the count reconciliation, the list of broken or rewritten links with their resolution, the reviewed template list, and a sign-off record. Ask your partner or internal team to define these evidence items in the written scope before the test import, so cutover is decided against an agreed standard rather than a general impression.