How to move an old club wiki to a new website without losing members

A club wiki that has run for ten or fifteen years holds more than it seems: rules that changed by vote, records nobody else kept, game logs or meeting notes going back to the start, and links from old emails, forum posts and search results. Moving it is mostly a matter of order. Count everything first, touch nothing you can’t undo, map every old address, and only switch over once people who know the club have checked the new site. Here is the order we follow when we build websites for clubs and organizations.

Step 1: Inventory every page, feature and admin action

Start a spreadsheet before anyone copies a word. It needs four tabs:

• Pages. Every page, the section or namespace it sits in, when it was last edited, and whether it is still needed.
• Files. Images, PDFs, spreadsheets and anything else uploaded, plus which pages use them.
• Features. Search, page history, comments, calendars, plugins, member lists, sign-up forms, anything a member can click and get a result from.
• Admin actions. Who can approve new members, edit pages, lock pages, delete things and change settings, and how each of those is done today.

Most wikis can list their own pages. A DokuWiki has an index view (doku.php?do=index), and MediaWiki has a Special:AllPages page. The features and admin tabs are the ones clubs skip, and they are where the surprises live. If an officer approves members by hand every season, the new site needs a way to do that too.

Get a quote

Step 2: Explore read-only

Look, don’t press. While exploring an old system, never click “forgot password”, delete, or anything inside the settings screens. Old software behaves in ways nobody remembers: we have seen an old system where “forgot password” removed the account instead of sending a reset email. Take screenshots, note what each screen does, and leave without saving.

Before anything else changes, ask whoever has server or hosting access to make a full backup of the files and database. That backup is the safety net for every step that follows.

Step 3: Export the content

How you get content out depends on the software:

• DokuWiki keeps every page as a plain text file in its data/pages folder, with uploads in data/media and old revisions in data/attic. Without server access, a single page’s raw text is available by adding &do=export_raw to its address.
• MediaWiki has a Special:Export page that saves pages to an XML file.
• Hosted wiki services often have an export option in their settings; if not, pages can be copied one by one.

The text then gets converted from wiki markup into the new site’s format. Check tables, links between pages, images and anything a plugin generated, because those break most often. Keep the content, not necessarily the look.

Get a quote

Step 4: Map every old URL to its new page

Every address that worked on the old wiki should lead somewhere sensible on the new site, through a 301 (permanent) redirect. That keeps old bookmarks, emailed links and search results working, and tells Google and Bing where each page moved.

Build the map in the spreadsheet. A DokuWiki map might start like this:

A few rules make the map work:

• Send each old page to its closest new page, not everything to the home page.
• Handle the query string. DokuWiki puts the page name after ?id=, and many simple redirect lists only match the part before the question mark. We handle these in the site’s code: read the id value, look it up in the map, send the 301.
• Collect every address form. Depending on its settings, a DokuWiki may also use doku.php/rules or /rules style addresses. Pull real addresses from the old sitemap, from Google Search Console or Bing data if you have it, and from links in old emails.
• Check that you control the domain. Redirects only work if the old address points at the new site. If the wiki lives on a free host’s address you can’t redirect, put a notice with a link on the old pages instead.

Get a quote

Step 5: Keep logs and archives searchable

Archives are often the reason members still visit. Don’t flatten them into one giant PDF. Put each entry in a database with fields such as date, season or year, title, people involved and the text itself. Then each entry gets its own page and address, lists can be grouped by year, and site search can find an entry by name or date. That structure also makes the redirect map easier, because old log pages line up with new archive pages one to one.

Step 6: Move members and roles

1. Export the member list with names, emails, current role and whether each account is still active.
2. Ask officers which accounts to keep. Old wikis collect years of inactive and spam accounts.
3. Map old groups to new roles, such as admin, editor, member and guest. Write down what each role can see and do. Our guide to member roles and approvals covers how to set this up.
4. Plan passwords. Import each account with its email and role, then send each member a link to set a new password.
5. Set up approvals for new sign-ups, so an officer decides who gets in.

If the club needs more than a standard member area, such as custom records, forms or rules about who can edit what, that is the kind of thing we build as part of our custom web apps work.

Get a quote

Step 7: Give reviewers demo access

Before switching over, put the new site at a private preview address and give the club’s reviewers a demo login for each role: one admin, one editor, one regular member. That way officers see exactly what each kind of member will see. Collect their feedback in one shared list, and ask them to check the pages they use most against the old wiki side by side.

Launch checklist

1. Every page in the inventory is marked as moved, merged or dropped on purpose.
2. Every uploaded file opens from its new page.
3. Links between pages work, with no leftover wiki-style links.
4. Every old address in the redirect map returns a 301 to the right page, tested as a full list, not a sample.
5. Members are imported with the right roles, and password invitations are ready to send.
6. Site search finds archive entries by name and by year.
7. The new sitemap is submitted in Google Search Console and Bing Webmaster Tools.
8. The domain points at the new site and HTTPS works.
9. The old wiki is read-only and backed up, not deleted.
10. Officers have signed off.

Your next step

If your club or organization is sitting on an old wiki and isn’t sure where to start, send us its address and a short note on what members use it for through our contact page. We’ll start with the inventory and give you a plan before anything is touched. For more on how we build sites for groups like yours, see our clubs and organizations page.