7 Salesforce Migration Pitfalls That Will Cost You Time and Money

Data migration is one of those tasks that looks deceptively simple. You've got data in System A, you need it in Salesforce. How hard can it be?

After handling dozens of migrations — from small CSV imports to multi-million-record enterprise moves — I can tell you: the technical work is the easy part. It's the planning, validation, and edge cases that trip people up.

Here are the seven most common pitfalls I see, and how to avoid them.

1. Not Mapping Relationships Before You Start

The biggest mistake is treating records in isolation. You can load 100,000 Accounts perfectly, but if your Contacts don't map to the right Accounts because you didn't preserve the external IDs, you've just created 100,000 orphaned records.

Fix: Map every relationship before you write a single line of migration code. Create a dependency diagram. Load parent objects first, always.

2. Ignoring Validation Rules and Triggers

Your Salesforce org has validation rules, required fields, and triggers that fire on insert. Your legacy data almost certainly doesn't conform to all of them.

Fix: Audit every validation rule and trigger before migration. Decide whether to temporarily disable them (risky but sometimes necessary) or clean your data to comply (safer, takes longer). Document everything you disable and re-enable.

3. Underestimating Data Cleanup Time

"We'll clean the data during migration" is the most expensive sentence in Salesforce consulting. Budget at least 40% of your migration time for data cleansing. That means deduplication, standardising formats (UK postcodes, phone numbers, date formats), and handling nulls.

Fix: Start data profiling early. Use tools like DataLoader with sample batches to identify issues before the full load.

4. No Rollback Plan

What happens when your Saturday morning cutover goes wrong at 2pm? If your answer is "we'll figure it out," you're going to have a very long weekend.

Fix: Always have a rollback plan. This means full backups before migration, documented steps to revert, and a clear decision point for when to abort. Test the rollback process, not just the migration.

5. Testing with Production-Scale Data Too Late

Your migration works perfectly with 1,000 test records. Then you run it against 2 million records and discover it takes 47 hours, hits governor limits, and times out halfway through.

Fix: Test with production-scale data as early as possible. If you can't use real production data (GDPR, etc.), generate realistic synthetic data at the same volume.

6. Forgetting About Attachments and Files

Records migrate. Files and attachments? Those need their own migration strategy. ContentDocument, ContentVersion, Attachment — Salesforce's file model has evolved over the years and it's not always obvious which one you should be using.

Fix: Inventory all files and attachments in the source system early. Decide on your target object model in Salesforce (ContentVersion is the modern approach). Account for file size limits and storage costs.

7. No Post-Migration Validation

You loaded the data, nothing errored out, job done? Not quite. Records can load successfully and still be wrong — wrong Account assignments, missing field values that weren't required, duplicate records that slipped through.

Fix: Build a validation report that runs automatically after migration. Compare record counts, spot-check key relationships, and validate critical fields. Have business users verify a random sample before you declare success.

The Bottom Line

A well-planned migration is boring. And boring is exactly what you want. The drama comes from poor planning, not from the technical work itself.

If you're facing a Salesforce data migration and want a second pair of eyes on your approach, get in touch. A 30-minute review can save you weeks of rework.