Describe the meaning of source fields
Record the original name, an appropriate example and its business meaning. A status column might describe progress, payment information or an active client relationship. Its name alone cannot identify the destination field.
Include empty values and allowed variants. Does a blank date mean unknown, not yet planned or not applicable? Where these distinctions matter, the move should not quietly collapse them into one default value.
Define destinations and conversions
Assign each required source field to a destination or deliberately mark it as excluded, recording why. An unsupported field may need another representation but should not simply disappear without discussion.
Express conversions as clear rules. Splitting first and last names at the first space does not work for every name. Examine the actual cases and choose manual clarification where needed rather than applying a superficially simple rule everywhere.
Formats and units matter for numbers and dates. An identifier with leading zeros may be text rather than a number. Hours should not become minutes without conversion. Flag such fields for particular attention during testing.
Preserve relationships
If tasks belong to projects, the destination needs a traceable connection. Retain original identifiers in a mapping while comparison requires them. Two projects with the same name cannot reliably be distinguished by title alone.
Consider the order in which record types must be imported. A dependent record may need an existing reference. The actual sequence follows the destination system and should be confirmed in a small test.
A status field needs a translation rule
Suppose the old file uses “open”, “in progress” and “done”, while the new tool distinguishes “new”, “assigned”, “waiting” and “closed”. Renaming “in progress” is insufficient: some items are waiting for a customer and others are being handled by the team. Record which additional field determines the mapping. If that information is missing, collect those rows for manual review instead of guessing a status.
Check how empty fields behave as well. An empty value may mean “not yet decided” in the original system but automatically create an active item in the destination. Document that difference in the mapping sheet. An explicitly assigned fallback category is easier to review than an unnoticed default value.
Keep the original identifier in a separate column during the trial import. If a row is challenged, that identifier lets you find the source record and correct the rule. Decide whether the extra identifier remains useful in everyday operation only after the mapping has been checked.
Choose a deliberately difficult sample
Include an ordinary record, one with missing information and one with several relationships. Add special characters and unusually long content. Inspect any available import preview. With text files, delimiters and interpretation of columns can affect the result.
After importing, compare meaning as well as appearance. A plausible date can still refer to the wrong event. Ask somebody responsible for the work to follow several complete cases.
Save the agreed mapping with a version date. When a rule changes, repeat the affected test. This preserves an explanation of which decision produced the final data state.
