CRM migration mapping worksheet, written before you import.
The document most migrations skip: a row per source field, saying which record and which field it lands in, what type it becomes, what transform you are applying, what the value looked like before and after, and the rule that should stop a bad row. Copy it as CSV, fill it in against a real export, and only then let anything move.
The template, filled with an example
The example maps nine source fields out of a fictional spreadsheet export. The sample values are deliberately messy — stray spaces, a lower-case GSTIN, a date that could mean two things — because a clean sample would hide exactly the work the sheet is for.
Illustrative example only. “Sample Legacy Spreadsheet” and “Acme Textiles Pvt Ltd” are invented for this page, and the GSTIN strings are placeholders in a valid format — not real registrations. The 1,284-row figure is an illustrative number used to make the worksheet concrete, not a measurement of anything.
Header block
- Migration name
- Sample spreadsheet to customer records (example)
- Source system
- Sample Legacy Spreadsheet (example) — 'Contacts' sheet
- Destination
- Customer records: company, contact, lead
- Rows to migrate
- 1,284 rows in the source sheet (example figure)
- Prepared by
- Sample Data Owner (example)
- Reviewed by
- Sample Sales Manager (example)
- Mapping written on
- 02-10-2026
- First import dry run
- 08-10-2026 — into a copy, not the live system
Field mapping
| ID | Source field | Destination record | Destination field | Data type | Transform applied | Sample source value | Sample destination value | Validation rule |
|---|---|---|---|---|---|---|---|---|
| M1 | Company Name | Company | Name | Text | Trim, collapse double spaces, title-case only if the source is all lower case | acme textiles pvt ltd | Acme Textiles Pvt Ltd | Must not be empty. Block the row and report it if it is. |
| M2 | GST Number | Company | GSTIN | Text | Upper-case, strip spaces and punctuation. Leave blank rather than guessing | 29 abcde 1234 f1z5 | 29ABCDE1234F1Z5 | 15 characters, and the first two must be a state code we serve. Flag any row that is neither. |
| M3 | State | Company | Place of supply (state code) | List → code | Map every spelling variant in the source to one state code. Do not infer from the address | Bengaluru, Karnataka | 29 (Karnataka) | Every distinct value in the column must appear in the map. List the unmapped ones, do not default them. |
| M4 | Phone | Contact | Mobile | Text | Keep digits only, drop a leading 0, drop a leading 91. Never merge two rows to resolve a clash | +91 98765 43210 | 9876543210 | 10 digits. A number already on another record is a merge decision for a person, not for the import. |
| M5 | Contact | Text | Lower-case the domain only. Leave the local part exactly as the person wrote it | [email protected] | [email protected] | Must contain one @ and a dot in the domain. Duplicates across rows are reported, not silently dropped. | ||
| M6 | Status | Opportunity | Stage | List → stage | Map each source status to a stage in our own list. Every stage you use must be written down first | hot / won / closed-lost | Negotiation / Won / Lost | No source value may map to a stage that does not exist in our configuration. Unmapped rows are held back. |
| M7 | Follow Up Date | Opportunity | Next action date | Ambiguous date → ISO | Ambiguous: 03-04-2026 could be 3 April or 4 March. Hold the row for a person, never pick one | 03-04-2026 | Held back — needs a human decision | Refuse any date that is not unambiguous in the source. An invented date is worse than a missing one. |
| M8 | Owner | Opportunity | Owner | Text → user | Match on the email in the user list. Unmatched owners are assigned to a named default, not left blank | Priya (sales) | Held back — no user matches 'Priya (sales)' | Every owner must resolve to a real user or a named default. An unowned record is an unworked record. |
| M9 | Notes | Contact | Note | Free text | Carry across as a single note with the source filename and row number in its header | Prefers WhatsApp. Called 2x. | From Contacts sheet, row 41: Prefers WhatsApp. Called 2x. | No transformation. Provenance is added so the note can be traced back if it turns out to be wrong. |
Rows the example deliberately refuses to convert
| ID | Source field | Why it is held back |
|---|---|---|
| M7 | Follow Up Date | Refuse any date that is not unambiguous in the source. An invented date is worse than a missing one. |
| M8 | Owner | Every owner must resolve to a real user or a named default. An unowned record is an unworked record. |
2 of the 9 mapping rows in the example end in “held back — needs a human decision” rather than a converted value. That is the normal outcome of doing this properly, and a migration plan with no held-back rows is usually a plan that has not been looked at yet.
The GSTIN is mapped here as a field to be carried across, and nothing on this worksheet decides how it should be validated, when it is required, or what your obligations are. Confirm your own tax and invoicing requirements — and whether a given record should carry a GSTIN at all — with your chartered accountant.
Before the import
- Source fields seen in the file
- 14 distinct columns
- Source fields with a mapping row
- 9 of 14 — the other 5 are deliberately not migrated
- Fields deliberately left behind
- Two internal-only columns, one spreadsheet formula column, two duplicate columns
- Rows expected to be held back on the dry run
- Ambiguous dates, unmatched owners, and duplicate phone numbers
- Merge decisions needed from a person
- Same company arriving as both a lead and a contact
- Source of truth after the migration
- The new system. The spreadsheet is archived read-only, not kept in sync.
CRM migration field mapping worksheet (CSV — illustrative example data) Field,Value Migration name,Sample spreadsheet to customer records (example) Source system,Sample Legacy Spreadsheet (example) — 'Contacts' sheet Destination,"Customer records: company, contact, lead" Rows to migrate,"1,284 rows in the source sheet (example figure)" Prepared by,Sample Data Owner (example) Reviewed by,Sample Sales Manager (example) Mapping written on,02-10-2026 First import dry run,"08-10-2026 — into a copy, not the live system" ID,Source field,Destination record,Destination field,Data type,Transform applied,Sample source value,Sample destination value,Validation rule M1,Company Name,Company,Name,Text,"Trim, collapse double spaces, title-case only if the source is all lower case", acme textiles pvt ltd ,Acme Textiles Pvt Ltd,Must not be empty. Block the row and report it if it is. M2,GST Number,Company,GSTIN,Text,"Upper-case, strip spaces and punctuation. Leave blank rather than guessing",29 abcde 1234 f1z5,29ABCDE1234F1Z5,"15 characters, and the first two must be a state code we serve. Flag any row that is neither." M3,State,Company,Place of supply (state code),List → code,Map every spelling variant in the source to one state code. Do not infer from the address,"Bengaluru, Karnataka",29 (Karnataka),"Every distinct value in the column must appear in the map. List the unmapped ones, do not default them." M4,Phone,Contact,Mobile,Text,"Keep digits only, drop a leading 0, drop a leading 91. Never merge two rows to resolve a clash",+91 98765 43210,9876543210,"10 digits. A number already on another record is a merge decision for a person, not for the import." M5,Email,Contact,Email,Text,Lower-case the domain only. Leave the local part exactly as the person wrote it,[email protected],[email protected],"Must contain one @ and a dot in the domain. Duplicates across rows are reported, not silently dropped." M6,Status,Opportunity,Stage,List → stage,Map each source status to a stage in our own list. Every stage you use must be written down first,hot / won / closed-lost,Negotiation / Won / Lost,No source value may map to a stage that does not exist in our configuration. Unmapped rows are held back. M7,Follow Up Date,Opportunity,Next action date,Ambiguous date → ISO,"Ambiguous: 03-04-2026 could be 3 April or 4 March. Hold the row for a person, never pick one",03-04-2026,Held back — needs a human decision,Refuse any date that is not unambiguous in the source. An invented date is worse than a missing one. M8,Owner,Opportunity,Owner,Text → user,"Match on the email in the user list. Unmatched owners are assigned to a named default, not left blank",Priya (sales),Held back — no user matches 'Priya (sales)',Every owner must resolve to a real user or a named default. An unowned record is an unworked record. M9,Notes,Contact,Note,Free text,Carry across as a single note with the source filename and row number in its header,Prefers WhatsApp. Called 2x.,"From Contacts sheet, row 41: Prefers WhatsApp. Called 2x.",No transformation. Provenance is added so the note can be traced back if it turns out to be wrong. Review question,Answer Source fields seen in the file,14 distinct columns Source fields with a mapping row,9 of 14 — the other 5 are deliberately not migrated Fields deliberately left behind,"Two internal-only columns, one spreadsheet formula column, two duplicate columns" Rows expected to be held back on the dry run,"Ambiguous dates, unmatched owners, and duplicate phone numbers" Merge decisions needed from a person,Same company arriving as both a lead and a contact Source of truth after the migration,"The new system. The spreadsheet is archived read-only, not kept in sync."
The sheet is deliberately a worksheet and not an import tool: nothing here reads a file or writes a record. The companion tool CRM migration CSV builder is the step that checks rows and produces a cleaned CSV — it looks for missing fields, duplicate phone numbers and emails, unparseable and ambiguous dates, and inconsistent status spellings, and it exports with your own column mapping. This worksheet is the step before that one. It is where you decide what each column means and what should happen to a bad row, and doing that on paper is much cheaper than discovering the answer inside a thousand imported records.
How to fill it in
Five steps, in the order that avoids a migration you have to undo.
Export one file and look at what is actually in it
Start with a single export rather than the whole history, and list every distinct column header you find. The example finds fourteen and maps nine — the difference is deliberate, and knowing which five you are discarding is part of the work.
Decide the destination record before the destination field
A source column might belong to the company, the contact, or the opportunity. Deciding the record first stops one source field from quietly being written into two different places, which is the most common way a migrated file becomes confusing within a month.
Put a real value in the sample columns
Not a description of the value — the value, from the actual export. The example uses a messy string with stray spaces, a lower-case GSTIN, and an ambiguous date, because those are what a real export contains and they are what the transform has to survive.
Write down what you are not migrating, and why
The example lists two internal-only columns, a formula column, and two duplicates. A field with no reason for being dropped comes back three months later as an argument about whether it was in scope.
Run the dry run into a copy and read the held-back rows
Never into the live system. The example expects rows to be held back for ambiguous dates, unmatched owners, and duplicate phone numbers, and expects a person to decide every one of them before anything is migrated for real.
When to use this, and when to stop
This is a preparation document. It earns its place only if it is filled in before the import, with a real export in front of you.
When this template is the right tool
- Your customer, contact, and lead data currently lives in a spreadsheet and you are moving it into a system for the first time.
- You have decided which fields matter and want the reasoning written down before anyone writes an import script.
- You want to spot the columns that will not survive the move — ambiguous dates, inconsistent status spellings, duplicated phone numbers — while the source file is still authoritative.
- You are planning a migration and want the hard questions answered before an engineer quotes for it.
When you have outgrown it
- The spreadsheet is still being edited while the import runs, so there is no stable source to migrate from.
- Nobody has decided how a lead, a company, and a contact relate to each other, so rows cannot be assigned to the right record.
- The same company exists as three rows and the import is expected to resolve that automatically.
- The plan is to migrate, keep editing both, and reconcile the differences later.
The same process in NoxOrigin
NoxOrigin treats an import as scoped work rather than a self-serve promise, and the reason is the same one this worksheet exists for: most data damage is done by a conversion nobody reviewed. So the mapping is discussed before anything moves — what your current process actually does, how a company, a contact, and a lead relate to each other, and what your merge policy is. Duplicate handling matters more than people expect, because the same organisation often arrives as a new lead, a new company, and a contact with a slightly different name; deciding that during setup is much cheaper than discovering it three months later. Sales processes are configuration, not migration — you keep the stages you already use rather than adopting a vendor’s funnel. Nothing on this page implies a self-serve import; it is a worksheet you fill in before talking to anyone about the work.
- CRM migration CSV builderPaste your rows and it checks for missing fields, duplicate phones and emails, unparseable and ambiguous dates, and inconsistent status spellings, then exports a cleaned CSV with your own column mapping.
- Customers & CRM in NoxOriginCompanies, contacts, leads, and opportunities as records that outlive the enquiry — and the merge policy that belongs in this mapping sheet as a decision rather than a surprise.
- Lead management softwareThe destination this sheet is pointing at: customer records, ownership, pipelines, follow-ups, and next actions.
- Lead follow-up sheetThe sheet most migrations are trying to escape — a working structure for leads you can run before the data is anywhere else.
- Client onboarding checklistWhat has to be true on the client record once the data is in it, including GSTIN and billing contacts.
CRM migration mapping questions
Why write the mapping down before importing anything?
Because an import is fast and a mistake inside it is invisible. A thousand rows arrive looking perfectly plausible, and the error — a GSTIN column mapped to a phone field, a date read the wrong way round — is only discovered weeks later when somebody tries to use the data. The worksheet takes an hour and its output is a list of decisions you would otherwise make by accident, in bulk, unreviewed.
What belongs in the validation rule column?
The check that would make you stop and look at that row. “Must be 15 characters and start with a state code we serve” is a rule. “Check this field” is a wish. If you cannot write the rule, that is usually a sign the destination field is not yet properly defined, which is worth finding out before the import rather than after it.
How should I handle duplicate phone numbers and emails?
Report them and leave the decision to a person. The example says so on rows M4 and M5 explicitly. Merging two records automatically is how you end up with a customer whose history belongs to somebody else, and the error is very hard to unpick after a few months of work has been logged against the merged record.
What about dates that are ambiguous in the source?
Hold the row back. A date like 03-04-2026 is either 3 April or 4 March depending on where the sheet came from, and a migration script will confidently pick one of them. An invented date is worse than a missing one, because a missing one gets chased and an invented one gets invoiced.
What is this worksheet not?
It is not an import file, and nothing on this page converts your data. The companion tool linked below checks pasted rows for missing fields, duplicate phones and emails, unparseable dates, and inconsistent status spellings, and exports a cleaned CSV with your own column mapping. This sheet is the step before that one: it is where you decide what the columns mean.
Decide what the columns mean before anything moves.
Bring this sheet, filled in against a real export, and the conversation starts from your data rather than from a generic migration plan.