By
Every Salesforce data migration starts with the same promise: clean records, connected systems, and a CRM that finally reflects how the business actually runs. Most projects don't fail because the vision was wrong. They fail because of decisions made weeks before go-live, when nobody stopped to ask what was actually being moved and why.
Salesforce data migration pitfalls rarely announce themselves as a single catastrophic error. They show up as a broken rollup three weeks after launch, a sales rep who stops trusting a report, or an integration that quietly drops records nobody notices until quarter close. Gartner puts the average cost of poor data quality at $12.9 million per organization per year, and much of that damage traces back to data problems that existed before migration even started and simply moved house along with everything else.
This guide walks through eight of the most common failure points in Salesforce migration projects, why each one happens, and what a structured approach looks like in practice. Teams evaluating a move to Salesforce, a consolidation of multiple orgs, or an expansion into Data Cloud and Agentforce will recognize most of these long before they become expensive.
1. Migrating dirty data instead of cleaning it first
The most common Salesforce data migration pitfall isn't technical at all. It's the decision to move data as-is because cleaning it feels like it will slow the project down. Duplicate accounts, inconsistent naming conventions, and stale leads get carried over on the assumption that someone will sort it out later. Later rarely comes, because the org is already live and everyone has moved on to the next priority.
Once bad data lands in Salesforce, it doesn't sit quietly. Duplicate contacts split activity history across two records. Inconsistent state or industry values break segmentation and reporting. Reps notice within days that a list is wrong, and once they stop trusting the CRM, they go back to spreadsheets, which defeats the entire purpose of the migration. Industry estimates put the cost of fixing a bad record after it enters a system at roughly ten times the cost of catching it beforehand, and roughly a hundred times the cost if it's never caught at all.
The fix is a data cleansing and deduplication pass before a single record touches the target org, not after:
- Profile the source data to quantify duplicates, blank required fields, and inconsistent formats before scoping the migration timeline
- Standardize picklist values, naming conventions, and address formats against the target org's schema
- Archive or exclude obsolete records, such as leads inactive for years, rather than migrating them out of habit
An implementation partner typically runs this as a distinct phase with its own sign-off, using profiling tools to produce a before-and-after data quality scorecard the business can actually see.
2. Skipping a full data and systems audit
Teams often scope a migration based on what they remember being in the CRM, not what's actually there. Spreadsheets bolted onto the sales process, a regional team's shadow database, and years of undocumented custom fields all tend to surface only after the migration is already underway, at which point they either get rushed in or left behind entirely.
The result is a migration that technically succeeds while missing entire slices of business-critical information. A professional services team might discover, mid-project, that renewal likelihood scores lived in a spreadsheet nobody flagged during scoping. Fixing that after go-live means a second, unplanned migration effort layered on top of the first, usually under worse time pressure than the original project had.
- Inventory every system, spreadsheet, and shadow database that currently feeds sales, service, or reporting processes
- Interview end users across departments, not just IT, since the people entering data daily know where the real records live
- Document field-level ownership so the audit produces a source-of-truth map, not just a list of systems
An implementation partner's discovery phase should produce this map before any migration timeline gets committed to leadership.
3. Breaking object relationships and referential integrity
Salesforce data is relational by design. Accounts connect to contacts, contacts connect to opportunities, and opportunities connect to activity history and custom objects layered on top. A migration that moves each object independently, without preserving the parent-child links between them, produces records that look complete individually but tell the wrong story together.
This tends to surface in the worst possible place: reporting. A pipeline report that used to roll up correctly by account now shows orphaned opportunities with no parent. A support case history that should trace back to a contact instead sits disconnected. These aren't cosmetic issues; they undermine the forecasting and service continuity the migration was supposed to protect in the first place.
- Map every parent-child and lookup relationship in the source system before building the migration sequence
- Migrate objects in dependency order (accounts, then contacts, then opportunities, then activity) so relationship IDs resolve correctly
- Validate referential integrity in a full sandbox before touching production, checking for orphaned records rather than assuming a clean load
4. Underestimating schema and field mapping mismatches
Legacy CRMs and Salesforce rarely structure data the same way. A field called "Region" in the old system might need to map to three separate picklist values in Salesforce, or a custom object that made sense in a spreadsheet might not have an equivalent object at all. Teams that treat field mapping as a mechanical export-import step, rather than a design decision, end up with silent data corruption that validation rules don't always catch.
Renamed fields, reordered columns, and mismatched data types break automated comparison scripts and can cause records to load with the wrong values in the wrong fields without throwing a single error. By the time someone notices, hundreds or thousands of records may already carry the mismatch, and tracing which ones were affected becomes its own project.
Salesforce's data mapping tools, combined with a documented field crosswalk, reduce this risk substantially:
- Build a field-by-field crosswalk document as part of discovery, not as an afterthought during load
- Flag every field with a data type mismatch (text-to-picklist, date format differences) for manual review before mapping
- Run a sample batch through a sandbox and manually spot-check a statistically meaningful sample against the source, rather than trusting a clean load count alone
5. Triggering automation and validation rules during load
Salesforce orgs accumulate automation over time. Workflow rules, triggers, and validation rules exist to enforce business logic when a human enters a record, but a migration load isn't a human entering a record. It's thousands of records arriving at once, and every one of them can fire the same automation that was built for one-at-a-time use.
The consequences range from annoying to genuinely damaging. Welcome emails go out to contacts who migrated three years after their last interaction. Validation rules block otherwise-valid historical records because they don't meet a rule written for new data entry. Assignment rules route thousands of legacy leads to whichever rep happens to own the current queue. None of this is a data problem; it's an automation design problem that only migration volume exposes.
- Inventory every trigger, workflow rule, process builder flow, and validation rule active in the target org before migration
- Disable or bypass non-essential automation during the load window, then re-enable it in a controlled sequence afterward
- Test the full automation stack against a sample load in sandbox to confirm nothing fires unexpectedly at volume
6. Rushing sandbox testing to hit a deadline
Sandbox testing is the step most likely to get compressed when a project falls behind schedule. It doesn't produce a visible deliverable the way a dashboard or a training session does, so it's an easy target when a deadline is slipping. The problem is that sandbox testing is the only stage where migration errors are cheap to fix; every error caught after production go-live costs materially more to unwind.
A rushed or skipped sandbox phase tends to surface its damage in stages rather than all at once, which makes it harder to trace. A report breaks in week one. A duplicate rule conflicts with legacy data in week three. An integration timeout appears under real production load in month two. Each incident looks unrelated, but they usually share the same root cause: nobody ran a full-volume test before go-live.
A disciplined implementation partner treats sandbox testing as a gating milestone, not a flexible buffer:
- Test with a full-volume, production-representative data set, not a small sample that hides scale-related issues
- Run parallel reporting comparisons between the legacy system and the sandbox to confirm numbers match before cutover
- Build a defined exit criteria checklist for sandbox testing that has to pass before production migration is authorized
7. Missing undocumented integrations
Most Salesforce orgs connect to other systems: marketing automation platforms, billing software, e-signature tools, and custom middleware built by a developer who has since left the company. These integrations are frequently undocumented, which means they don't show up on anyone's migration checklist until something downstream stops working.
Point-to-point integrations built on assumptions about field names, object structures, or API endpoints tend to fail quietly rather than loudly. A billing sync might keep running but silently drop records that no longer match its expected schema. Nobody notices until finance flags a discrepancy weeks later, and by then, tracing the gap back to the migration takes far longer than testing the integration would have.
- Produce a complete integration registry before migration kickoff, listing every connected app, API credential, and middleware flow
- Validate each integration against the new org structure in a full sandbox, not just the migrated data itself
- Assign an owner for each integration who confirms it works end-to-end before the migration is marked complete
8. Skipping backup and rollback planning
It's easy to assume a migration will go as planned, especially after weeks of preparation. Skipping a formal rollback plan is a bet that nothing will go wrong at exactly the moment when the stakes of being wrong are highest: production, live users, and a business that can't simply pause while a fix gets sorted out.
Without a tested rollback path, a migration failure turns into a business continuity incident rather than a contained technical problem. Sales teams lose access to active pipeline. Support agents can't pull case history. What should have been a delay of a few hours turns into days of manual workarounds while the team improvises a recovery plan under pressure.
- Take a full backup of both source and target systems immediately before cutover
- Define a rollback trigger in advance (specific error thresholds, not gut feel) so the decision isn't made in the middle of a crisis
- Schedule migration windows, such as a weekend, that allow for rollback and re-testing without disrupting a full business day
Partner with TELUS Digital for a Salesforce data migration that holds up after go-live
Salesforce data migration pitfalls are avoidable, but avoiding all eight consistently takes more than good intentions. It takes a structured implementation approach built around data profiling, sandbox testing discipline, and a governance model that survives past launch day, along with ongoing managed services support to keep the org clean once it's live.
TELUS Digital's Salesforce practice runs migration projects with this discipline built in from discovery through go-live, including AI and data services for teams preparing their org for Data Cloud or Agentforce, where clean, well-structured data isn't optional; it's a prerequisite. For organizations still scoping their approach, our consultation service starts with the audit this guide describes, before a single record moves.
Talk to our team about scoping a Salesforce data migration that gets the fundamentals right the first time.
