Most teams that start a wiki on MediaWiki or Notion do not plan to move it later. Then the maintenance catches up with them, or the per-seat invoice does, and migration becomes the project nobody budgeted for. MediaWiki runs well once it is set up, but every core upgrade means checking which extensions still work, patching the ones that do, and replacing the ones that have gone abandoned - a part-time job for whoever drew the short straw. Notion runs beautifully for a five-person team and then turns into a real line item once that team is twenty or fifty people, because the pricing is per seat, per month, forever.
Both problems share the same root cause: the wiki lives somewhere your members, customers, or community are not. WB Member Wiki solves that by running the wiki inside WordPress itself, with a built-in importer for MediaWiki, Notion, and Confluence exports, so the move does not mean starting your documentation history over from page one. This guide walks through the actual migration - what to export, how the importer handles it, and what tends to break along the way.
Table of Contents
- Why Teams Actually Migrate Off MediaWiki or Notion
- Before You Start: What to Export
- Exporting From MediaWiki
- Exporting From Notion
- Running the WB Member Wiki Import
- How WikiLink Auto-Linking Preserves Cross-References
- Verifying Revision History After Import
- Setting Up Access Permissions Post-Migration
- What Commonly Breaks, and How to Fix It
- Preserving Old URLs and Search Rankings
- A Real-World Scenario: An Open-Source Project Moving Off MediaWiki
- FAQs
- Conclusion
A Notion workspace on the Business plan runs $20 per member per month billed annually - for a 20-person team that is roughly $4,800 a year just for the workspace itself, before any AI add-on. Meanwhile, MediaWiki’s open-source maintenance burden centers on its extension ecosystem: every core upgrade cycle means checking extension compatibility, patching what still works, and finding replacements for anything abandoned. Neither cost shows up on the original decision to adopt the tool - both show up later, which is exactly when migration starts getting seriously considered.
Why Teams Actually Migrate Off MediaWiki or Notion
The MediaWiki migration conversation almost always starts with a security patch cycle that goes wrong, or a core upgrade that breaks three extensions nobody remembers installing. MediaWiki itself is free and genuinely powerful - it runs Wikipedia, after all - but running your own instance means you are the one applying security patches, managing skins and extensions, and testing compatibility with every release.
A small instance runs fine on modest server resources, but the ongoing operational overhead is real and does not scale down just because your wiki is smaller than Wikipedia’s.
The Notion migration conversation starts differently - usually at a renewal invoice. Notion’s per-seat pricing is transparent and fair for a small team, but it scales linearly with headcount in a way that catches growing teams off guard. A 10-person team on the Business plan pays roughly $2,400 a year; double the team and the number doubles with it, with no volume discount kicking in until you are negotiating an Enterprise contract.
For a public-facing knowledge base or a community wiki where “members,” not just “employees,” need edit access, per-seat pricing stops making sense entirely - you cannot put a price-per-editor on content your own customers are writing for you. WordPress does not have either problem. There is no per-seat cost for how many members can edit a page, and WB Member Wiki’s own license is a flat per-site fee rather than a cost that grows with your community.
Before You Start: What to Export
Before touching the importer, take stock of what you are actually moving. Not every migration needs everything preserved - a small internal wiki with no real editorial history might only need the current content moved, but a public-facing documentation site with years of community contributions usually wants it all intact, since the edit history is itself part of the trust signal for readers. Walk through this checklist first:
- Page content - the actual text and media of every page you plan to move
- Internal link structure - MediaWiki’s
[[Page Name]]syntax or Notion’s internal page links between articles - Revision history - who wrote what and when, if authorship and edit trails matter for your community
- Embedded images and file attachments - these do not travel with a standard text export and need separate handling
- Tables and custom templates - flag anything with complex formatting now so it is not a surprise during cleanup
Exporting From MediaWiki
MediaWiki’s built-in Special:Export page generates an XML dump of your wiki’s pages, including full revision history if you check that option. For a full-site migration, export by namespace or by a complete page list rather than one page at a time - MediaWiki lets you paste a bulk list of page titles or export an entire category at once. If your wiki uses extensions for things like infoboxes or custom templates, note which ones before exporting, since templates do not always translate cleanly and may need manual rebuilding as WordPress blocks or reusable patterns after import.
Image and file attachments are not included in the XML export by default - those live in MediaWiki’s images/ directory on the server and need to be copied separately, then re-linked after the text import completes. This is the single most common thing people forget on a MediaWiki migration, so budget time for it rather than discovering it after the fact.
Exporting From Notion
Notion’s export tool (Settings & Members → Settings → Export all workspace content) offers Markdown & CSV or HTML as output formats, plus an option to include subpages and include content from linked databases. For a wiki migration, Markdown export generally preserves more of the original formatting and internal link structure than HTML, and is the format WB Member Wiki’s importer is built to parse most cleanly.
Notion’s export preserves internal page links as relative file paths within the exported ZIP, which the importer uses to rebuild your internal link structure - this is also why exporting the entire workspace (or entire relevant section) at once, rather than individual pages one by one, produces a cleaner result than piecemeal exports where the link targets may not exist in the exported set.
Running the WB Member Wiki Import
With your export file in hand (MediaWiki XML dump, or Notion’s Markdown/CSV ZIP), the import runs from WB Member Wiki’s admin settings: upload the export file, select the source format, and the importer parses the file, creates a wiki page for each source page, and attempts to preserve the internal link structure, revision history (MediaWiki only - Notion’s export does not include a native revision log, so Notion imports start fresh revision history from the import date), and any category/namespace structure that maps cleanly to WordPress taxonomy.
Run the import on a staging site first if you have one, not production. A wiki import involving hundreds of pages is not something you want to redo because a template or category mapping came in wrong - catching that on staging costs minutes, catching it on a live public wiki costs a cleanup project. For very large wikis (several hundred pages or more), consider running the import in smaller batches by namespace or category rather than one giant file - it is easier to spot and fix a problem confined to fifty pages than to untangle it across a import of two thousand pages all at once, and a failed batch partway through is far less disruptive to re-run than a failed full-site import.
How WikiLink Auto-Linking Preserves Cross-References
One of the things that makes a wiki feel like a wiki, rather than a loose collection of documentation pages, is the dense cross-linking between articles - MediaWiki’s [[Page Name]] syntax, where typing a page title in double brackets automatically creates a working link if the page exists, or a red “stub” link inviting someone to create it if it does not. WB Member Wiki supports the same [[WikiLink]] syntax natively, and during import, it attempts to resolve each source page’s internal links against the new page titles created in WordPress, rebuilding the cross-reference web rather than leaving you with hundreds of now-broken links pointing at a MediaWiki URL structure that no longer exists.
A wiki where every internal link is broken after migration stops functioning as a wiki - it becomes a pile of disconnected pages that happen to live on the same domain.
Spend time after the import spot-checking a sample of heavily cross-linked pages (your wiki’s most-visited or most-edited articles are a good starting sample) to confirm the link rebuilding worked as expected before you consider the migration done.
Verifying Revision History After Import
If preserving who-wrote-what-and-when mattered enough to check the “include history” box on your MediaWiki export, verify it actually came through after import. WB Member Wiki’s revision history view shows word-level diffs between any two versions of a page, along with the contributor and timestamp for each revision - after a migration, spot-check a handful of pages with long edit histories to confirm the full chain of revisions is intact rather than collapsed into a single “imported” revision.
For a Notion migration, remember that Notion’s export does not carry a native edit-by-edit history the way MediaWiki’s does, so imported pages will show a single starting revision dated at import time, with fresh revision tracking beginning from that point forward. If preserving pre-migration authorship matters for your community (crediting original contributors, for instance), capture that separately before migrating, since it will not travel with a Notion export automatically.
Setting Up Access Permissions Post-Migration
Once content is in place, set up who can do what. WB Member Wiki’s role-based permissions let you define which roles can create pages, edit existing pages, or need admin approval before an edit goes live - turning on moderated mode routes any edit from a non-admin role into a review queue, where you approve or reject with an optional inline comment back to the contributor.
If your MediaWiki instance ran with open anonymous editing, decide deliberately whether that is the right default post-migration, rather than carrying the old permission model over by default; a members-only WordPress site is often a very different trust environment than a public MediaWiki install was.
If BuddyPress, BuddyBoss, or PeepSo is active on the same site, the wiki tab auto-appears on member profiles and wiki edits surface in the activity feed automatically - worth knowing before migration, since a large bulk import can otherwise flood the activity feed with hundreds of “created page” entries in one afternoon. Consider doing a bulk import with activity notifications paused, then re-enabling them for ordinary day-to-day edits once the migration itself is complete.
What Commonly Breaks, and How to Fix It
- Images and file attachments. MediaWiki’s XML export does not include the actual image files, only references to them. Re-upload images to the WordPress media library and re-link them - for a large wiki, a bulk media-upload pass followed by a find-and-replace on the old image URL pattern is faster than doing it page by page.
- Nested page hierarchies. MediaWiki’s namespace system and Notion’s nested-subpage structure both represent hierarchy differently than WordPress’s flatter page/category model. Deeply nested structures sometimes need manual category or parent-page reassignment after import.
- Templates and custom includes. MediaWiki templates (
{{Template Name}}syntax) do not have a direct WordPress equivalent and typically need to be rebuilt as a Gutenberg reusable block. This is the most labor-intensive part of a heavily templated migration. - Tables and complex formatting. Wiki markup tables and Notion’s table blocks both convert reasonably well to standard HTML tables, but highly customized formatting (colored cells, merged cells, embedded formulas) is worth spot-checking on a sample of complex pages.
Preserving Old URLs and Search Rankings
If your MediaWiki instance or Notion workspace was publicly indexed and ranking in search, those URLs do not carry over automatically - MediaWiki’s /wiki/Page_Name structure and Notion’s long hash-based URLs both look nothing like a typical WordPress permalink. Before going live, map your highest-traffic old URLs to their new WordPress equivalents and set up 301 redirects for each one, so existing search rankings and any external links pointing at the old wiki do not just disappear the day you cut over.
For a wiki with a few dozen pages this is a manageable spreadsheet exercise; for a wiki with hundreds of pages, prioritize the redirects for whatever your analytics show as the most-visited pages first, then work through the long tail afterward rather than treating every single page as equally urgent.
A Real-World Scenario: An Open-Source Project Moving Off MediaWiki
Picture a mid-sized open-source project running its documentation on a self-hosted MediaWiki instance that a volunteer set up five years ago. The volunteer has since moved on, nobody left on the team is comfortable with MediaWiki’s extension ecosystem, and the last two core upgrades were skipped entirely because nobody wanted to risk breaking the install. The project already runs its community forum and member directory on WordPress with BuddyPress, so consolidating the documentation into the same platform means one fewer system to maintain, one login for contributors instead of two, and wiki edits showing up in the same activity feed as forum posts and project updates.
The migration path here is a full XML export with revision history included, a staging import to catch template and category issues first, a manual pass to re-link images, and a final permissions setup that mirrors what trusted long-time contributors already had on MediaWiki - direct edit access - while newer community members go through the moderated review queue until they have built up some track record. The project ends up with the same editorial depth it had before, minus the maintenance burden of an aging extension stack nobody on the current team wants to own.
FAQs
1. Will my MediaWiki page history survive the migration?
Yes, if you check “include history” on MediaWiki’s Special:Export page before exporting. The importer preserves the revision chain, including contributor and timestamp per revision, which then appears in WB Member Wiki’s own word-level-diff revision history view.
2. Does Notion’s export include edit history the same way?
No. Notion’s Markdown/CSV export does not carry a native revision log, so imported pages start a fresh revision history from the import date. If crediting original authorship matters, capture that separately before migrating.
3. Do images migrate automatically from MediaWiki?
No. MediaWiki’s XML export only includes page text and references to images, not the image files themselves, which live in MediaWiki’s images directory on the server. Plan to re-upload and re-link images as a separate step after the text import.
4. What happens to MediaWiki templates during import?
Templates do not have a direct WordPress equivalent and generally need manual rebuilding, usually as a Gutenberg reusable block. For wikis that used templates heavily, this is the most time-consuming part of the migration.
5. Can I run the import on a staging site before going live?
Yes, and it is strongly recommended for any wiki with more than a handful of pages. A staging import lets you catch template, category, and link-resolution issues before they reach the live site.
6. Does WB Member Wiki require BuddyPress to work?
No. WB Member Wiki is a complete wiki on its own. If BuddyPress, BuddyBoss, or PeepSo is active, the wiki tab auto-appears on member profiles and wiki edits surface in the activity feed, but none of that is required for the core wiki functionality.
7. How does WB Member Wiki handle internal links after import?
It supports the same [[WikiLink]] auto-linking syntax as MediaWiki, and during import attempts to resolve each page’s internal links against the new WordPress page titles, rebuilding working cross-references rather than leaving broken links pointing at the old wiki’s URL structure.
8. Can I require admin review before imported or new pages go live?
Yes. Moderated mode routes any edit from a non-admin role into a review queue, where an admin approves or rejects with an optional inline comment back to the contributor.
9. Is WB Member Wiki really a full MediaWiki alternative?
For most communities, yes - it supports WikiLinks, revision history, watchlists, namespaces (as categories), template-style includes, and full search. What it does not do is wiki-syntax markup (it uses the Gutenberg block editor instead) or millions-of-articles scale, which most member communities and internal documentation sites do not need.
10. Is there a money-back guarantee if the migration does not work out?
Yes, WB Member Wiki offers a 30-day money-back guarantee, which is enough time to complete a staging migration and verify it meets your needs before committing on the live site.
Summary
Migrating off MediaWiki or Notion is not a one-click operation regardless of which tool you move to - images need re-linking, templates need rebuilding, and nested hierarchies need a second look. But the actual content, the internal link structure, and (for MediaWiki) the full revision history do not have to start over from zero. WB Member Wiki’s importer handles the structural heavy lifting, and the result is a wiki that lives in the same place your members, customers, or contributors already are, with no per-seat invoice and no extension-compatibility fire drill waiting at the next core upgrade.
Run the import on staging first, budget real time for the image and template cleanup pass, and spot-check your most heavily cross-linked pages before calling the migration done. That upfront discipline is what separates a wiki migration that feels seamless from one that quietly loses half its cross-references and nobody notices until a reader hits a dead link six months later.
Get WB Member Wiki
A collaborative WordPress wiki with built-in MediaWiki, Notion, and Confluence importers, front-end editing, full revision history, and WikiLink auto-linking - no per-seat pricing, ever.
Interesting Reads:
How to Build Multi-Page Surveys with CSV Export on WordPress