The data mapping document will be an integral piece to the success of your data migration or integration. It’s with the data mapping document that you are able to mitigate your risk factors.
The data mapping process will determine what data needs to be transferred over to the new system. This includes:
- Which entities (a.k.a. tables) will be moved over along with the specific fields.
- The format of the data after it is transferred.
- The frequency of the transfer (for integrations).
- What will trigger the transfer (manual or automatic).
In order to figure out how the data needs to be formatted, or mapped, it is essential to build a data mapping document. The data mapping document must include specifically the source and target data mappings. It must also include the primary key of all tables in source system. The following is an example of data mapping document.
Below is an example of mapping a field named E-mail to a field named E-mail. You’ll see that in this particular example, they are the same name in both systems, but this is not always the case. When mapping fields, even though the Label is useful, the Field (which is the schema name) is required. This will be the unique name for the field, while the Label (often times referred to as the display name) may not be unique. The type is also required (number, text, etc.), and when dealing with the type of a picklist the list values are also required (ex. yes, no, maybe).
The more specific this document is, the easier it will be to perform both the migration and integration. Examples of transformations include:
- Telephone format: format all telephone numbers to the destination system using the format (xxx) xxx – xxxx
- A text field in the current system needs to be moved to a date format of ##/##/####
- Two entities should be combined into one based off of the Contact on those entities
Next up, we’ll discuss creating the migration integration scripts.