The migration playbook: moving off a legacy CRM without losing a record

Migrations off legacy CRMs fail the same way every time. Someone exports a CSV, someone else imports it into the new system, the founder flips the switch at 5pm on a Friday, and by Monday morning the sales team is rebuilding workflows from memory while invoices are getting sent to deleted contacts.

This isn’t because CRM migrations are mysterious. It’s because they’re three problems pretending to be one. This post is the playbook we’d recommend teams run. None of it is Conduyt-specific — if you end up picking a different CRM, this still applies.

Why CRM Migrations Go Wrong

A CRM migration is not just moving contacts from one database to another. A legacy CRM often contains years of customer records, sales activity, notes, tasks, custom fields, pipeline stages, automations, integrations, reporting logic, and business rules.

When teams treat CRM migration like a simple export and import, records may technically move, but the business context gets lost.

Common CRM migration problems include:

• Duplicate contacts and companies
• Missing notes or activity history
• Broken field mapping
• Lost ownership assignments
• Incorrect pipeline stages
• Disconnected CRM integrations
• Workflow automation that no longer triggers correctly
• Reports that no longer match the old CRM
• Customer records without clear status or next steps
• Teams losing trust in the new CRM database

The goal of a CRM migration is not only to move records. The goal is to preserve the information your sales, marketing, support, and operations teams need to keep working without disruption.

1. The three-problem framing

A CRM migration looks like “moving data from system A to system B.” It isn’t. It’s three independent problems:

1. Schema mapping — figuring out how Contacts in A correspond to Contacts in B, where each custom field goes, what the status taxonomy looks like on the other side.
2. Data migration — actually moving the rows. Relatively mechanical once schema is settled.
3. Workflow reconstruction — rebuilding every automation, integration, report, and dashboard your team relied on. This is 60% of the effort and usually gets 10% of the planning.

Treating these as one project produces surprises. Budget for them separately, staff them separately, ship them in order. Schema first, data second, workflows last — and workflows can be iterative while the team is already live on the new system.

2. Before you export: the inventory

Before anyone touches an export button, write down what you actually have. Every legacy CRM accumulates junk — dead custom fields from a 2019 campaign, user accounts for people who left, test records from the initial setup.

The inventory you need:

• Contact count by owner. Contacts with no owner, contacts with owners who’ve left the company, contacts with duplicate email addresses. These are three different data-hygiene problems you don’t want to import.
• Pipeline and stage list, with counts. Pipelines that haven’t had a new deal in 6+ months are candidates to archive, not migrate. Stages that contain 80% of deals are candidates to split.
• Custom field list. Every custom field, what type it is, what percent of records actually have a value for it, and which of your team members uses it. Be ruthless — migrations are a clean-slate opportunity.
• Active automations. Every workflow that’s currently firing, with last-fire timestamps. Anything that hasn’t fired in 3 months is a candidate to retire.
• Integration endpoints. Every webhook, every Zapier zap, every API client. This is the list you’ll rebuild against in step 8.

Two to three days for inventory. It pays for itself immediately in reduced migration scope.

CRM Migration Checklist: What to Protect Before You Move

Before migrating off a legacy CRM, create a clear inventory of what needs to move, what needs to be cleaned, and what can be archived.

Use this checklist before any CRM data migration:

1. Customer records

Identify all contacts, companies, accounts, deals, opportunities, leads, and related customer records. Make sure each record has a clear unique identifier so it can be matched correctly in the new CRM.

2. Activity history

Preserve notes, calls, emails, SMS messages, meetings, tasks, status changes, and timeline activity whenever possible. Activity history is often what gives the CRM record its real business value.

3. Custom fields

List every custom field in the legacy CRM. Decide whether each field should be migrated, renamed, merged, archived, or replaced with a cleaner data structure.

4. Pipeline stages and statuses

Map old pipeline stages, lead statuses, deal statuses, and customer lifecycle stages to the new CRM. Do not assume the new CRM uses the same definitions.

5. Ownership and permissions

Confirm which users own which records, who can access sensitive data, and how manager visibility should work after the migration.

6. CRM integrations

Document every system connected to the old CRM, including forms, calendars, dialers, email tools, SMS platforms, payment systems, reporting tools, AI agents, Zapier, n8n, webhooks, and custom API integrations.

7. Workflow automation

Review every automation before turning it back on. A status change, duplicate field, or mismapped trigger can cause the wrong emails, tasks, messages, or alerts to fire.

8. Reports and dashboards

Identify the CRM dashboard views and reports your team relies on. After migration, compare the new reports against the old CRM before declaring the migration complete.

3. Schema mapping: the spreadsheet that saves your project

Open a spreadsheet. Columns: Source object, Source field, Source type, Target object, Target field, Target type, Transform, Notes.

Fill in every row. Every custom field, every system field, every relationship. This is boring. Do it anyway — the spreadsheet is what your migration script will execute against, and it’s what you reference six months later when someone asks “why is this field named this way?”

Common transforms that look innocent and aren’t:

• Enum values — “Qualified” in system A might be “Marketing Qualified Lead” in system B. Your transform column needs the exact mapping.
• Phone numbers — formats vary. Normalize to E.164 before you import.
• Timestamps — pay attention to timezones. CRMs store in UTC but display local; a careless import puts your western customers’ last-contact-date a day off.
• Owner references — if user accounts don’t exist yet in the target system, decide whether to import owner-less records (re-assignable later) or to provision all users first.

The mapping spreadsheet takes a week if you’re methodical. Skipping it takes a month of debugging.

Field Mapping Is the Heart of CRM Data Migration

Field mapping is where many CRM migrations succeed or fail. It defines where each piece of legacy CRM data will live in the new CRM database.

A strong field mapping process should answer:

• What is the field called in the old CRM?
• What is the field called in the new CRM?
• What type of data does the field store?
• Is the field required?
• Is the field still useful?
• Are there duplicate fields with similar meanings?
• Does the field affect workflow automation?
• Does the field appear in CRM dashboard reporting?
• Does the field connect to a CRM integration or API workflow?
• Should the field be migrated, cleaned, merged, or archived?

For example, a legacy CRM may have several fields that all describe lead source, such as “Original Source,” “Lead Source,” “Marketing Source,” and “Campaign.” If those fields are moved without cleanup, the new CRM may inherit the same reporting problems.

Good CRM migration is not copying old confusion into a new system. It is using the migration as a chance to create cleaner data, clearer workflows, and better reporting.

4. Custom fields will hurt

Reserve the most time for custom fields. They look simple in the spreadsheet — Text maps to Text, right? — but they carry the most business logic and the most edge cases.

Three patterns that burn migrations:

• Semi-structured fields. A “Notes” text field that, over the years, your team started using in a specific format — Contract value: $X | Renewal: date | Owner note: .... The target system probably has dedicated fields for two of those, and your migration should parse them out. Don’t import the raw text and assume you’ll clean it later.
• Multi-select fields. Legacy systems implement these differently. Some store them as comma-separated strings in one column; others as relations. The target system will also have its own approach. Confirm how each side serializes before you export.
• Dropdown fields with orphaned values. At least one of your dropdown fields has a value that exists on records but isn’t in the current dropdown configuration — because someone deleted it without cleaning up the old records. Decide now: recreate the value in the target, remap to an active value, or null it.

Assume two full days of work just for the custom-field pass.

5. Shadow writes and parallel run

Before you cut over, run both systems in parallel for at least two weeks. The cost is real — someone has to maintain both — but the cost of cutting over without a parallel period is worse.

Two shapes of parallel run, depending on your appetite:

• Shadow writes (one-way). New records go into the new system automatically; someone manually mirrors into the legacy system for a while. Cleaner data on the new side, higher manual cost.
• Dual writes (bi-directional sync). Events in either system propagate to the other via a sync process. Lower manual cost, higher engineering cost — and the bi-directional case has subtle conflict-resolution problems you’ll hit.

For most teams, one-way shadow writes plus a bi-directional sync on just the Contact object is the sweet spot. You get the “no lost records” property for the highest-stakes object, without the full complexity of dual-write for everything.

Use the parallel period to:

• Validate that your schema mapping handles real-world data, not just test records.
• Let the sales team click around the new system without pressure to commit to it.
• Run your automations in the new system with production data to catch edge cases.

End the parallel period when everyone can answer “which system do I check?” the same way for a given question. If the answer is still “it depends,” you’re not ready.

6. Validation in three passes

Don’t validate by eyeballing. Do it in three structured passes:

Pass 1 — Count validation. For every object, row count on source should equal row count on target. If it doesn’t, you have a structural bug (filter misconfigured, relationship dropped, etc.). Do not proceed to pass 2 until counts match.

-- Count validation SQL - run on both sides, compare
SELECT
  'contacts' AS object, COUNT(*) AS row_count FROM contacts
UNION ALL
SELECT 'deals', COUNT(*) FROM deals
UNION ALL
SELECT 'companies', COUNT(*) FROM companies
UNION ALL
SELECT 'activities', COUNT(*) FROM activities;

Pass 2 — Sample validation. Randomly pick 50 records of each object. For each, compare side by side. If any of the 50 diverge, expand the sample or diff at field level to find the pattern.

Pass 3 — Field-level diff for high-stakes records. Every record of strategic value — your largest accounts, your top-of-pipeline opportunities, your named customers — gets diffed field-by-field. This catches the custom-field mapping bugs that slip through count + sample.

A migration script that passes all three passes on a sample probably isn’t broken. A script that passes count but fails sample has a data-shape bug. A script that passes sample but fails field-level for big accounts has a mapping bug for a rarely-set field.

7. Workflows and automations

This is the part teams underestimate. You rebuild every automation from scratch on the new system — there’s no automated way to translate, say, a GHL trigger into a Conduyt workflow. The triggers, conditions, and actions don’t map 1:1.

Structure the rebuild:

• Start with the highest-volume automations. If your lead-capture → auto-response workflow fires 500 times a day, rebuild that first and run it in the parallel period. Side-by-side, you’ll see divergences within a week.
• Don’t rebuild everything. The inventory step surfaced the automations that haven’t fired in 3 months. Ask whether they need to exist at all. Migration is the cheapest moment to delete.
• Version what you build. Every new automation should include a note on what it replaces: "Replaces legacy: GHL workflow 42 'Lead Intake'". Makes debugging weeks later much easier.

A rough scaling rule: if you had 20 active automations on the legacy system, assume you’ll end up with 12 on the new one after the cleanup. The 8 missing are drift.

8. Integrations: cut deliberately, not all at once

Integrations are the most dangerous part of a cutover because they’re mostly invisible. Something stops firing, you don’t notice until the monthly report is wrong.

Do not move all integrations at once. Do this instead:

1. Inventory them (from step 2).
2. Classify each by criticality: lead-capture (high), internal Slack pings (medium), reporting dashboards (low).
3. Cut over one at a time, starting from lowest criticality. That way if something breaks, the impact is a stale dashboard, not lost leads.
4. Monitor each for 48 hours after cut. Then move the next one.

If the integration owner isn’t on your team — a Zap that your CMO built, say — include them in the cutover conversation. They need to know what broke and where the new endpoint lives.

9. The cutover day

Cutover is the easy part if the prior steps went well. A short playbook for the day itself:

• Freeze the legacy system first. Switch it to read-only, or revoke write API keys, or just announce a hard cutoff time and trust the team. Do not leave it writable “just in case” — that’s how you end up with two divergent sources of truth.
• Run a final delta sync. Anything that’s been written to the legacy system in the last 24 hours since your parallel-period sync gets one more pass.
• Run validation pass 1 (count) one more time. If it passes, you’re in good shape.
• Notify the team. Post a Slack message with: the new URL, where to find legacy data if they need to reference it (read-only portal), the list of known-not-yet-migrated automations, and who to escalate to if they find something broken.
• Archive, don’t delete, the legacy system. Keep read-only access for 60 days minimum. You will need to look something up.

Do not treat cutover as “project over.” The first week on the new system is when you find the last 5% of migration issues that didn’t surface during parallel run.

Post-Migration QA: What to Check Before Go-Live

Before fully switching to the new CRM, run a post-migration QA review.

Check the following:

• Did all expected contacts, companies, leads, and deals migrate?
• Are record counts close to the legacy CRM?
• Are notes, tasks, calls, emails, and activity history attached to the right records?
• Are pipeline stages and statuses mapped correctly?
• Are duplicate records under control?
• Are owners and permissions correct?
• Do CRM dashboard reports match expected numbers?
• Are integrations connected and tested?
• Are webhook and API workflows working correctly?
• Are automations paused until validation is complete?
• Can users find the records they need?
• Is there a rollback plan if something important is wrong?

Do not turn on every automation immediately after migration. Validate the data first, then activate workflow automation in phases.

10. Patterns that come up most in CRM migrations

A couple of patterns worth calling out specifically, because they come up in most CRM migrations:

• GoHighLevel has a lot of per-location complexity. If you’re running an agency on GHL, each location has its own schema, custom fields, and automations. Plan to treat each location as a separate migration with its own spreadsheet — don’t try to unify on day one.
• HubSpot’s per-contact pricing model changes your import strategy. There’s no reason to import inactive contacts on day one if you’re leaving HubSpot partially because of the contact-count bill. Migration is a good moment to decide which contacts deserve to exist on the new platform. For a deeper comparison, see our HubSpot alternatives guide.
• Reports and dashboards rarely translate. Budget extra time to rebuild reporting. The “top-of-funnel this quarter” dashboard your sales lead looks at every morning is exactly the wrong thing to be rebuilding under time pressure during the first week post-cutover.

Preparing CRM Data for AI and Automation

A CRM migration is also an opportunity to prepare your customer data for AI-native CRM workflows.

AI agents, automation tools, and CRM dashboards depend on clean, structured data. If customer records are duplicated, fields are inconsistent, activity history is missing, or statuses are unclear, AI tools will struggle to produce useful summaries, recommendations, and workflow actions.

Before moving to a new CRM, review whether your data is ready for:

• CRM automation
• CRM workflow automation
• AI-assisted lead summaries
• CRM dashboard reporting
• MCP tools for AI agents
• REST API integrations
• Bring Your Own AI workflows
• Custom CRM development
• Lead routing and follow-up automation

An AI-ready CRM database should have consistent fields, reliable statuses, complete activity history, clear ownership, and structured records that both humans and AI agents can understand.

This matters because AI CRM workflows are only as useful as the data underneath them.

How Conduyt Supports a Cleaner CRM Migration

Conduyt is designed for teams that want a more flexible CRM foundation after leaving a legacy system. With flat-rate CRM pricing, unlimited users, CRM automation, REST API access, MCP tools, and Bring Your Own AI architecture, Conduyt can support both human workflows and AI-powered operations.

For teams migrating from a legacy CRM, Conduyt can help support:

• Cleaner CRM database structure
• Contact, company, deal, and activity records
• CRM lead management workflows
• Pipeline tracking and reporting
• CRM dashboard visibility for managers and operators
• Workflow automation across sales, support, marketing, and operations
• CRM integrations through API access and webhooks
• MCP tools for AI agents
• Custom CRM development and internal workflow design

The best migration is not just a successful import. It is a new CRM structure that your team can actually trust, automate, report on, and build around.

---

Closing

A good CRM migration ends with your team not noticing they moved. That’s an achievable bar if you spend more time in the spreadsheet than in the export button, run a real parallel period, and validate in structured passes. Most of the work happens before anyone clicks “import.” Most of the mistakes happen when that order gets reversed. According to Gartner, CRM remains the largest enterprise software category, which means the migration playbook above applies to more teams every year.

If you’re evaluating Conduyt as your migration destination, start the 20-day free trial and we’ll walk through your migration plan together. You might also find our flat-rate CRM pricing guide helpful for understanding how Conduyt’s pricing compares to the per-seat model you may be leaving behind.

FAQ

What is CRM migration?

CRM migration is the process of moving customer records, activity history, fields, users, workflows, reports, and integrations from one CRM system to another.

Why do CRM migrations fail?

CRM migrations often fail because of poor data cleanup, incomplete field mapping, duplicate records, missing activity history, broken integrations, unclear ownership, and workflow automation that was not tested before go-live.

What should be included in a CRM migration checklist?

A CRM migration checklist should include customer records, activity history, custom fields, pipeline stages, statuses, ownership, permissions, CRM integrations, workflow automation, dashboards, reports, and post-migration QA.

How do you avoid losing records during CRM migration?

To avoid losing records, export a complete backup, map fields carefully, use stable record identifiers, test with sample data, compare record counts, validate activity history, and keep a rollback plan.

Why is field mapping important in CRM data migration?

Field mapping is important because it determines where each piece of legacy CRM data will live in the new CRM. Poor field mapping can break reports, automations, integrations, and customer record history.

Should CRM automations be turned on immediately after migration?

No. CRM automations should usually stay paused until the migrated data has been validated. Once records, fields, statuses, and integrations are confirmed, workflows can be turned on in phases.

How does CRM migration affect AI workflows?

AI workflows depend on clean CRM data. If records are duplicated, fields are inconsistent, or activity history is missing, AI agents may produce poor summaries, recommendations, or workflow actions.

What is CRM data migration, and how is it different from a generic CRM migration?

CRM data migration is the narrower technical workstream inside a broader CRM migration project. The full migration covers strategy, configuration translation, integration rewiring, training, and cutover. CRM data migration specifically handles the records – contacts, deals, activities, notes, custom fields, attachments – moving from the source CRM to the destination CRM with semantics preserved. Most CRM migration project plans split data migration into its own phase because it has its own failure modes (encoding issues, field-type mismatches, deduplication conflicts) that are independent of the configuration translation work.

What is a typical CRM migration strategy for mid-market teams?

A typical CRM migration strategy for mid-market teams runs in five phases over 4-8 weeks. Phase 1: source-system audit (export every record, custom field, automation, and integration with documentation). Phase 2: destination workspace setup (replicate the data model in the new CRM with adjustments for platform conventions). Phase 3: data migration dry run (load a subset, validate, fix issues, repeat). Phase 4: parallel-run period (both CRMs receive updates for 1-2 weeks while the team validates accuracy). Phase 5: cutover (hard-stop on the old CRM, single source of truth on the new one). The CRM data migration best practices the playbook above details apply at every phase.

Do CRM migration services and CRM migration tools cover the same scope?

No. CRM migration services are professional-services engagements where a vendor or partner team executes the full migration on your behalf, typically $5,000-$50,000+ depending on data volume and complexity. CRM migration tools are software products (some vendor-provided, some third-party like Trujay) that automate the technical data-transfer step but leave strategy, configuration, and validation work to your team. Most successful migrations combine both: a tool for the bulk record transfer plus internal or partner-led services for everything around it.

What are the CRM data migration best practices to avoid losing records?

The CRM data migration best practices that prevent lost records: (1) preserve a frozen export of the source system before any cutover, kept for at least 90 days in case rollback is needed; (2) run a deduplication pass on the source data before migration, not after – fixing duplicates in the new CRM is harder; (3) map every custom field explicitly, including field-type conversions, and verify the mapping with sample records before bulk load; (4) preserve original record IDs in a custom field on the destination side so audit trails stay intact; (5) test API integrations against the new workspace before the cutover, not during. The full playbook above walks through each of these in detail.