Written by: Doug Camplejohn, CEO & Co-Founder, Coffee
Key Takeaways for Your Salesforce Migration
- Salesforce migration data quality works best as an ongoing discipline. Treat accuracy, completeness, consistency, timeliness, uniqueness, and validity as daily habits, not a one-time cleanup.
- The six-stage playbook of profiling, deduplication, field mapping, sandbox rehearsal, KPI validation, and governance prevents costly post-migration issues and revenue loss.
- Benchmarks such as >98% accuracy, <2% duplicate rate, and >95% required-field completeness give you clear acceptance criteria at every stage.
- Automation and autonomous agents reduce reliance on manual stewardship and keep data quality KPIs healthy long after go-live.
- Teams ready to maintain clean Salesforce data after migration can automate validation and enrichment with Coffee.
Core Data Quality Dimensions for Salesforce Migration
The table below defines the six dimensions every migration team must measure, with benchmarks drawn from current practice. Use this as your acceptance framework so definitions stay clear and scannable.
| Dimension | Definition | Migration Benchmark | Owner | Primary Risk | Measurement Method |
|---|---|---|---|---|---|
| Accuracy | Data reflects real-world values (correct names, emails, revenue figures) | >98% verified records | RevOps / Data Steward | Stale or fabricated contact data | Spot-check sample vs. source of truth |
| Completeness | Required fields are populated for every record | >95% required-field fill rate | Salesforce Admin | Orphaned records with no owner or email | Field-null report pre- and post-load |
| Consistency | Same entity represented identically across all objects and systems | Zero conflicting values for the same field across objects | RevOps | Dropdown value drift (“USA” vs. “United States”) | Cross-object reconciliation query |
| Timeliness | Records reflect current state, not outdated snapshots | No record untouched >12 months without review flag | Sales Ops | Migrating churned customers as active accounts | Last-modified-date audit |
| Uniqueness | Each real-world entity has exactly one record | <2% duplicate rate post-migration | RevOps / Admin | Duplicate contacts inflating pipeline | Automated deduplication scan |
| Validity | Data conforms to defined formats and business rules | 100% of emails pass regex; 100% of phone numbers match E.164 | Salesforce Admin | Invalid formats breaking automation triggers | Validation rule report on load |
1. Source Data Profiling: Expose Problems Before They Hit Salesforce
Inputs: Full export of legacy CRM, connected data sources (marketing automation, ERP, spreadsheets), and a field inventory.
Decisions: Which objects migrate, which are archived, and which are retired.
Owner: RevOps lead with input from Sales Ops and IT.
Systems: Legacy CRM export, Excel or Google Sheets, profiling tools (OpenRefine, Talend).
Auditing legacy CRM data begins with a full data quality assessment to inventory issues including missing contact details, outdated email addresses, multiple records for the same company, deals stuck in old pipelines, and inconsistent formatting. Document every object, field, and relationship before writing a single migration script. That inventory becomes the foundation for your baseline metrics. Organizations should establish data quality baseline metrics for priority data assets as part of the implementation readiness checklist, using the profiling inventory to decide which objects need the strictest thresholds.
Common Pitfall: Poor data quality without proper cleanup can add 2–3 months to the expected migration timeline. Teams that skip profiling discover scope surprises mid-project and face rushed, reactive fixes.
2. Deduplication and Standardization: Create One Clean Version of Every Record
Once profiling reveals the full scope of data issues, the next step is to eliminate duplicates and standardize formats before any data moves into Salesforce.
Inputs: Profiling report, matching-rule definitions, field format standards.
Decisions: Merge vs. archive rules, and which system acts as the authoritative source when records conflict.
Owner: RevOps lead, with Marketing Ops for lead records.
Systems: Deduplication tools (DemandTools, Dedupely), ETL platform.
Deduplication and normalization involves merging duplicate contacts and companies, standardizing phone number formats, cleaning up company naming conventions, and validating email formats to prevent loss of trust in the new system. When merging multiple data sources, teams must designate a single source of truth and define rules for resolving conflicts such as which email address or company name is authoritative. Fuzzy matching algorithms identify duplicates across name variations like “Bob Smith” vs. “Robert Smith” to build reliable golden records.
Common Pitfall: Archived data not visible in the source CRM UI can surface as unexpected errors during test migrations if overlooked. Always export archived objects explicitly so hidden records do not break loads later.
3. Field Mapping and Relationship Preservation: Protect Business Context
Inputs: Source field inventory, Salesforce target schema, business logic rules.
Decisions: Field type conversions, custom field creation, retirement of legacy fields.
Owner: Salesforce Admin, with RevOps for business logic sign-off.
Systems: Salesforce Schema Builder, ETL tool, migration mapping spreadsheet.
Field mapping requires aligning source fields with target fields while applying business logic and data transformation rules such as standardizing dropdown values or merging duplicate fields. Data mapping must transfer every record with its full surrounding context, including sales pipeline history, campaign origin, support tickets, and group assignments, so the migrated record retains its business value. These context-preservation requirements can quickly consume Salesforce platform limits.
Salesforce limits custom fields per object to 800 in Unlimited Edition, custom objects per org to 200 in Enterprise Edition (or 2000 in Unlimited), and lookup or relationship fields per object to 40 (increasable to 50). Some field type changes are destructive and require careful planning, so teams should design mappings with these limits in mind.
Common Pitfall: Any error in master data at the start will be replicated throughout the new system. Validate lookup relationships in a schema diagram before the first load attempt to avoid cascading issues.
4. Sandbox Rehearsal and Mock Loads: Practice Before Production
Inputs: Cleansed, mapped dataset; Salesforce Full or Partial sandbox; validation rule inventory.
Decisions: Pass and fail thresholds per object, plus rollback triggers.
Owner: Salesforce Admin and QA lead.
Systems: Salesforce Sandbox, Data Loader, Dataloader.io.
Salesforce’s CRM Readiness and Migration Checklist recommends testing in a safe environment before full data migration, loading parent records (accounts) first followed by child records (contacts and opportunities), and temporarily disabling validation rules and triggers during the data load to prevent errors. Running multiple trial migrations using several different data samples is especially important when integrating complex systems with multilevel hierarchies and cross-object links.
| Sandbox Test | Pass Criterion | Owner | Remediation if Fail |
|---|---|---|---|
| Parent-object load (Accounts) | 0 load errors; record count matches source | Salesforce Admin | Fix mapping; re-run load |
| Child-object load (Contacts, Opportunities) | All lookups resolve; 0 orphaned records | Salesforce Admin | Repair parent IDs; reload |
| Validation rule re-enable | 0 rule violations on full dataset | RevOps | Cleanse violating records |
| Workflow and automation trigger test | Lead routing and stage transitions fire correctly | Sales Ops | Update trigger criteria |
| Relationship integrity check | All parent-child links intact; no broken lookups | Salesforce Admin | Re-map relationship fields |
Common Pitfall: Treating migration as a single “big bang” event rather than an incremental, domain-by-domain transition increases failure risk. Run at least three mock loads with progressively larger data samples before production go-live.
5. Post-Migration Validation: Confirm KPIs Before You Declare Success
Inputs: Production load logs, pre-migration record counts, stakeholder acceptance criteria.
Decisions: Go or no-go sign-off, and rollback versus remediation path.
Owner: RevOps lead, with an executive sponsor for final sign-off.
Systems: Salesforce reports, Data Loader audit logs, BI tool.
| KPI | Acceptance Threshold | Measurement Method | Owner |
|---|---|---|---|
| Duplicate rate | <2% | Automated deduplication scan post-load | RevOps |
| Required-field completeness | >95% | Field-null Salesforce report | Salesforce Admin |
| Record count variance | <0.5% vs. source export | Source vs. target count comparison | RevOps |
| Relationship integrity | 100% of lookups resolve | Cross-object SOQL query | Salesforce Admin |
| Workflow trigger accuracy | 100% of test scenarios pass | UAT script execution | Sales Ops |
Common Pitfall: Even with careful planning, there is a risk of breaking table relationships or losing transaction history during migration. Preserve the legacy system in read-only mode for at least 30 days post-go-live as a rollback reference.
Keep your migration KPIs green with Coffee’s continuous validation long after go-live.
6. Ongoing Governance and Automation: Keep Data Clean After Go-Live
Inputs: Post-migration KPI baseline, RACI matrix, governance policy documentation.
Decisions: Automation scope and escalation paths for data quality exceptions.
Owner: RevOps, with assigned data stewards per domain.
Systems: Salesforce validation rules, Flow automation, integrated governance platform.
Organizations should adopt the CRM data management lifecycle of capture → validate or standardize → route → update → audit → improve to sustain data quality after go-live rather than treating cleanup as a one-time project. Data quality naturally decays over time, so organizations must treat data quality management as an ongoing program with dedicated ownership, continuous funding, and persistent monitoring.
| Cadence | Activity | Owner | Output |
|---|---|---|---|
| Daily | Automated duplicate scan and validation rule alert review | Salesforce Admin | Exception queue for steward review |
| Weekly | Required-field completeness report and pipeline data health check | RevOps | Data health dashboard update |
| Monthly | Full deduplication run, stale record audit, steward review | RevOps + Data Stewards | Remediation backlog and stakeholder report |
| Quarterly | Governance policy review, RACI refresh, KPI trend analysis | RevOps + IT | Updated governance documentation |
Automation of validation, normalization, deduplication, and governance rules is required at enterprise scale because manual review cannot keep pace with omnichannel lead volume and complexity. A governance-first approach that establishes RACI, data quality standards, and access policies before migrating data can reduce audit preparation time and prevent disputes later.
Common Pitfall: Clear governance ownership by groups such as Marketing Ops, Sales Ops, RevOps, and IT is necessary to resolve consistency disputes and prevent data quality from depending on individual memory or discipline. Without named stewards, governance cadences often collapse within 90 days of go-live.
Post-Migration Data Validation in Salesforce: How Autonomous Agents Take Over
The most durable post-migration data validation Salesforce strategy removes humans from the data-entry loop entirely. Autonomous agents such as the Coffee Companion App connect directly to a Salesforce instance, ingest unstructured signals from emails, calendar events, and call transcripts, and write structured, validated records back to the CRM in real time. AI and machine learning can support automated anomaly detection, probabilistic matching of duplicate records, and data classification to scale maintenance after CRM migration, replacing the manual stewardship cadences that most teams abandon within a quarter of go-live. The result is a self-maintaining system of record where the six governance KPIs above are enforced continuously, not periodically.
Frequently Asked Questions
Who should own Salesforce migration data quality: IT, RevOps, or the Salesforce admin?
Ownership works best when distributed across a RACI matrix, not concentrated in a single role. The Salesforce admin owns technical execution such as schema design, load configuration, validation rule management, and sandbox testing. RevOps owns business logic, including field definitions, acceptance criteria, duplicate-matching rules, and post-migration KPI sign-off. IT owns infrastructure, security, and access controls. A named executive sponsor holds go or no-go authority. Without explicit RACI documentation before the project starts, accountability gaps form at the handoff between profiling and cleansing, and again between sandbox testing and production go-live. Assign owners to every stage in the six-stage playbook before the first data export.
How long does a Salesforce data migration take when data quality is poor?
Timeline depends heavily on source data condition and organizational complexity. A mid-market company with a single legacy CRM and reasonably maintained records can complete a migration in eight to twelve weeks. When data quality is poor, with significant duplicates, inconsistent formatting, missing required fields, or multiple source systems, the profiling and cleansing stages alone can consume four to six weeks. As noted in the profiling stage, timeline extensions of two to three months are common when teams skip cleanup, and the delay compounds when issues surface mid-project rather than during profiling.
What is the difference between sandbox testing and production validation in a Salesforce migration?
Sandbox testing uses a rehearsal environment where the migration team loads cleansed, mapped data into a Salesforce sandbox org to identify load errors, broken relationships, and automation failures before any production data is touched. The process is iterative, and teams run multiple mock loads with progressively larger data samples. Production validation occurs after the actual go-live load and confirms that the live instance meets the acceptance criteria defined in Stage 5, including duplicate rate below 2%, required-field completeness above 95%, record count variance below 0.5%, and all workflow triggers firing correctly. Sandbox testing is preventive, while production validation is confirmatory. Both are mandatory, and skipping sandbox testing in favor of production-only checks is a common cause of emergency rollbacks.
How can smaller RevOps teams scale the six-stage process without data engineers?
Small RevOps teams should prioritize automation and tooling over manual work at every stage. For profiling and deduplication, tools like DemandTools or Dedupely handle matching and merging without custom scripts. For field mapping, Salesforce’s native Data Import Wizard auto-matches columns and flags unmapped fields. For sandbox testing, Dataloader.io provides a UI-driven load process that does not require command-line expertise. For ongoing governance, Salesforce Flow automation enforces required fields and validation rules at the point of entry, which removes the need for frequent manual audits. The governance cadence table in Stage 6 is designed so a single admin can execute it with automated tooling handling daily and weekly tasks, while humans focus on monthly and quarterly reviews. Autonomous agent platforms that write enriched, validated data back to Salesforce continuously can further reduce the manual governance burden to near zero.
Conclusion: Turn Your Migration into a Self-Maintaining System
Salesforce migration data quality works as a six-stage continuous process: profile the source, deduplicate and standardize, map fields and relationships, rehearse in sandbox, validate against measurable KPIs, and govern with automation. Poor data quality costs the average B2B company between $12.9 million and $15 million per year, and 37% of CRM users reported losing revenue as a direct consequence of poor data quality in 2025. Teams that execute all six stages with clear owners, measurable acceptance criteria, and automated governance avoid the two-year cleanup cycle that derails most migrations. Teams that skip stages often pay for it in stalled forecasts, broken automations, and rep distrust of the system of record.
