Mapping
The mapping phase is a logical continuation of the inventory phase. During the inventory the content and the content structure of the current situation are documented; during the mapping phase the actual situation is placed next to the new situation. What are the matches, what are the differences and how are we going to handle these differences?
As a prerequisite to the mapping phase the new content structure must be decided upon. This means in practice that the templates for the new CMS are determined in a technical design or the development has already started.
Mapping the content types
This phase can be divided in mapping on the content type level and on the field level. When mapping on content type attention must be paid to the following:
- Will a content type be migrated 1 on 1?
For instance content type A goes to content type A
- Will several content types be combined?
For instance content type A and content type B merge into content type C.
- Will any content types be disposed of?
When it is decided that content type A will not exist in the new CMS.
- A part of the items from a content type will be migrated.
A mapping rule is created that determines which content is migrated, for example only content newer than 1999 will be migrated.
Fieldmapping
One level down from the content types are the fields they contain. These also must be analysed. For each field in the current content types it must be decided to what field in the new CMS each will be migrated. This is an intensive step but it pays off during the migration path and the project itself. On the field level the following details will be reviewed:
- Will a field be migrated 1 on 1?
For instance field A goes to field A. Per field the format and the list of possible values of the current and the new situation must be compared. A publication date can for instance in the current system be recorded in a different format than in the new CMS.
- Will several fields be merged or alternatively be split?
Often the current CMS contains a block of text that must be split in separate paragraphs in the new CMS or the other way around. While mapping, decisions must be made which rules must be applied to splitting or merging.
- Will a field be disposed of?
When it is decided that a field will be disposed of in the new situation, this must be recorded in the mapping rules.
- The new CMS contains a field that is not available in the current CMS.
It is possible that the new CMS contains fields that are not available in the old CMS. For required fields a mapping rule, or default value set, must be created concerning the handling of this situation.
Retaining links
One of the most important subjects of a migration is retaining the functionality of internal links. In the mapping a strategy must be developed to retain the links and relations post-migration. During the migration the links and content items must be registered and in the new CMS the items must be converted to relative URLs, or joined based on the IDs of the relevant CMS.
End result
The end result is a document showing the content types, and two columns listing the fields of the current and new situations and a list with mapping rules. This will be the input for the following phases where the content will be cleaned up, enriched with metadata and migrated. This document is often useful in other areas of the project as well.
Mapping as a control instrument
Often during the mapping phase it becomes apparent that discarded fields from the old CMS are in fact required for the new CMS, and that there may be no capacity in the CMS for some of the new content types. While creating the mapping these issues come to light early, and not during the actual migration. This advocates an early start of the mapping, right after finishing the technical design and before the creation of the first templates.
