Direct answer
A CRM data mapping document is a written map from every piece of data in the old system to a place in the new one, or to an explicit decision to drop it. Make it before the first import: inventory the sources, map field to field with types and transformations, map picklist values and pipeline stages, map users and owners, decide how associations and history come across, list what you will not migrate, and get a named person to sign it off. It sits between deciding to migrate and running a test import. For the go/no-go decision and what a migration covers, see CRM migration checklist; for after mapping, see CRM migration cutover checklist.
Step 1: inventory every source
The CRM is rarely the only place customer data lives. List each source in a table with an owner, and do it before you design anything:
- The current CRM, object by object: contacts, companies, deals, leads, tickets, products, custom objects
- Spreadsheets kept by individual reps or by finance
- Email marketing lists, form tools and any billing or support system that holds customer fields
- Attachments, files and notes, which may sit in the CRM, in a drive or in email
- For each source: rough record count, how it is exported (native export, API, manual), when it was last cleaned, and who can answer questions about it
Step 2: build the field-to-field map
This is the core table. One row per source field, with columns you agree on before starting:
- Source object and field name, with an example value copied from a real record
- Source type and target type. Text to number and text to date are where imports fail, so mark every type change
- Target object and field name, or 'DROP' with a reason
- Transformation rule: trim spaces, change case, split full name into first and last, normalise phone formats, convert date formats, combine two fields into one
- Required in target? If yes, what fills it when the source is empty
- Notes: known bad values, uniqueness expectations, and who decided
Check your platform's field limits and types
Field types, length limits and allowed characters differ between platforms. Look up the target's rules rather than assuming the source's structure will fit, and mark any mismatch in the map. Where behaviour varies, check your platform's documentation; we do not assume a particular importer's abilities here.
Step 3: map picklists and pipeline stages
Picklist values and stages are the most common silent failure, because an import can succeed while putting records into the wrong place. Build two extra tables. For each picklist field, list every source value, its count, and the target value it maps to. Include the oddballs: blanks, misspellings and values no longer in the list but present on old records. For pipelines, list every stage in the old system and the stage in the new one, and say what happens to deals in stages that have no equivalent. If your stages are changing as part of the migration, decide the new definitions first; CRM pipeline stage design covers that, and mixing the two decisions during import is how deals end up in the wrong stage.
Step 4: map users and owners
Ownership is a data field that carries meaning. List every user in the old system, the matching user in the new system, and what to do with records owned by people who have left. Options are a holding owner, a team owner, or a reassignment rule. Decide this up front because importing records against a user that does not exist in the target can fail or leave them ownerless, depending on the platform. Also map teams, territories or business units if you use them, and any permission-based visibility rules that depend on ownership.
Step 5: associations and history
Records are useful because of their links: a contact belongs to a company, a deal has a contact, an activity belongs to a deal. Write down the relationships that must survive, and how each will be matched: by a unique ID from the old system, by email, by company domain, or by name. Name matching is the weakest and should not be the default. Then decide how much history moves:
- Notes, calls, emails and meetings: migrate all, migrate recent only, or archive outside the CRM and link to it
- Attachments and files: where they will live after migration and how they stay linked
- Timestamps and original creation dates: check whether your target lets you keep them, since this varies by platform and method
- Closed and lost deals: keep for reporting history or archive; decide before the count is known, not after
- Activity sequences, tasks and open reminders: usually rebuilt, not migrated
Step 6: decide what to drop
Not everything deserves to move. Dropping is a decision, not an omission, so write it down. Candidates are unused custom fields (see CRM custom field cleanup), duplicate records (see merging duplicate CRM records), records that fail a minimum-data rule, long-dead deals, and test or junk records. For each category, note the rule, the approximate count and where the dropped data will be stored, such as an exported archive, in case someone needs it later. Do not claim a drop is safe until an owner has approved it.
Step 7: sign-off
Finish with a one-page approval, not a verbal nod. The person who owns sales, and the person who owns finance or customer data if they are different, review three things: the field map, the picklist and stage maps, and the drop list. They confirm in writing, with a date, and later changes go through a short change note. This is what stops an argument in week three of the project about why a field is missing. The estimate of effort that results from the map is easier to get from the free CRM migration complexity estimator, and the cost side is on CRM migration cost.
Next step
If the map exposes more complexity than you expected, such as many sources, unclear ownership or a large drop list, that is useful information rather than a problem. CRM Migration covers how LATYNEX approaches scoping and delivery. Larger migrations are scoped separately, and we do not promise that any importer will carry every field or history type across; the mapping document is where that gets settled honestly.
Questions
Do I need a special template for CRM data mapping?+
No. A spreadsheet with one row per source field and the columns described above is enough. What matters is that every field has a decision, including 'drop', and that a named person signs it off.
When should the mapping be done in the migration timeline?+
After the decision to migrate and before any test import. The map determines what the test import does, so building it afterwards means the first test runs on guesses.
What happens to fields that have no equivalent in the new CRM?+
There are three options: create a custom field in the target, fold the value into a note or description field, or drop it and archive the export. Each should be recorded in the map with a reason.
Can the new CRM's native importer handle the mapping for us?+
Importers differ between platforms, and we do not assume what yours supports. Treat the mapping document as your source of truth and check the importer's abilities and limits in the platform's own documentation before you rely on it.
Who should sign off the mapping?+
The person accountable for the sales process, plus whoever owns the customer or finance data if it is different. Signing means they reviewed the field, value and drop lists, not that they checked every record.