Guide · CRM & customer operations
A CRM Field-Mapping Worksheet That Catches Expensive Mistakes
Work through names, types, relationships, and empty values before importing customer data into a different CRM.
A column called "Customer" sounds straightforward until you discover it contains a person's name in one system and a company identifier in another. Field mapping needs to explain the meaning of the data, the shape the destination expects, and what to do when a value doesn't fit. Matching column headings gets you only part of the way.
Map a complete record first
Choose one representative customer with an open opportunity, a note, and whatever related information your team uses. Write down where each piece should appear after the import. This reveals relationships that disappear when you inspect each spreadsheet in isolation.
In a hypothetical agency CRM, the contact may be a person, the company may be the client account, and the opportunity may be a proposed project. Mapping all three to a single customer name loses distinctions that people need later. Establish those meanings before deciding how the columns should be transformed.
Make the worksheet explain your decisions
For each field, record the source name, a sample value, the destination field, and the transformation rule. Add an exception rule and a person responsible for unresolved cases. A blank cell in the worksheet should mean "not decided," not "probably obvious."
Take a source value of "09/10/26." Does it mean September 10 or October 9? Does it represent a date or a timestamp? Use the source system's documented format and inspect known examples. Once you understand it, write the conversion explicitly. Guessing based on your own locale can shift dates without producing an import error.
A picklist needs the same care. If the old system allows "Booked," "Scheduled," and "Appointment Set," decide whether those are synonyms in your business. They might represent different commitments. A mapping that reduces three labels to one is a business decision as well as a data transformation.
Handle missing values on purpose
An empty field can mean unknown, not applicable, or intentionally cleared. Decide which meaning applies before importing it. You may want to skip an empty phone field when updating an existing contact, but retain a deliberate request to remove an outdated number.
Ask how the importer treats missing columns compared with present columns containing empty values. Check the behavior on a test record. Don't assume an import that can create records will update existing ones in the same way, or that every field supports the same clearing behavior.
Also check lengths and number formats. A postal code is often better treated as text because leading zeros can matter. Phone numbers and money fields need their own rules. Keep raw values available so a reviewer can compare the transformation with the source.
Test relationships and exceptions together
Use a small sample containing an ordinary record, a missing value, an unusual value, and a relationship that must survive. Confirm the resulting record in the destination interface. A successful import log doesn't tell you whether a salesperson can find the right company from the contact page.
When a field fails, update the worksheet with what you learned. Avoid changing the export repeatedly without changing the documented rule. By the time you're ready for the larger import, a teammate should be able to read the worksheet and explain what will happen to each important field, including the cases you're choosing to leave for manual review.