Migrating CRMs Without Losing Client Data: Field Mapping & Export/Import

This guide is the mechanics: how to structure an export, map fields between an old CRM and a new one, handle the custom fields, tags, and pipeline stages that never line up 1:1, and validate that an import actually landed the way you expect. It doesn't cover the mistakes and planning judgment calls around a migration — timing, client communication, deliverability, piloting — that's a separate topic, and we've already written it up: for common mistakes to avoid during this process, see Common Mistakes When Migrating Clients to a New CRM. This guide picks up where that one leaves off — the actual how-to.

Before you export: inventory what exists

Before you touch an export button, get a clear list of what's actually in the old system. At minimum:

• Every custom field in use, not just the default ones (name, email, phone) — check the field list in your old CRM's settings, not just what shows up on a typical contact record, since fields with no data on the record you happen to be looking at can still exist and matter for others.
• Every tag currently applied to any contact, and roughly what each one is used for.
• Every pipeline and every stage within each pipeline, exactly as labeled.
• Whether notes, activity history, attachments, and tasks are things you need to bring over, or things you're comfortable archiving separately and leaving behind (see the note on automations below).

Automations, workflows, and any logic tied to the old platform generally can't be exported at all — they're rebuilt from scratch in the new system, which is a real project on its own and outside the scope of this guide.

Step 1: Structure the export

• Export one object type at a time — contacts, companies, and deals/opportunities as separate files — rather than one blended dump. It's easier to map and validate each type on its own.
• Include every custom field as its own column, not just the default fields. If your old CRM's export tool lets you choose which fields to include, err toward including too many rather than too few — it's much easier to ignore an extra column later than to re-export because something was left out.
• Export tags as their own column. Many CRMs export tags as a single comma-separated list within one column rather than one column per tag — know which format you're getting before you try to map it.
• Export pipeline and stage as their own columns, using the exact labels from the old system, not a paraphrase.
• Keep an unedited master copy of the raw export before you touch anything. Every cleanup or reformatting pass should happen on a copy, so you can always get back to the original if a step goes wrong.

Step 2: Map fields between the old and new schema

This is the step that gets rushed and causes most of the actual data problems. Build a simple two-column mapping sheet — old field name, new field name — before you import anything, and work through it deliberately by category:

• Default fields (name, email, phone, address) usually map directly, but check formatting, not just field names. Phone numbers, dates, and addresses are often stored in different formats between systems (with or without country codes, different date orderings), and a mismatched format can cause a field to import blank, truncated, or garbled rather than throwing an obvious error.
• Custom fields rarely map one-to-one. For each one, make an explicit decision rather than defaulting to "skip it": create a matching custom field in the new CRM before you import, fold it into an existing field that serves the same purpose, or consciously decide it's no longer useful and leave it out. The point is that every custom field gets a decision, not that every one has to survive the move.
• Tags need a structural decision, not just a rename. Decide whether tags in the old system should become actual tags in the new one, or whether some of them are really standing in for a field value (a tag like "vip-client" might be better represented as a custom field with a yes/no value in a system that supports that more cleanly).
• Pipeline stages almost never match name-for-name. Decide on your new pipeline structure first — ideally before migration day, not while you're mid-import — then build an explicit stage-to-stage mapping table. For any old stage with no obvious equivalent in the new pipeline, make a deliberate call about where those records land instead of letting the import tool guess.

Step 3: Test the mapping on a small batch first

Don't run your full export through the mapping on the first attempt. Import a small batch — enough records to cover every tag, every pipeline stage, and every custom field you're bringing over, even if that's only a few dozen contacts — and check the results before touching the rest of the file. Confirm custom field values, tags, and pipeline stage all landed in the right place, fix whatever's wrong in your mapping sheet, and only then move to the full import.

Step 4: Run the full import

• Import object types in an order that respects any dependency between them — companies before the contacts linked to them, for example, if the new system needs the parent record to exist first.
• If the platform has a file size or row limit on imports, split the full export into batches sized to fit rather than hitting an error partway through a large file. Check your specific platform's current limits before you plan batch sizes, since these change between vendors and over time.

Step 5: Validate that the import actually landed correctly

A completed import isn't the same as a correct one. Before you consider the migration done:

• Spot-check individual records, field by field, against the original export — not just a total record count. Pick a handful of records that each cover a different tag and pipeline stage combination, and compare every field, not just the ones you expect to have worked.
• Confirm the record counts match between the export and the import, accounting for any intentional deduplication.
• Check custom field values, not just field presence. A field showing up as a column in the new system doesn't confirm the values inside it are correct — verify actual data, especially for anything that went through a format change.
• Confirm tags and pipeline stages landed on the right records. This is the single most common place small migration errors hide, since a wrong mapping here doesn't usually throw an error — it just quietly puts records in the wrong bucket.
• Look for silently truncated or dropped data, particularly in long text fields (notes, descriptions) and anything with special characters — these are common places for an import to cut off content without flagging it as an error.

Keeping two systems in sync during a transition

If clients or team members need to keep working in the old system for a stretch while you finish validating the new one, you may need the two systems to stay roughly in sync rather than doing one hard cutover. Zapier can push new records or updates between two systems during a transition period without needing to be a permanent part of your stack. Some newer tools like Whalesync also handle this kind of two-way sync, though it's a newer, less established option than the more common connector tools — worth a look if your case is a good fit, but not something we'd put ahead of tools with a longer track record without your own testing.

If GoHighLevel is the platform you're migrating into, it's worth reviewing its default field set and pipeline structure before you finalize your mapping sheet, since building the mapping around what the destination system actually expects saves a round of rework after the fact.

None of these steps are exotic — they're the same export, map, test, import, validate sequence regardless of which two systems are involved. The failure mode to avoid is skipping the mapping and validation steps because the import itself "completed successfully" — a successful import and a correct one are not the same thing, and the difference usually doesn't surface until a client asks about a record that's missing or wrong.