Executive Summary
Choosing between Pardot, Marketing Cloud Engagement, and the newer Data Cloud editions is less about industry and more about how you win customers. This guide compares these four distinct Salesforce marketing platforms, maps each to the buying motion they fit best, and walks through the decision framework so you pick the right tool for your go-to-market strategy.
Quick links
- What "Done" Actually Means
- Phase 1: Data Audit and Discovery
- Phase 2: Object Model and Load Order
- Phase 3: Field Mapping and Transformation
- Phase 4: Deduplication and Cleansing
- Phase 5: Tooling Selection
- Phase 6: Build, Configure, and Load
- Phase 7: Validation and Reconciliation
- Phase 8: Cutover and Go-Live
- Phase 9: Rollback and Contingency
- Preflight Checklist
- Frequently Asked Questions
What "Done" Actually Means
Before any Salesforce data migration checklist, agree on the finish line. “The data is in Salesforce” is not it. A Salesforce data migration is done when four things are true:
Every record is accounted for. Every record that should have moved is present and reconciled against a verified count from the source system.
Every relationship is intact. No orphaned contacts, no opportunities pointing at nothing, no broken links between parent and child records.
The data is clean enough to use. Users adopt the system instead of working around it. They trust the numbers.
All of the above is provable with numbers. Not vibes or spot checks—reconciliation reports and validation queries. Write these acceptance criteria down with stakeholders at the start. They drive the validation phase later and keep scope from quietly expanding.
The Salesforce Data Migration Lifecycle at a Glance
Run these nine phases in sequence. Each one has a checklist below. The order matters: skipping discovery to save a week is the single most common way teams add a month later.
- Data audit and discovery
- Object model and load order
- Field mapping and transformation
- Deduplication and cleansing
- Tooling selection
- Build, configure, and load
- Validation and reconciliation
- Cutover and go-live
- Rollback and contingency
Salesforce data migrations rarely live in isolation. If yours is part of a larger build, it should plug into your Salesforce implementation plan. If the legacy system stays live after go-live, you’ll also need an integration to keep the two in sync rather than a one-time Salesforce data migration.
Phase 1: Data Audit and Discovery
You can’t migrate data you don’t understand. For every source system feeding your Salesforce data migration, the audit answers four questions: what data exists, how much of it there is, how clean it is, and how it relates to everything else. Skip this phase and you’ll discover the answers during the load, at the worst possible time.
Profile Every Source
Inventory the sources.List every system holding CRM data: the legacy CRM, spreadsheets, the ERP, a billing tool, marketing automation, support inboxes. Shadow data in spreadsheets is where surprises hide.
Count the volume. Record counts per object and table. Volume drives tool choice, timeline, and your Salesforce data migration strategy. 40,000 contacts is a Data Loader afternoon. 40 million is an ETL project with a different risk profile.
Profile data quality. For each field, measure fill rate, distinct values, and format consistency (dates, phone numbers, country codes, currencies). Watch for obvious junk (“asdf,” “test,” “n/a”). Profiling tools or a few SQL GROUP BY queries expose this fast.
Map relationships. Document parent-child links and foreign keys. Which table holds the owner? How are contacts tied to companies? Where do orphans already exist in the source? You’ll rebuild these in Salesforce, so you need the wiring diagram now.
Decide What Not to Migrate
Not all legacy data deserves a new home in your Salesforce data migration. Bringing everything across inflates cost, storage, and deduplication effort. It also pollutes a fresh org with noise.
Run a selection workshop with sales, service, and marketing. Sort every dataset into migrate, archive, or discard. Common candidates for archiving: leads untouched for 3+ years, closed-lost opportunities older than your reporting window, contacts with no valid email and no activity.
For borderline data, archive to cold storage (a database export or a data lake) so it’s recoverable without living in Salesforce and slowing down your Salesforce data migration.
Audit Output
Before moving to Phase 2, produce: a source inventory, per-object record counts, a data-quality scorecard per field, a relationship map, and a documented migrate/archive/discard decision for every dataset. If you can’t produce these, you’re not ready for Phase 2.
Phase 2: Object Model and Load Order
Salesforce enforces referential integrity. A child record can’t point to a parent that doesn’t exist yet, so your Salesforce data migration must load in dependency order or the load fails. Get the order and the linking strategy right and everything downstream in your Salesforce data migration gets easier.
Use External IDs and Upsert, Always
This is the most important technical decision in any Salesforce data migration. Create an external ID field on each object (a unique, indexed text field) and populate it with the record’s primary key from the source system—for example, Legacy_Id__c.
Two things follow. First, you load with upsert instead of insert, so re-running a Salesforce data migration job updates existing records instead of creating duplicates. This makes loads safely repeatable.
Second, you link children to parents by the parent’s external ID rather than its Salesforce ID. You don’t have to wait for the parent load to finish and harvest its new IDs before loading children in your Salesforce data migration.
The Canonical Load Order
Adjust for your custom schema, but this is the backbone for a standard Sales Cloud or Service Cloud Salesforce data migration:
| Order | Object | Depends On | Notes |
|---|---|---|---|
| 1 | Users | None | Load or activate users first so ownership and audit fields resolve. Where a source owner has no Salesforce user, map to a designated migration user. |
| 2 | Accounts | Users | Parent of most records. Set the external ID here first. |
| 3 | Contacts | Accounts | Link by Account external ID. Watch for contacts with no account. |
| 4 | Leads | Users | Independent of accounts. Decide convert-later vs migrate-as-is. |
| 5 | Products and Price Books | None | Must exist before opportunity line items. |
| 6 | Opportunities | Accounts, Users | Map stages and close dates. Link to account by external ID. |
| 7 | Opportunity Line Items, Quotes | Opportunities, Products | Load only after both parents exist. |
| 8 | Cases | Accounts, Contacts | Link to parents. Map status and origin picklists. |
| 9 | Activities (Tasks, Events) | Any Parent (WhoId, WhatId) | Load after all possible parents so polymorphic links resolve. |
| 10 | Files and Attachments | All Parent Records | ContentVersion, then link via ContentDocumentLink to parent Salesforce IDs. |
| 11 | Custom Objects | Their Lookups | Sequence by dependency. Junction objects load after both parents. |
Two traps live in this Salesforce data migration sequence. Activities and other polymorphic objects (anything with a WhoId or WhatId) must come last because they can point at several object types. And files migrate in two steps: load the binary as a ContentVersion (base64-encoded), then create ContentDocumentLink records to attach each file to its parent by Salesforce ID, which means you need the parent IDs first.
Phase 3: Field Mapping and Transformation
The mapping document is the contract between the old world and the new one in your Salesforce data migration. For every field you’re migrating, it defines where it comes from, where it goes, what type it becomes, and how it transforms on the way. Build it in a spreadsheet and have business stakeholders sign off, because mapping is a business decision dressed as a technical one.
A mapping row in practice:
| Source Field | Source Type | Target Field | Target Type | Transformation |
|---|---|---|---|---|
| company_name | Text | Account.Name | Text | Trim whitespace, fix casing |
| acct_id | Integer | Account.Legacy_Id__c | External ID (Text) | Cast to string |
The two columns that matter most for your Salesforce data migration: “Transformation” (what business logic applies) and “Notes” (why this field matters or where it goes wrong).
Phase 4: Deduplication and Cleansing
Duplicates in your Salesforce data migration are worse than gaps. They’re invisible and they compound downstream. Every tool and process from here out assumes you deduped in staging.
Define matching rules in your Salesforce data migration. Are two contacts duplicates if they have the same email, or the same name and company? Document the rule, then run it against every source system and the merge you’ll apply. Salesforce has Matching Rules and Duplicate Rules that can run during load as a safety net.
Cleanse as you go for your Salesforce data migration. Fix obvious data quality issues—truncate whitespace, standardize country codes, convert legacy picklist values to Salesforce equivalents—in staging before the load.
Phase 5: Tooling Selection
For most Salesforce data migration scenarios, Data Loader handles the core objects well and it’s free. Use the Salesforce Data Import Wizard only for small, standard-object loads.
Reach for an ETL or iPaaS tool when you have complex transformations, multiple sources, or ongoing delta syncs as part of your Salesforce data migration. Plan around Bulk API 2.0 for very high-volume asynchronous data processing across large datasets in your Salesforce data migration.
Your tooling choice for the Salesforce data migration should support upsert on external IDs and be able to capture the IDs of inserted records so you have a precise delete list for rollback.
Phase 6: Build, Configure, and Load
Salesforce data migrations at scale require deliberate execution. Build your load jobs in a staging sandbox first and run them end to end. Capture timings. Watch for errors.
Before production load, deactivate automation in your Salesforce data migration window: validation rules, Flows, triggers, duplicate rules, assignment rules. Bulk loads can trigger these unless they are intentionally bypassed or disabled. Create a Salesforce data migration user with a trigger/Flow bypass permission set so that user’s loads skip automation entirely.
Enable the Set Audit Fields upon Record Creation permission before your Salesforce data migration if you need to preserve original created dates and record owners. This is usually the right call for an accurate historical record.
Phase 7: Validation and Reconciliation
Reconciliation is the proof your Salesforce data migration worked. Run it immediately after the load completes while everything is fresh.
Count every object. The source said 50,000 accounts; do you have exactly 50,000? Account for any intentional deltas (records you chose not to migrate). Query for orphans. Run your acceptance criteria against the migrated data and sign off with the business.
Spot-check relationships. Pull a random sample of 50 opportunities. Do they link to real accounts? Do the owners exist? Do the amounts and stages make sense? This is where gut-check validation catches things the automated checks miss.
Phase 8: Cutover and Go-Live
The cutover window for your Salesforce data migration is the moment from when you take the legacy system read-only until users log into Salesforce and start work. Have a written runbook. Name owners. Be clear about the point of no return.
Run your validation suite one more time against production. If anything fails, you have the rollback decision tree ready.
After Go-Live: Stabilize and Decommission
The Salesforce data migration isn’t finished when users log in. The first days decide whether the data stays clean.
Reactivate automation deliberately. Turn validation rules, Flows, triggers, and duplicate rules back on in a controlled order. Confirm each behaves as expected against live data.
Recalculate sharing and roll-ups. Bulk loads can leave sharing recalculations and roll-up summaries pending. Trigger and verify them so visibility and totals are correct for every user.
Run hypercare. Stand up a short, intensive support window. Triage data questions fast. Track issues so patterns are visible. Monitor performance. Watch for slow reports or list views caused by skew or missing indexes and address them.
Decommission on a schedule, not impulsively. Keep the legacy system read-only for an agreed period as a reference and a fallback for your Salesforce data migration, then retire it once you’re confident.
Phase 9: Rollback and Contingency
Salesforce does not provide a native transaction-wide rollback mechanism for large, multi-object migrations. Rollback has to be planned.
Before production load, take a full point-in-time backup using Salesforce Backup & Recover or a third-party backup platform like Gearset, Own, or Spanning.
Capture the Salesforce IDs of every record your Salesforce data migration inserts so you have a precise delete list. Know the Recycle Bin recovery window. Rehearse the reversal in a sandbox before cutover so you know how long it takes and what the process looks like.
Build a decision tree: at what point in the Salesforce data migration window do you stop and roll back instead of pushing forward? Name the owner of that decision. Hard deletes bypass the Recycle Bin and are not recoverable through native Salesforce restoration methods, making pre-migration backups critical.
A Modern Question: What Belongs in CRM, and What Belongs in Data Cloud
A few years ago every byte went into CRM objects. That’s no longer the obvious choice for a Salesforce data migration. High-volume behavioral and engagement data (web events, product usage, clickstream) often belongs in Salesforce Data Cloud, where it’s unified and resolved to a profile, rather than stuffed into custom objects that bloat your org and slow it down.
Before you migrate, ask which data your users and automation actually need as transactional CRM records, and which is better held in Data Cloud and surfaced when needed. Getting this split right keeps the CRM lean and your reporting fast.
The Preflight Checklist: Run This Before You Load Production
One consolidated list to walk top to bottom in the days before cutover. If any item is unchecked, you’re not ready to load production data for your Salesforce data migration.
Discovery and Design
- Source inventory complete, with per-object record counts
- Data-quality scorecard done per field (fill rate, formats, junk)
- Migrate / archive / discard decision signed off by the business
- Relationship map documented across all sources
- Acceptance criteria and reconciliation targets agreed
Mapping and Data Prep
- External ID field created and populated on every object
- Field mapping document complete and stakeholder-approved
- Picklist and record-type value maps defined, with defaults
- Owner and user mapping resolved, including inactive users
- Set Audit Fields permission enabled where history matters
- Deduplication and cleansing completed in staging, survivorship rules documented
Load Readiness
- Tooling selected and confirmed to support upsert on external IDs
- Load order finalized for your full object model
- Automation deactivation list prepared (validation, Flows, triggers, dupe rules, assignment rules)
- Trigger and Flow bypass mechanism in place for the migration user
- Full Salesforce data migration rehearsed end to end in a sandbox, and timed
Safety Net
- Full point-in-time backup taken and confirmed restorable
- Inserted-ID capture process confirmed for every batch
- Rollback rehearsed in sandbox, with a written decision tree and named owner
- Go-live runbook written, with owners, times, and a point of no return
- Validation suite ready to run against production immediately after load
Want this as a working document? VALiNTRY360 runs this exact preflight as a Salesforce data migration audit before any production load. Request a migration audit and we’ll pressure-test your plan against your real data before anything moves.
The Bottom Line on Salesforce Data Migration
A Salesforce data migration succeeds or fails before the first record loads. The teams that go live cleanly are the ones that profiled their data, mapped it deliberately, deduped in staging, loaded in dependency order with automation off, validated against real targets, and walked into cutover with a rehearsed rollback in their back pocket.
The load is the easy part. The checklist is the hard part. It’s also the part that protects the years of customer history you’re moving.
If you’d rather not run all of this for the first time on your own production org, that’s exactly what we do. VALiNTRY360 handles Salesforce data migration as a disciplined, audited process, whether it’s a standalone move or part of a larger Salesforce implementation. We keep legacy systems in sync through integration services when a clean one-time cutover isn’t an option.
Before you move a single record, get a second set of eyes on the plan. Request a migration audit and we’ll run this preflight against your actual data, flag the risks, and tell you honestly whether you’re ready to load.
Frequently Asked Questions about Salesforce Data Migration
It depends almost entirely on data volume and quality, not record count alone. A clean, single-source move of standard objects can take a few weeks. A multi-source Salesforce data migration with heavy cleansing, custom objects, and delta cutover runs months. The audit in Phase 1 is what lets you estimate honestly.
For most CRM migrations, Data Loader handles the core objects well and it’s free. Use the Data Import Wizard only for small, standard-object loads. Reach for an ETL or iPaaS tool when you have complex transformations, multiple sources, or ongoing delta syncs as part of your Salesforce data migration. Plan around Bulk API 2.0 for very high-volume processing.
Two layers. First, dedupe in staging before the load using clear matching and survivorship rules. Second, load with upsert keyed on an external ID so re-runs update instead of insert. Configure Salesforce Duplicate Rules as a safety net for anything that arrives later in your Salesforce data migration.
Yes. Enable the Set Audit Fields upon Record Creation permission before loading and include CreatedDate, CreatedById, and the last-modified fields in your mapping. Resolve every owner to a valid user, and store the original owner in a custom field if you need the history from your Salesforce data migration.
Not natively—there’s no undo button. Rollback has to be planned: take a full point-in-time backup first, capture the Salesforce IDs of every record you insert so you have a precise delete list, know the Recycle Bin recovery window, and rehearse the reversal in a sandbox before cutover.
Usually not. Bringing everything across inflates cost and clutters a fresh org. Sort data into migrate, archive, and discard during the audit phase. Archive borderline data to cold storage so it stays retrievable without living in Salesforce and slowing your Salesforce data migration.
Data skew occurs when too many records share the same parent, creating lock contention during your Salesforce data migration. Common sources: all opportunities under one account, all cases owned by one user. Monitor for skew during load and use Salesforce data skew guidance to mitigate with batch strategies or custom indexes.
Dedup in staging during Phase 4 using clear matching rules. Pick a survivorship rule (which version of the record “wins” and what fields carry over). Document the rule so the business understands which data you’re keeping in your Salesforce data migration. After dedup, validate that the count matches your new baseline.
Build a picklist mapping table during Phase 3. The source system’s “Closed/Lost” might map to Salesforce’s “Lost.” The source “N/A” might drop (null value) in Salesforce. Define defaults for unmapped values so your Salesforce data migration doesn’t fail silently. Test the mapping on a small batch first.
Both add complexity. For multi-currency, map the legacy currency code to Salesforce currency, and let Salesforce handle conversion and reporting. For multi-entity, decide whether each entity is a separate Salesforce instance or a single org with Salesforce territory or sharing rules. The decision shapes your whole Salesforce data migration architecture.
Yes, but plan for it. Files migrate in two steps: ContentVersion (binary), then ContentDocumentLink (relationship to parent). Attachments require the ParentId (Salesforce ID of the parent record), which you’ll only have after the parent load completes in your Salesforce data migration.
Batch your Salesforce data migration loads into smaller chunks. Use Bulk API 2.0 for millions of records. If you hit governor limits on a custom trigger during your Salesforce data migration, bypass it with a trigger/Flow bypass permission set for the migration user. Monitor API usage and plan for concurrent processing carefully.
Stop and roll back. Fix the issue in staging and re-run. This is exactly why rehearsal in Phase 6 matters—you’ll discover these problems in a sandbox, not production. Your Salesforce data migration load should be repeatable and idempotent (same result every time).
Master-detail relationships are hard to change after creation, so get them right in Phase 2. In your Salesforce data migration, the child record must have a parent. Never load a child without its parent first. If the source has orphans, decide: create a placeholder parent, discard the orphan, or archive it.
Hypercare for 1-2 weeks. Monitor for data questions, performance issues, and automation surprises. Recalculate roll-ups and sharing. Reactivate automation deliberately. Keep the legacy system read-only as a fallback for your Salesforce data migration for 30 days, then decommission it once you’re confident. Keep archived data retrievable but offline.