Data migration to BlueSpice MediaWiki

So data migration is not quite that simple?

As is so often the case, it is all a question of planning. Migration projects are concerned with structural migration on the one hand. This is the more complex part, because different software systems usually have different storage logics. In addition, one speaks of content migration. This is the conversion of content from the source format to the target format “WikiText”. Only in this way can the content be optimally mapped and formatted in the Wiki.

Further information about the format WikiText can be found here:

https://de.wikipedia.org/wiki/Wikitext
https://www.mediawiki.org/wiki/Wikitext/de

Why is data migrated at all? What is behind it?

The trigger for a migration project in our company is usually the shutdown of an existing software and the customer’s change to BlueSpice MediaWiki. Migration projects make sense when a large number of contents or documents need to be transferred to BlueSpice MediaWiki. If this is the case, the effort of manual data transfer into the new system would be considerable. In this case we suggest a migration project to the customer.

Because migration projects involve programming effort on our part, the profitability of such a project is clarified in advance. Since data stocks can also be transferred manually as an alternative, the basic rule is that the migration project must be more cost-effective for the customer than manual data transfer. The cost-benefit ratio must be right. If this is the case, depending on the size of the migration project, considerable time and thus cost savings are achieved for the customer.

What exactly is migrated in a migration project?

On the one hand, this involves content from editorial or CMS systems such as WordPress, Lotus Notes or Typo3. Often the customer’s content is also available in the classic document format, e.g. in Word or PDF format. If the customer wishes to transfer the content from an existing wiki system such as MediaWiki, Confluence or TWiki, this is also no problem. Almost anything is possible.

What should you pay particular attention to when migrating data?

The homogeneity of the customer’s data source is important. This means that the documents or contents should be prepared according to the same logic. If they are not, our automatisms or scripts do not work and many small things have to be maintained manually. So you can say: The more heterogeneous the data is, the more complex a migration becomes. Therefore, for some customers it makes sense to use a migration script to import those parts of the data stock that are homogeneous in themselves and to manually maintain other contents. This is always very customer-specific.

And how exactly does a migration project work for us?

We have a tried and tested process that has already proven itself in many migration projects. First of all, a feasibility analysis is carried out to determine whether a migration of the existing data stock makes any sense from a technical point of view (keyword: structural migration and data homogeneity).

If the feasibility is given, the detail will be determined in a specification workshop (via screen sharing or on-site at the customer’s premises). These include renaming documents and files, cleaning up outdated data, assigning content to wiki categories, namespaces (areas delimited by access rights), pages, sub-pages or wiki instances. The whole thing is an iterative process with several feedback rounds. Once this “homework” is done, a multi-stage shutdown or handover process follows with the goal of minimizing the time in which the documents cannot be edited by the customer. The final step is the activation of BlueSpice and the shutdown of the old system. And a satisfied customer, who can now manage his content easily and comfortably in his company wiki: BlueSpice MediaWiki.

Let’s Wiki together!