Data Migration in Salesforce: What a Failed Migration Actually Costs to Fix

Every guide about data migration in Salesforce tells you how to do it right. Almost none of them tell you what happens when it goes wrong, or what the cleanup actually costs. We think that gap matters. At VALiNTRY360, a meaningful share of our migration work is rescue work: orgs where the load already happened, something broke, and the team is trying to figure out how bad it is.

So this article prices the damage. We’ll rank the 8 most common migration failures from cheapest to most expensive to fix, show you when repairing beats re-migrating, and walk through exactly what to do in the first 72 hours after you find a problem.

One note before we start. The hour ranges and dollar figures in this article are our own planning estimates, drawn from rescue projects we’ve delivered. Use them for budgeting conversations. Your numbers will move with your record volume, org complexity, and how long the problem sat undetected.

TL;DR

The Repair Bill Nobody Publishes

Every top-ranking guide teaches you how to migrate. This article prices what happens when the load goes wrong, ranking the 8 most common Salesforce migration failures from cheapest to costliest to fix, with hour ranges drawn from real rescue projects rather than theory.

Why Waiting Is the Most Expensive Decision

Your real worry is the meter you can’t see. Repair quotes are roughly 12% of the true bill; productivity drag and slipped deals carry the rest, and every month a problem sits undetected, multiplying the total cost up to 10x once evidence windows close.

Triage First, Then Repair or Re-Migrate

Act inside 72 hours: pause jobs, preserve the Recycle Bin and Bulk API files, then scope with record counts. Under 20% of records affected, repair wins; past 40%, re-migrate. VALiNTRY360 runs this exact triage-to-verified-repair sequence for orgs whose migrations already went sideways.

What Counts as a Failed Data Migration in Salesforce

Failure rarely announces itself with an error screen. In our experience, data migration in Salesforce fails in 4 distinct ways, and each one carries a different price tag.

A loud failure is embarrassing, but it’s the cheapest of the 4. Nothing bad reached production, and you fix the job and rerun it. Silent corruption sits at the other end. Wrong picklist values, split duplicates, and orphaned records blend into daily work, and by the time someone notices, months of new activity is layered on top of the mess. Trust collapse is the failure nobody budgets for. Once reps find 2 or 3 wrong records, they stop trusting all of them, export their pipeline to spreadsheets, and adoption craters. You can repair records in weeks. Rebuilding user trust takes quarters.

The pattern that drives everything else in this article: repair cost scales with discovery time. Keep that in mind as you read the rankings below.

Why Fixing a Failed Migration Costs More Than the Original Project

Teams are often shocked that a rescue quote exceeds the original migration budget. It usually should. A first migration moves data once. A rescue has to diagnose, untangle, and rebuild while the business keeps writing new records into the same org.

The bill stacks up in 5 layers:

•     Diagnostic work: reconciling source against target to find out what’s actually wrong
•     Repair labor: the hands-on fixing, merging, reparenting, and re-loading
•     Productivity drag: every hour your reps and service agents lose working around bad records
•     Opportunity cost: deals that slip because pipeline data was wrong at the moment it mattered
•     Compliance exposure: legal and audit costs when regulated data landed in the wrong place

Consulting labor is usually the smallest of the 5. Gartner puts the average cost of poor data quality at $12.9 million per organization per year, and in a broken org most of that leaks through productivity drag and bad decisions, quietly, before anyone opens a repair ticket.

Discovery time then multiplies everything. Here’s the planning rule we use when scoping a rescue for data migration in Salesforce environments:

The multiplier climbs for 3 mechanical reasons. Salesforce keeps deleted records in the Recycle Bin for only 15 days before scheduling them for permanent deletion. Bulk API job results are deleted after 7 days, which means the error files that would tell you exactly which records failed simply vanish. And every day of normal use writes new records on top of migrated ones, making it harder to separate what the migration broke from what users created since.

That’s why the single most valuable thing you can do after a suspect migration costs nothing: check early, while the evidence still exists.

The 8 Most Common Salesforce Migration Failures, Ranked by Repair Cost

This is the comparison most content about data migration in Salesforce skips entirely. Below are the 8 failure modes we see most often in rescue projects, ordered from cheapest to most expensive to fix.

For each one, we cover what it looks like, why it happens, what the repair involves, and whether repairing or re-migrating is usually the right call. Hour ranges are our planning estimates for a mid-size org of roughly 100 to 300 users.

1. Field Mapping and Picklist Errors

What it looks like: state fields holding “FL,” “Fla,” and “Florida” as free text. Phone numbers in 6 formats. Text silently truncated because the source field was longer than the target. Dates shifted by time zone.

Why it happens: the mapping specification was incomplete, or nobody validated transformed values against Salesforce picklists before loading.

What the fix involves: export the affected objects, normalize values in a transformation pass, and mass update. Tedious, but mechanical, and it rarely requires business judgment.

Typical repair effort: 20 to 60 hours.

Repair or re-migrate: repair, almost always. As failures go in data migration in Salesforce work, this is the one that’s genuinely cheap to fix if you catch it early, which is exactly why it sits at the bottom of the cost ranking.

2. Ownership and Access Problems

What it looks like: 40,000 records owned by the integration user. Reps who can’t see their own accounts. Territory assignments and sharing rules that no longer match reality.

Why it happens: the load ran under a single admin credential without an ownership mapping table, or role hierarchy changes went live mid-project.

What the fix involves: build the ownership map that should have existed before the load, mass transfer records, then recalculate sharing. The technical work is straightforward. Getting sales leadership to sign off on who owns what is the slow part.

Typical repair effort: 30 to 80 hours, plus management time.

Repair or re-migrate: repair. Ownership is metadata about records, so there’s nothing to re-load.

One warning from experience: don’t transfer ownership in a single giant batch. Ownership changes fire assignment rules and sharing recalculations, and a full-org transfer on a Tuesday afternoon can lock users out for hours. Run it in waves, off-hours.

3. Automation Collisions

What it looks like: 15,000 “welcome” emails sent to long-standing customers overnight. Thousands of junk tasks assigned to reps. Roll-up fields and lead scores corrupted because flows fired on every inserted record.

Why it happens: triggers, flows, validation rules, and email alerts were left active during the load. It’s one of the most preventable failures in data migration in Salesforce projects, and one of the most common.

What the fix involves: inventory every automation that fired, identify the side effects per record, delete the generated junk, recalculate roll-ups, and send an honest apology to any customers who got spammed.

Typical repair effort: 40 to 120 hours, heavily dependent on how many automations fired.

Repair or re-migrate: repair for the side effects. If the automations also modified the loaded records themselves, parts of the load may need a clean re-run.

4. Duplicate Explosion

What it looks like: the same hospital system appearing 4 times, each copy holding a different slice of contacts, opportunities, and history. Reports that double count revenue. Marketing emailing the same person 3 times.

Why it happens: no matching rules were defined before the load, or multiple sources were merged without a survivorship plan deciding which system wins for each field. Duplicates are the failure mode users notice first, so they do outsized damage to trust in any data migration in Salesforce effort.

What the fix involves: define matching logic, run merge waves, and make survivorship calls record by record for the accounts that matter. Merging is slow because every merge is a judgment, and Salesforce merges have side effects on related records that need checking.

Typical repair effort: 60 to 150 hours, plus real business-user time to adjudicate matches.

Repair or re-migrate: repair. Re-migrating doesn’t help, because the duplicates exist in the source. You’d load the same problem twice.

5. Lost Activity History and Notes

What it looks like: accounts with no emails, calls, or notes before go-live day. Reps walking into renewal conversations blind because 5 years of relationship memory didn’t make the trip.

Why it happens: activities are high-volume and awkward to map, so teams cut them from scope to hit a deadline, or loaded them without resolving their parent records first.

What the fix involves: everything depends on whether the source extracts still exist. If they do, activities can be transformed and loaded against the new record IDs. If the source system was decommissioned and no extracts were kept, that history is gone, and no budget recovers it.

Typical repair effort: 50 to 160 hours when extracts exist. Unrecoverable when they don’t.

The painful version we see most often: the legacy CRM subscription was cancelled 30 days after go-live to save money, and the problem surfaced on day 45. Keep read access to the source system, or a complete extract of it, for at least 12 months.

Repair or re-migrate: targeted re-load of the missing objects. This is also the loudest argument for keeping full source extracts for at least a year.

6. Broken Parent-Child Relationships

What it looks like: contacts orphaned from their accounts. Opportunities pointing at nothing. Cases detached from the customers who raised them. Roll-ups, forecasts, and account 360 views all quietly wrong.

Why it happens: records were loaded in the wrong order, or the load relied on Salesforce IDs instead of stable external IDs, so the keys connecting objects broke in transit. Relationship integrity is the hardest part of data migration in Salesforce to get right, because objects have to land in dependency order with their keys intact.

What the fix involves: rebuild the relationship keys from the source system using external ID fields, then reparent records in dependency order. Each wave has to be verified before the next starts, because reparenting mistakes compound.

Typical repair effort: 80 to 200 hours.

Repair or re-migrate: repair if the source keys survive. If they don’t, a partial re-migration of child objects is usually cleaner than guessing at relationships.

7. Silent Data Loss

What it looks like: nothing, for a while. Then a rep asks where a customer went. Reconciliation reveals that 8% of records never arrived because batches failed mid-load and nobody read the error files before the 7-day results window closed.

Why it happens: no source-to-target reconciliation was run at go-live. Success was declared because the job finished, and finishing is a much weaker claim than loading everything.

What the fix involves: a full reconciliation of source counts against Salesforce counts per object, then a targeted re-load of what’s missing. The reconciliation is the expensive part, and it can’t be skipped, because you can’t fix what you haven’t measured. Detecting this failure is exactly what makes data migration in Salesforce risky to declare done without count-level verification.

Typical repair effort: 100 to 250 hours.

Repair or re-migrate: usually a partial re-migration of the missing slices, gated behind reconciliation.

A useful habit even outside a crisis: after any large load, pull the failed-record files the same day and store them somewhere permanent. They cost nothing to save and everything to lose.

8. Compliance Exposure

What it looks like: patient identifiers loaded into unencrypted free-text fields. Consent and opt-out flags dropped in transit. Records retained past the limits your own policies promise regulators.

Why it happens: nobody with regulatory knowledge reviewed the mapping. Compliance was treated as a legal checkbox instead of a set of field-level decisions, which is a common blind spot in data migration in Salesforce projects run by teams without regulated-industry experience.

What the fix involves: locating every affected field, remediating or purging data, documenting what happened, and involving counsel. GDPR Article 5 requires personal data to be accurate and kept no longer than necessary, and for healthcare organizations the HIPAA Security Rule sets safeguards for electronic health information that don’t pause because a migration made a mess.

Typical repair effort: 120 to 300+ hours, plus legal review that we won’t pretend to estimate for you.

Repair or re-migrate: sometimes a forced, clean re-migration is the only defensible answer. This is the most expensive failure on the list, and the only one where the meter keeps running after the data is fixed.

How the 8 Failures Compare at a Glance

Two things stand out in this table. First, the failures users complain about loudest, like duplicates, are mid-priced, while the quiet ones at positions 7 and 8 cost the most. Second, the “usual call” column shifts from repair to re-migration as you move down because the deeper the structural damage, the less trustworthy in-place fixes become.

Repair or Re-Migrate: How to Make the Call

Once you know which failures you’re dealing with, the next decision in any broken data migration in a Salesforce project is whether to fix records in place or wipe affected objects and load again. Here’s how the factors line up.

The one that trips teams up is new data. Once users have spent weeks creating and editing records, a wholesale re-migration would overwrite their work, so repair becomes the only realistic path even when it’s slower.

Our stance: if under 20% of records are affected and the source extracts survive, repair wins almost every time. Between 20% and 40%, run the numbers both ways before committing.

The First 72 Hours After You Find the Problem

What you do in the first 3 days determines whether this is a contained fix or a quarter-long crisis. The sequence matters more than speed.

1.   Stop the bleeding. Pause integrations, scheduled jobs, and mass updates touching the affected objects so the problem stops spreading.
2.   Preserve the evidence. Export the Recycle Bin before the 15-day purge, download every Bulk API error and result file before the 7-day deletion, and take a full snapshot of current state with a tool like Salesforce Data Loader.
3.   Scope with counts, not anecdotes. Compare source record counts against Salesforce counts for every migrated object. One rep’s complaint is a symptom. Counts are a diagnosis.
4.   Freeze schema and automation changes. Every config change made mid-diagnosis makes the eventual repair harder to verify.
5.   Classify what you’re seeing against the 8 failures above. Most broken orgs have 2 or 3 of them at once, and the combination changes the repair order.
6.   Make the repair-or-re-migrate call using the table in the previous section, and write the decision down with its reasoning.

Communicate honestly with users during these 3 days. A short note saying “We found a data issue; here’s what’s affected, and here’s when we’ll have answers,” preserves far more trust than silence followed by a surprise cleanup weekend.

One thing not to do: mass-delete anything on day one. Deletion feels like progress, and it destroys the evidence you’ll need 48 hours later. In a rescue, data migration in Salesforce follows a rule borrowed from medicine: diagnose before you operate.

What a Rescue Actually Costs: A Worked Example

Numbers make this concrete. Here’s a composite scenario modeled on rescues we’ve delivered, showing what a broken data migration in Salesforce costs end to end, with every figure labeled as our estimate.

The setup: a 150-user org migrated from Microsoft Dynamics to Salesforce. Six weeks after go-live, the team confirms 3 of the failures above: a duplicate explosion on accounts, orphaned opportunities, and partial activity loss.

Look at where the money sits. The consulting labor everyone negotiates over is about 12% of the bill. The productivity drag and slipped revenue nobody puts on a purchase order make up the rest. That ratio is the real argument for moving fast. Every week of delay barely changes the repair quote and massively grows the drag underneath it.

DIY Cleanup or a Rescue Partner: A Side-by-Side Look

Plenty of failed migrations get fixed in-house, and some should be. If your team has run data migration in Salesforce before and the damage is contained, doing it yourself is a legitimate option. Here’s an honest comparison to help you place your situation.

Our honest guidance: keep failures 1 and 2 in-house if your admin has bandwidth. They’re mechanical and low-risk. For failures 6 through 8, where mistakes compound and evidence expires, experienced help pays for itself, and the worked example above shows why: shrinking the drag matters more than shrinking the hourly rate.

How to Keep It From Happening Again

The cheapest rescue is the one you never need. Once your org is stable, these 5 moves protect the next load, because there’s always a next load.

Treat reconciliation as a go-live gate. No data migration in Salesforce should be declared complete until source and target counts match per object and a sample of records passes field-level checks. Finished jobs are not the same thing as complete data.

Put governance in place before the next project. Matching rules, validation standards, and field ownership are exactly what our Salesforce data governance services establish, and they’re dramatically cheaper to set up than to retrofit after a failure.

Audit your org on a schedule. A periodic Salesforce health check catches duplicate creep, broken automations, and permission drift while they’re still small findings instead of rescue projects.

Fix the architecture that caused the failure. If your data model made the mapping ambiguous, a data strategy and architecture engagement addresses the root cause rather than the symptom. And if Salesforce needs a continuous feed from your ERP, a properly built ERP integration with Salesforce beats repeated bulk loads that each carry migration-level risk. For analytics use cases, real-time data access can eliminate some bulk data movement entirely.

Keep hygiene continuous. Ongoing Salesforce managed services and support means duplicates get merged and load errors get read monthly, and your team can build shared standards with free resources like Salesforce’s own data quality module on Trailhead.

How VALiNTRY360 Fixes Failed Migrations

We’ve spent 12+ years on data migration in Salesforce and the wider platform work around it, and our Salesforce data migration services cover both sides of that work: doing migrations right the first time, and repairing the ones that went wrong elsewhere.

Our rescue engagements follow the same sequence this article laid out. We triage and preserve evidence first, reconcile source against target to scope the real damage, make the repair-or-re-migrate call with you using explicit criteria, then execute in verified waves with count-level proof at each step.

A few things make us a strong fit for this specific problem. Our team is 100% US-based and Salesforce certified, which matters when the broken data includes regulated records that can’t leave the country. We work extensively with healthcare and life sciences organizations, so HIPAA-aware field handling is part of how we operate, and our Salesforce implementation services background means we fix the configuration that let the failure happen instead of just the records it damaged.

And if you’re earlier in the journey and still planning your move, our Salesforce consulting services team would much rather help you build the reconciliation gates now than meet you in a rescue later.

If your migration already went sideways, the evidence windows in this article are ticking. Talk to our team and we’ll help you scope the damage before the 15-day and 7-day clocks run out.

The Bottom Line

The cost of a failed migration is mostly invisible. Consulting hours are the small, visible slice, and productivity drag, slipped deals, and eroded trust are the large, hidden one, growing every week the problem sits. So move early. Preserve the evidence, scope with counts, classify against the 8 failures, and make the repair-or-re-migrate call deliberately. Handled that way, a failed data migration in Salesforce is a bounded project with a known price instead of a slow leak with an unknown one. And whichever path you take, we’re here for both the rescue and the prevention.

FAQs

1. How Long Does It Usually Take to Recover From a Failed Salesforce Data Migration?

Recovery time depends on record volume, data complexity, affected objects, integrations, and whether reliable source data still exists. A contained issue may take days, while complex recovery involving multiple objects, automations, and integrations can take several weeks.

2. Can a Failed Salesforce Migration Be Fixed Without Taking the System Offline?

Yes, many migration issues can be repaired while Salesforce remains available. Teams often isolate affected objects, pause selected automations or integrations, and complete corrections in controlled batches to reduce disruption while preserving normal business activity wherever possible.

3. Should Salesforce Migration Recovery Be Tested in a Sandbox First?

Yes. Testing recovery steps in a sandbox helps confirm mappings, transformation logic, relationship updates, automation behavior, and expected record counts before production changes are made. This lowers the risk of creating new issues during an already sensitive recovery project.

4. What Information Should I Provide to a Salesforce Migration Rescue Team?

Useful materials include source extracts, migration mappings, import logs, error files, object lists, integration details, automation documentation, backup files, and known user complaints. The more evidence available, the faster a rescue team can isolate root causes and scope remediation.

5. Can Salesforce Attachments, Files, and Notes Be Recovered After a Migration Problem?

Often, yes, if the original files, source system, or migration extracts are still accessible. Recovery usually requires matching files and notes to the correct Salesforce records, validating ownership and permissions, and confirming that links or relationships were preserved correctly.

6. How Do You Verify That a Repaired Salesforce Migration Is Actually Complete?

Validation should compare source and target record counts, field values, relationships, ownership, permissions, attachments, and key reports. Teams should also test representative business workflows so repaired data supports sales, service, reporting, and automation as expected after recovery.

7. Can Custom Salesforce Objects Make Migration Recovery More Difficult?

Yes. Custom objects often include unique relationships, validation rules, automation, dependencies, and business logic that standard migration tools may not handle cleanly. Recovery requires understanding how those custom structures interact before records are corrected or reloaded.

8. What Happens to Integrations During Salesforce Migration Recovery?

Integrations may need to be paused, throttled, or temporarily redirected while affected data is corrected. Otherwise, connected systems can reintroduce bad records or overwrite fixes. Recovery planning should include every integration that reads from or writes to affected objects.

9. Can Salesforce CPQ or Revenue Cloud Data Be Repaired After a Bad Migration?

Yes, but these environments require extra care because quotes, products, price books, contracts, subscriptions, and related records are highly interconnected. Recovery must preserve relationship order, pricing logic, and downstream automation before users resume normal quoting or billing activity.

10. How Do Large Salesforce Data Volumes Affect Migration Recovery?

Large data volumes increase reconciliation time, batch planning, API usage, testing requirements, and the risk of partial updates. Recovery teams typically work in smaller verified waves, monitor limits closely, and use repeatable scripts or ETL tools instead of manual corrections.

11. Can a Failed Migration Affect Salesforce Reports and Dashboards Even When Records Look Correct?

Yes. Reports may still be inaccurate if ownership, record types, dates, lookup relationships, currency fields, or hidden values were mapped incorrectly. Recovery should validate reporting outputs separately rather than assuming correct-looking records automatically produce trustworthy analytics.

12. Can Salesforce Migration Recovery Affect API Limits or System Performance?

Yes. Large correction jobs can consume API calls, trigger automation, increase locking, and slow production activity. Recovery teams should schedule batches carefully, monitor platform limits, and control concurrency so remediation does not create avoidable performance problems for users.

13. Can Migration Recovery Preserve Changes Users Made After Go-Live?

Yes, but those changes must be identified and protected before corrections begin. A careful recovery process distinguishes migrated records from post-go-live edits, then applies targeted updates so recent sales, service, and customer activity is not accidentally overwritten.

14. Do I Need a Full Salesforce Backup Before Starting Migration Recovery?

A fresh backup is strongly recommended before remediation begins. It provides a rollback point if repair steps create unexpected results and preserves the current production state for comparison. Backups should include affected records, relationships, metadata, and important files.

15. What Should We Monitor After a Salesforce Migration Has Been Repaired?

After recovery, monitor import errors, duplicate growth, automation failures, integration exceptions, unusual ownership changes, missing relationships, report variances, and user-reported issues. Scheduled reconciliation and data-quality checks help confirm the repair remains stable as new records enter Salesforce.