How to Map Fields Between an Old CRM and a New One

CRM field mapping is the step that separates migrations that go smoothly from the ones that haunt a team for months. You can choose the right new platform, negotiate a fair contract, and still land with a contact database full of mismatched data, broken picklists, and salespeople who can no longer trust what they see on screen. Getting the mapping right before you move a single record is not optional — it is the whole job.

What CRM Field Mapping Actually Means

At its most basic, CRM field mapping is the process of matching each data field in your source system to the correct field in your destination system. "First Name" in the old CRM goes to "First Name" in the new one. Simple enough. The complexity starts when fields do not match one-to-one: when the old system stored the entire mailing address as a single text blob, and the new one expects five separate fields. Or when a dropdown in the old system had 47 options, and the new one only allows 10.

Think of it as translation — not of language, but of structure. Every piece of data has a home in the source. Your job is to find its equivalent home in the target, or to build one if it does not exist.

Why This Step Is Where Migrations Break Down

Most migration failures are not technical failures. They are planning failures. A team exports a CSV, looks at it briefly, uploads it to the new platform, and then discovers six weeks later that every deal stage was imported as a free-text note instead of a structured pipeline field. That kind of damage is expensive to reverse.

The crm migration mapping phase is also where political tensions surface. Sales wants all their custom fields preserved. Marketing has a different definition of "Lead Source" than Sales does. Customer success uses a field called "Account Health" that does not exist in the new system at all. These conflicts exist in the source data long before the migration begins — the mapping process just makes them visible.

Step 1: Audit Every Field in the Source System

Before you touch the target platform, export a complete schema from your current CRM. Most systems let you do this through an admin settings panel or a developer API. What you want is a list of every object type (Contact, Company, Deal, Ticket) with every field name, field type, and whether the field contains data.

That last point matters more than people expect. A lot of CRM databases carry dozens of fields that were created years ago, used briefly, and then forgotten. Before you map them to the new system, ask: does this field have data in at least 5% of records? If the answer is no, consider whether it belongs in the migration at all. Dragging dead fields into a new system just adds noise.

Create a spreadsheet — a crm data mapping template — with one row per source field. Columns should include: object type, field name, field type (text, number, date, picklist, multi-select, boolean), percentage of records with a value, and a notes column for anything unusual.

Step 2: Audit the Target System

Do the same for the destination CRM. Pull a schema of every available field, including any custom fields you have already created in the new system during the trial or setup phase. Note which fields are required, which have validation rules, and which are locked to a specific data type.

This dual-audit approach is the foundation of clean CRM field mapping. Without it, you are working blind.

Step 3: Build the Mapping Document

Now you match source fields to target fields, row by row. This is slower than it sounds. For straightforward fields — names, emails, phone numbers — the matches are obvious. The difficulty lives in four categories:

• Missing fields in the target. The new CRM does not have an equivalent for something in the old one. Decision: create a custom field, fold the data into a notes field, or drop it entirely.
• Type mismatches. A number field in the source, a text field in the target. Dates stored in different formats. Booleans stored as "Yes/No" text instead of true/false.
• Picklist and multi-select conversions. This deserves its own section, covered below.
• Free-text fields being migrated to structured fields. Also covered below.

The mapping document itself should show source object, source field name, source field type, target object, target field name, target field type, and a transformation note. That transformation note is where you record what has to happen to the data before it can land in the new field.

The Contact Field Translation Table: A Worked Example

Here is a simplified example of what a crm data mapping template looks like in practice for the Contact object:

This is a real pattern. Notice that almost every row has something in the transformation column. Clean, zero-transformation migrations are rare in practice.

Handling Picklist Consolidations

When a source-target field mapping involves a picklist with more options in the source than the target allows, you have three choices: expand the target picklist to match, consolidate options into logical groups, or drop values that are rare.

Start with frequency analysis. If 92% of records in the "Lead Source" field use five values, and the remaining 8% are spread across another eleven values, the case for consolidation is strong. Group the tail values into an "Other" bucket and document what got merged — your team will ask.

Multi-select to single-select conversions are trickier. The source might have a contact tagged as interested in three products. The target only accepts one. There is no universally correct answer here. Taking the first-selected value is pragmatic. Taking the most recent selection requires your source system to have timestamp data on individual selections. Logging all values to a notes or tag field so nothing is lost is often the safest path — you can always refine the data later once the new system is live.

Migrating Free-Text Fields to Structured Ones

Free-text to dropdown migration is, bluntly, one of the harder problems in CRM field mapping. People type inconsistently. "New York", "NYC", "new york", "N.Y." — all the same city, all four different strings. Before you can map free-text to a structured picklist, you need to normalize it.

The practical approach: export the distinct values from the free-text field, run a frequency count, then write a normalization map. High-frequency values get mapped directly. Rare or malformed values get reviewed manually or placed in a staging area — a "parking lot" object or set of custom fields — where they can be cleaned post-migration without blocking the go-live.

Do not attempt to automate your way through normalization entirely. A script can catch obvious variations, but human review is needed for the long tail.

The Orphaned Data Problem (and How to Park It)

Not everything maps. Some source fields have no logical home in the target, and some data is too dirty to transform in time for the migration window. The wrong move is to silently drop this data. The right move is to park it.

A parking lot in the context of crm migration mapping is a designated custom object, a set of catch-all custom fields, or an external spreadsheet that holds unmapped data in a structured, retrievable format. Label each parking lot field clearly: "Migrated from: [source field name]". Set a review date — typically 60-90 days post-migration — and assign an owner.

This approach keeps your go-live clean while ensuring nothing is permanently lost. Explore the /crm-tools section if you want a rundown of platforms that support custom object creation for exactly this kind of staging.

Testing Your Field Mapping Before Full Migration

Run a pilot migration with a small, representative sample — 200 to 500 records across different contact types, deal stages, and account sizes. Then review the results field by field. Look for truncated values (a text field in the target is shorter than the source), misclassified picklist values, and records where the transformation produced a blank instead of a fallback.

Fix your transformation scripts and mapping rules based on what the pilot surfaces. Then run a second pilot. Most teams skip the second pilot. Most teams also report data quality problems in the first 30 days post-migration.

After the Migration: Validating the Outcome

Once the full migration runs, validation is not optional. Pull record counts for each object and compare source to target. Check that required fields are populated. Sample 1-2% of records manually and compare them against the source. If your CRM supports it, run a duplicate detection sweep — migrations occasionally create duplicate contacts when email addresses are malformed or missing.

What does this mean for your sales team day-to-day? Mostly, it means they should be involved early. A sales manager who reviews the mapping document and spots that "Deal Stage" was mapped to the wrong equivalent in the new system is far more valuable than a post-migration ticket six weeks later. Involve the people who use the data in the design of the map. They know the quirks.

Good CRM field mapping is methodical, collaborative, and unglamorous. It is also the work that determines whether your new platform becomes a genuine improvement or just an expensive replacement for the same mess you had before.