Written by: Doug Camplejohn, CEO & Co-Founder, Coffee | Last updated: August 11, 2026
Key Takeaways for a Clean Salesforce Migration
- Data quality, not record volume or field mapping, is the leading cause of Salesforce migration failure, with 60% of CRM migrations failing due to bad data quality.
- The eight-step pre-migration checklist covers full backups, data profiling, record classification, enrichment, deduplication, external ID creation, sandbox testing, and post-load validation.
- Resolving duplicates and enriching records in the source system before migration prevents costly post-go-live remediation and broken automations.
- External ID fields and proper load order ensure accurate parent-child relationships and faster, more reliable data loads during migration.
- Deploy Coffee to continuously enforce data quality at the source and avoid future migrations, and get started with Coffee.
The 8-Step Pre-Migration Data Quality Checklist
- Export a Full Backup of Every Source Object
Export Account, Contact, and Opportunity objects using the Data Export Service for scheduled weekly zipped CSVs or Data Loader for targeted on-demand extracts that include record IDs and all fields that may change. Treat these files as your rollback baseline. No migration has an undo button once data reaches production.
- Use Data Export Service for scheduled, automated snapshots.
- Use Data Loader for targeted object extracts keyed on record ID.
- Store success and error log files for audit and rollback reference.
- Profile and Audit Source Data
Data profiling analyzes datasets to identify anomalies, inconsistencies, duplicates, and missing values before remediation begins. Given that 60% of CRM migrations fail due to bad data quality, the pre-migration audit is your primary risk mitigation tool. It produces a data quality report that the business owner reviews, with resolution decisions required before migration begins.
- Flag duplicate records, missing required fields, and formatting inconsistencies.
- Identify invalid picklist values and referential integrity breaks such as contacts without parent accounts.
- Run saved reports for open opportunities with past close dates, blank Next Step fields, and last activity older than 30 days.
- Classify Records: Migrate, Archive, or Leave Behind
Classify objects and data categories as migrate, archive, or leave behind, and capture sign-off from a named business owner for each decision to prevent scope creep. Removing dead records such as those with no activity in two or more years, no open opportunities, bounced emails, test records, and personal email addresses for B2B records can remove a large portion of the database before migration.
- Migrate: data actively used in current workflows, reporting, compliance, or customer relationships.
- Archive: records needed only for legal or historical reference.
- Leave behind: duplicates, test data, and data with no business or compliance value.
- Enrich Records Before Deduplication
Run enrichment first in the Salesforce data cleansing sequence, because it fills domains, DUNS numbers, industry, employee count, geography, and parent identifiers that serve as match keys for subsequent deduplication. Running deduplication on unenriched records produces false negatives, where records appear distinct only because a field is blank.
- Validate email syntax using services such as ZeroBounce, NeverBounce, or BriteVerify.
- Standardize Country, State, Industry, Lead Source, and Job Title to Salesforce picklist values.
- Correct phone numbers, date formats, and capitalization inconsistencies.
- Deduplicate in the Source System
Deduplicating 70,000 records before migration typically takes 15-90 minutes, while post-migration deduplication after records have mixed with existing data can be significantly more costly and time-intensive. For volume thresholds, use Excel for small datasets, OpenRefine for medium datasets, and DemandTools or CRMfusion for large datasets that require fuzzy matching.
- Under 5,000 records: Excel or Google Sheets with normalized email as the match key.
- 5,000–50,000 records: OpenRefine or Python-based grouping by normalized email or company name.
- Over 50,000 records: DemandTools, Cloudingo, or CRMfusion with fuzzy account-name matching.
- Apply tiebreaker rules that favor records with active opportunities or higher revenue as the survivor.
- Create and Populate External ID Fields
Create a custom External ID field such as Legacy_ID__c on objects like Account and mark it as an External ID to enable Upsert operations that match child records to parents without needing Salesforce-generated IDs. Salesforce external ID fields are automatically indexed by the platform, which speeds up lookup operations and improves reliability during large data loads.
- Set field length to at least 36 characters to accommodate GUIDs from systems like Microsoft Dynamics, so the field can store any identifier format your source system uses.
- Enforce uniqueness to prevent duplicate legacy IDs from entering the target org, which catches data quality issues at load time instead of after records reach production.
- Before loading, trim whitespace and standardize formats on all legacy IDs, because even minor formatting inconsistencies can break the lookup matching that makes External IDs valuable.
- Retain Data Loader success files as the canonical mapping between legacy IDs and new Salesforce record IDs for post-migration reconciliation, rollback validation, and troubleshooting.
- Run Sandbox Test Migrations
Plan multiple cycles of test migrations in sandbox environments before production cutover. Perform a test load of 100 records into a sandbox using Data Loader, then review success and error files, field values, lookup relationships, currency and date formatting, and automation behavior before any production migration.
- Use a Full Copy Sandbox to mirror production as closely as possible, so your test environment reflects the configuration where the migration will run.
- Before loading, temporarily disable Record-Triggered Flows, validation rules, Workflow Rules, and Apex Triggers to isolate pure mapping errors from automation behavior and make diagnosis easier.
- Load in batches of 5,000–10,000 records to stay under governor limits and simplify error diagnosis, since smaller batches limit blast radius and keep error logs manageable.
- For loads over 50,000 records, switch to Bulk API instead of the standard API, because Bulk API 2.0 handles up to 150 million records asynchronously without timing out on large datasets.
- Validate Post-Load and Establish Ongoing Governance
Use a four-layer validation framework that verifies source row count equals target row count per object and batch, spot-checks 5–10% of records for field-level integrity, performs aggregate checks such as matching opportunity amount sums, and conducts user acceptance testing where real users verify real records. Run automated field-level checks for at least the first 90 days after go-live, with a named data quality owner managing recurring check-ins and regression alerts.
- Reconcile record counts per object and investigate any discrepancy greater than 0.1%.
- Verify sharing rules, child record relationships, renamed fields, and report functionality.
- Implement validation rules and hygiene dashboards for ongoing governance post-migration.
Deploy Coffee to prevent your next migration. The agent enforces data quality at the source and stops data decay before it creates another migration project.
How Coffee Companion App Compares to Manual Cleansing
The following table compares the manual data quality processes in the checklist with Coffee’s automated approach, showing how continuous enforcement removes recurring migration work.
| Capability | Manual Process | Coffee Companion App | Business Impact |
|---|---|---|---|
| Data entry and logging | Rep-dependent, and 71% of sales reps say they spend too much time on data entry | Agent auto-logs calls, emails, and calendar events to Salesforce continuously | Eliminates the primary source of missing and stale records |
| Deduplication | The pre-migration deduplication window described in Step 5, while post-migration deduplication can be significantly more costly | Agent prevents duplicate creation by enriching and matching records at ingestion | Removes deduplication as a recurring migration cost |
| Record enrichment | Requires separate ZoomInfo or Apollo subscription and manual field updates | Agent enriches job titles, funding, and LinkedIn profiles via licensed data partners automatically | Consolidates stack and keeps enrichment current instead of point-in-time |
| Pipeline visibility | Manual CSV exports, and quarterly audits required to detect data drift | Agent tracks all pipeline changes week-over-week automatically via Pipeline Compare | Replaces expensive add-ons and surfaces stalled deals without admin effort |
How to Handle Duplicates During Salesforce Migration
Duplicates are the most destructive data quality problem in a Salesforce migration because they split pipeline attribution, corrupt territory assignments, and break automation logic from day one. Resolve duplicates in the source system before any records are exported.
Volume determines tooling. For larger volumes, tools such as Cloudingo, DemandTools, or Python-based grouping by normalized email or company name handle deduplication outside production. When the legacy CRM cannot safely support mass merge operations, a staging environment serves as a safe control point.
The matching sequence also matters. Matching uses exact identifiers and multi-field matching to identify duplicates, applies tiebreaker rules that favor active opportunities or higher revenue, and defines survivorship rules before merges. Handle hierarchy resolution after matching so that parent records are deduplicated before children are re-parented.
Salesforce matching rules define comparison logic such as fuzzy account-name or exact contact-email matching but perform no action on their own, while duplicate rules reference matching rules and control actions on create or edit such as alert, block, or silent report. Enable both before the final production load to prevent net-new duplicates from entering the org during cutover.
Correct Load Order for Salesforce Data Migration
Load order affects data integrity because loading records out of sequence creates orphaned child records with broken parent associations. These problems often surface weeks after go-live in reports and automation failures rather than immediately in record counts.
Consider these practical guidelines by volume and complexity.
- For one-time CSV migrations of up to one million records with few automations, the process typically takes around one week from cleaning to production validation.
- Complex historical migrations involving multimillion records and deep relationships typically require two to three weeks, depending on data hygiene and metadata behavior in production.
- Attachments and files can represent a substantial portion of the overall data volume compared to structured records, so plan a separate migration and use tooling such as the Salesforce Files API in parallel with the structured data migration.
- For very large data loads, suspend sharing rule calculations to prevent the system from recalculating permissions for every inserted record.
Why External IDs Matter in Salesforce Migrations
External IDs allow Data Loader to perform parent-child lookups using legacy identifiers instead of Salesforce-generated record IDs. Without them, loading child records after parents requires manual VLOOKUP operations across exported success files, which breaks at scale and introduces mapping errors.
Use this setup checklist for External IDs.
- Create a text field on each target object with a length sufficient to store the longest source-system identifier, at least 36 characters for GUIDs.
- Mark the field as External ID and optionally enforce uniqueness to block duplicate legacy IDs.
- Use consistent naming conventions across all objects.
- Keep the success files mentioned in Step 6, because you will need them to troubleshoot any child records that fail to link to their parents.
- If child records fail to link to parents, verify that the lookup was mapped to the parent object’s External ID field rather than its Salesforce ID and confirm that all legacy IDs are clean and consistently formatted.
Keep your Salesforce data clean with Coffee. Continuous data quality enforcement means External IDs become a one-time migration artifact instead of a recurring operational dependency.
Failure Case: Lost Pipeline from Orphaned Records
A SaaS company migrated from a legacy CRM to Salesforce without completing a pre-migration deduplication pass on its Contact and Opportunity objects. The migration team prioritized timeline over data quality and skipped the source-side audit.
After go-live, the revenue operations team identified numerous duplicate Contact records that split activity history and broke lead routing rules. Some Opportunities were orphaned and became invisible in territory reports, which removed pipeline value from the quarterly forecast and triggered a review of forecast accuracy.
The remediation required significant manual cleanup by the Salesforce admins. The pre-migration audit is a mandatory de-risking step that prevents quality problems from reaching production Salesforce, where they require months of post-go-live remediation by sales teams. The cleanup cost exceeded the cost of a full pre-migration audit by a wide margin.
Salesforce Migration Readiness Matrix
Use this matrix to assess your organization’s current migration readiness across four critical dimensions. Teams that score Low Readiness in two or more areas should address those gaps before starting the eight-step checklist.
| Dimension | Low Readiness | Medium Readiness | High Readiness |
|---|---|---|---|
| Team size and admin capacity | No dedicated Salesforce admin, with migration owned by sales ops part-time | One dedicated admin and an external consultant engaged for cutover | Dedicated admin plus RevOps lead with prior migration experience |
| Current CRM and data model complexity | Multi-org or heavily customized legacy CRM with undocumented custom objects | Single-org CRM with moderate customization and partial documentation | Standard objects, documented schema, and clean field taxonomy |
| Data maturity | 76% of CRM users believe less than half their organization’s data is accurate and complete, with no baseline metrics established | Duplicate rate and fill rate measured on key objects, with partial remediation completed | Pre-migration audit complete, with deduplication, enrichment, and External IDs in place |
| Change management capacity | No training plan and end users unaware of migration timeline | Communication plan drafted and UAT participants identified but not yet scheduled | UAT sign-off process defined, training delivered, and rollback plan documented and tested |
Frequently Asked Questions
Does Coffee Companion App integrate with existing Salesforce workflows and third-party tools?
Coffee Companion App connects to an existing Salesforce or HubSpot instance through a simple authentication flow. The agent syncs data, enriches records, and writes insights back to Salesforce without replacing the existing system of record. For third-party tool integrations beyond Salesforce and HubSpot, Coffee currently supports connections via Zapier, with deeper native integrations on the product roadmap. The agent also connects to Google Workspace and Microsoft 365 to auto-capture emails, calendar events, and call transcripts directly into Salesforce records.
How does Coffee handle data security and compliance?
Coffee is SOC 2 Type 2 certified and GDPR compliant. Data processed by the Coffee Agent is not used to train public AI models. For mid-market teams in regulated-adjacent industries, this keeps customer interaction data from emails, calls, and calendars within the compliance boundary. Organizations in heavily regulated industries such as healthcare or finance that require multi-year security reviews fall outside Coffee’s current ideal customer profile.
What does Coffee Companion App cost, and how is pricing structured?
Coffee uses seat-based pricing. Each human seat includes the full labor of the Coffee Agent, including automated data entry, enrichment, meeting management, pipeline intelligence, and Salesforce sync, without additional metering on AI usage or process volume. There are no separate charges for the number of records enriched, emails logged, or automations triggered. This structure keeps total cost predictable for mid-market RevOps teams that compare it against point solutions for enrichment, recording, and engagement sequencing.
Can Coffee Companion App prevent the need for future Salesforce migrations?
The primary cause of CRM migrations is accumulated data debt such as missing records, stale contacts, and unlogged interactions that make the existing system untrustworthy. Coffee addresses this at the source by deploying an agent that continuously captures and structures data from emails, calendars, and call transcripts into Salesforce without requiring manual entry from sales reps. When the input stays accurate and complete on an ongoing basis, the data quality problems that typically force a migration do not accumulate. Teams that deploy Coffee Companion App on top of Salesforce fix the underlying cause of data decay instead of scheduling the next cleanup project.
How long does a typical Salesforce migration take, and where does Coffee fit in the timeline?
Migration timelines vary significantly by source complexity and data volume. Simple migrations from a clean single-org CRM typically run three to six weeks. Microsoft Dynamics to Salesforce migrations typically run 16–24 weeks. Multi-org Salesforce consolidations can typically be completed in 3–8 weeks or even three weekends, though complex enterprise projects may take longer. Coffee Companion App delivers the most value when deployed immediately after production cutover, during the critical first ninety days when data governance is fragile and new records enter the system from multiple sources. The agent enforces data quality from day one of the new environment and prevents the regression that often follows a migration when manual entry habits return.
Put Coffee to work on your migration data quality. Deploy the agent before, during, and after cutover to maintain the clean state you worked hard to achieve.
