Child pages
  • Example worksheet
Skip to end of metadata
Go to start of metadata

Wiki Content Migration Worksheet

1. Overview

Proper planning and thought for your Wiki migration is crucial to success. There are three areas of planning, all of which should start around the same time, with continual diligence to ensure success.

These areas are:

1. User Community Planning

2. Systems Planning

3. Information Architecture

User Community Planning

Experience has shown that User Community Planning is often short-circuited or underestimated in importance, and we feel it is in proper due diligence on our part to clearly emphasize the importance of this.

During our initial meeting discussing your migration plans in greater depth, we will provide additional details on the type of user community planning required.

For example...
This will vary depending on your organization, but this might include:

Coordinating with your wiki's content managers
Communicating expectations to your userbase, either directly or through department managers
Designating an internal Wiki champion or Information Architect position ongoing to ensure quality structure and ongoing content management
and many others.

– the point, in short, being: going out right and keeping it right.

Systems Planning

While every wiki is unique not only by brand or flavor, and in particular by data content, structure, and integrity – let alone personal user styles – this worksheet attempts to highlight some of the most common areas that need to be considered for best results in a wiki migration processes.

Please fill out the following worksheet questions as best possible. It is OK if you do not know all the answers – that is not uncommon. Afterall, you were busy using it, not studying its overall syntax.

Nonetheless, a first cut effort on this checklist provides alot of context for planning and defining the best strategy forward. Every migration is unique.

3.1 Environment Details

Current Wiki brand and version:  mediawiki Number of pages: 7655
Number of Attachments: 5965
Current OS that Wiki is running on: linux External Database running with the current Wiki: oracle Size (inGB) of database: 7000

Application server, if applicable: Tomcat
New Environment anticipated for new Wiki (OK if not sure): 

just to see how this works

3.2 Content Syntax Transformations

Following are some typical context syntax areas to think about when planning for your migration.

Please check all areas that are in use in your wiki in a typical or atypical way. Also add anything that isn't represented here.


Table 1: Content Syntax Transformations


Do you have this? If so, is it used consistently?

wiki syntax

  • links: internal
  • links: external
  • links: anchors
  • bold
  • italics
  • strike
  • underline
  • lists
  • headers
  • table of contents (auto or manual)
  • mailto
  • horizontal rule
  • signature
  • interwiki links

inline html syntax - some wikis allow inline html

  • <b>
  • <i>
  • <em>
  • <strong>
  • <table><tr><td> table syntax
  • <ol><ul><li> list syntax
  • <s>
  • <h1><h2>...
  • <tt>

syntax language tags

  • code
  • pre
  • leading spaces = noformat
  • math (latex) <math>
  • templates


  • headers used?
  • row/colspan used?
  • tables within tables?
  • images within tables?
  • captions?
  • formatting?

what table features do you need?

  • any in-house XML
  • any XML that is not within code or pre tags





3.3 Metadata


Another area that is very important to consider in your migrations planning is metadata included with your existing data. Please list any metadata transformations you are expecting.

Table 2: Metadata Migration Review



Do you want it preserved in the new Wiki? 

  • categories, tags, labels 
  • comments and/or discussion pages 
  • full page history 
  • user/author data 
  • timestamp data 
  • hierarchy (child/parent relationships) 



Do you have a hierarchy that you have built that needs preserving?


Have you thought about Space design in the new Wiki system?



3.4 Attachments


Attachments should be attached to the page that refers to them? (Means extra attachment uploads if referred to from multiple places.)



Attachments placed in a centralized location?
(Not recommended if out wiki is expecting attachments per page, not centralized.)


What about orphaned attachments? (attachments that no page is referencing anywhere?)

Please check all areas that are in use in your wiki in a typical or atypical way. Also add anything that isn't represented here.

3.5 Existing Extensions/Plugins Installed on Current Wiki?


If you are using non-out-of-the-box extensions or plugins in your current wiki and you want those feature sets preserved, please let us know.


Can you please attach a copy of your “system information” page, or similar for the Wiki you want to move from? This will typically show the plugins and environment variables on your system - and this can be “matched up” for Confluence systems.

_____________________________________________________________________ _____________________________________________________________________ 


3.6 Archiving or Not Migrating All Data?


Can some of your data be left behind (archived)? _____________________________________________________________________ _____________________________________________________________________

Is there a set of rules that we can use to distinguish what data should be moved and what should not? If you would like some strategy ideas on this discernment, we can provide.



3.7 Language and Encoding


Are you using any non UTF-8 character encodings? Do you expect for this to be preserved? _____________________________________________________________________ _____________________________________________________________________ Do you have any foreign language specific syntaxes?

(For example, we've run into mediawikis that use the syntax [[Bild: instead of [[Image: )

_____________________________________________________________________ _____________________________________________________________________ 


3.8 Any Custom Namespaces?


Some wikis (like mediawiki) allow custom organizational schemes. For example, in mediawiki, a link to a custom namespace might look like: \[\[Mynamespace:Pagename\]\]
Do you have any that come to mind that you know of? _____________________________________________________________________ _____________________________________________________________________


3.9 Special Functions or Features?


Do you have any special functions or features in your old wiki that are an absolute must-have in the new one (even if outside of the content migration needs)? For example:

Email handler that allows you to mail in content to your Wiki? _____________________________________________________________________ _____________________________________________________________________

Special function plugins or extensions? _____________________________________________________________________ _____________________________________________________________________


4. Information Architecture


The Information Architecture is a crucial planning area of your new migrated system, at both a task level and user experience level. This should be considered before your migration, and also after.

The reasons an organization chooses to migrate are usually one or more of the following:

the old system has inadequate functions, or
the old system lacks a space-level architecture to better sort content, or
in many cases – they simply want to start fresh: divorce their old messy sandbox Wiki and have a nice clean, crisp, shiny new Wiki system

While a nice clean Wiki system is indeed the goal and desire for all resulting new migrations, this architecture needs some planning and forethought, which sometimes also has a big impact on system-level migration efforts.

This is because there is no magic migration bullet when dealing with unstructured data.

Bad content on the OLD system is still bad content on the NEW system.

A migration is the perfect opportunity to get a fresh start, fresh information architecture, and new beginning.

We can assist you not only in taking a stab at what the new architecture will be, but also implementing, scrubbing, and ensuring that it is crystal clean on the other side. Your active engagement will be required in the many continual decisions involved in this area.

For now, this item is listed on the worksheet to get you thinking of this crucial area for great adoption! Remember: It all starts with the content!


5. Discussion Notes


This checklist is not a replacement of a full review of your system during a planned and controlled migration.

It is a “kick start” overview of your system to best strategize and design a successful migration plan forward. It provides initial understandings of all the content areas of consideration involved in a migration.
During the actual migration, many sample tests will be run in the process to purge many of these technical details to the forefront as required.

If you have any other comments, add them in the following space please. 

  • No labels