A 200-contact export from your old CRM sounds straightforward until you're staring at 140 duplicates, contact names split across three fields, and deal close dates that are six months off. Then your team asks where last quarter's committed pipeline went, and nobody can find it in the new system. Bad CRM migrations are common enough that most operations teams have a war story. The fix isn't to delay the switch—it's to treat the data movement as infrastructure work, not paperwork. You need a data audit , a deduplication pass , field mapping done before you touch anything live, a test run on a sandbox , and a cutover plan with a known rollback point. Here's how to move customer data without losing deal history. Step 1: Audit what you actually have Export your entire customer database from your current system. Open it in a spreadsheet and spend an afternoon—literally—counting and categorizing what's there. Ask yourself: How many contacts? If the export shows 500 but your team talks about 280 active customers, you have duplicates or abandoned test data. How many deals? Count rows. Then count again by deal stage. Deals that sit in 'Negotiation' for three years without a last-touch date are either dead or unmaintained. How many fields actually have data? Your old CRM may have 40 fields. If 12 are empty across 90% of records, you're moving garbage. What's in notes/history? Open a random 20 deal records. Are there call logs, email threads, or just the occasional comment from 2021? This tells you whether your migration can recover context or whether you're starting over anyway. Date integrity. Pull the oldest and newest deal dates. If you see deals from 1999 or dates in 2027, those are typos or test data. Flag them. Document your findings in a simple spreadsheet: total contacts, total deals, total records, empty field count, date range, known data quality issues. This becomes your baseline for QA after migration. Step 2: Deduplicate before you move anything Duplicates are the silent killer of CRM migrations. One contact record that exists three times with slight variations—"John Smith", "J. Smith", "john.smith@company.com"—will either merge badly in the new system or create confusion for your entire team. Do this in your old system . Do not move duplicates hoping the new platform will clean them up. Three methods, in order of effort: Manual merge in your current CRM. Most CRMs (Salesforce, HubSpot, Pipedrive, even Orin's CRM ) have a built-in merge function. Use it. It's slow for 500 contacts but guarantees you understand what's being combined. Deduplication software. Tools like Winback, Dupe Killer, or your CRM's native cleaning tool can flag likely duplicates. Always review before merging—automatic dedup can incorrectly combine two real people with the same name at different branches. Spreadsheet sort and manual review. Export contacts, sort by last name + first name + email domain. Scan visually. Takes two hours for 500 records but you catch edge cases. After deduplication, your contact count should drop by 10–30%. If it drops 60%, you were moving a lot of test data and you're now closer to truth. Step 3: Map fields before the export Your old CRM and your new one don't speak the same language. "Deal Amount" in Pipedrive might be "Contract Value" in your new platform. "Status" in one might be "Stage" in another. Moving data without a map means amounts land in text fields, stages get munged into descriptions, and nobody can run a revenue forecast. Create a field mapping document : Left column: Every field in your old CRM that has data. Middle column: The exact equivalent field in your new system. If there's no match, write "Custom field needed" or "Drop this." Right column: Data type. Is it text, number, date, dropdown, email, phone? If types don't match (e.g., old CRM stores deal amount as text with commas; new one expects a number), you need a conversion rule. Example: Old CRM "Deal Value" (text) → New CRM "Annual Contract Value" (number) → Conversion: Strip commas, convert to integer. Old CRM "Close Date" (date) → New CRM "Expected Close" (date) → No conversion needed. Old CRM "Industry" (dropdown: 50 values) → New CRM "Sector" (dropdown: 12 values) → Needs manual translation table. This step saves hours of troubleshooting after migration. Share the map with both your old CRM admin and your new one. If anyone says "That field doesn't exist," you find out now, not after cutover. Step 4: Run a test migration on a sandbox Never do a first migration on live data. Your new CRM should offer a sandbox (a copy of the production environment where you can experiment safely). If it doesn't, ask for one or use a second trial account. Export a small, representative subset: 20–30 contacts, 10–15 active deals, at least one deal in each stage. Run the migration following your field map. Then check: Contact integrity. Do emails, phone numbers, and names look right? Is there any weird character encoding (names showing as "Jo###hn"