Migrating to Salesforce: A Data Migration Guide

Migrating to Salesforce is less about moving records and more about correctly mapping your data into Salesforce’s object model — standard objects, custom objects, and the relationships between them — and rebuilding your automation using Flow and Apex rather than copying logic that won’t translate directly. Teams that treat it as a pure data-export exercise usually end up with a system that holds the old data but doesn’t actually reflect the old process.

Map your data to Salesforce’s object model first

Salesforce structures data around standard objects (Account, Contact, Opportunity, Lead) plus any custom objects you build. Before migrating, decide how your source data maps onto this structure — a “Company” in your old system usually becomes an Account, but the mapping isn’t always that clean, especially for platforms with a flatter data model (a single “Contact” that combines what Salesforce splits into Lead and Contact, for example). Get this mapping documented and reviewed before any data moves, since restructuring relationships after records are loaded is far more painful than mapping correctly the first time.

In practice this means walking through every field in the source system and assigning it one of four outcomes: maps directly to a standard field, maps to a new custom field, gets combined with another field during transformation, or gets dropped because it no longer reflects the process. Teams that skip the “drop” category tend to recreate every field their old CRM accumulated over years, including the half-used ones nobody actually reports on — carrying forward clutter instead of leaving it behind. The mapping document should also flag picklist values that need normalizing (three spellings of “Enterprise” is a common find) before they become three different values in a Salesforce picklist.

Plan record types and page layouts around real usage, not defaults

If different teams or products need different fields and processes, Salesforce’s record types and page layouts handle that — but only if planned before migration, not bolted on after. Decide up front whether you need multiple record types (e.g. separate Opportunity record types for new business versus renewals) rather than migrating everything into one generic layout and retrofitting structure later.

A useful test: if two teams selling different products would answer “what fields matter on this record” differently, that’s a signal for separate record types and page layouts rather than one shared layout with optional fields everyone scrolls past. Getting this wrong in the other direction — too many record types for processes that are actually identical — creates its own maintenance burden, since every record type needs its own page layout, validation rules and often its own sales-process picklist values to keep in sync.

Rebuild automation with governor limits in mind

Workflow rules, email alerts and approval processes from another platform don’t transfer — they need to be rebuilt in Flow (and Apex where the logic requires it), and rebuilt correctly means respecting Salesforce’s governor limits from the start: bulkified triggers that handle batches of records, not one-at-a-time loops that hit API call limits under real production volume. This is the single most common place migrations that “worked in testing” break once real usage hits them.

Before rebuilding a single automation, list every workflow, notification and approval step the old system runs and mark which ones actually still reflect how the team works today versus which ones accumulated as one-off exceptions nobody remembers the reason for. Rebuilding a legacy exception exactly as it existed is how a clean Salesforce org quietly inherits the same automation sprawl the old CRM had — this is the moment to prune, not just port. For anything that touches more than a handful of records at once (a nightly sync, a mass status update), design it as a batch or queueable Apex job from the outset rather than a synchronous trigger, since that’s the difference between a job that scales and one that starts throwing limit exceptions the day record volume doubles.

Handle deduplication with Salesforce’s tools

Salesforce has built-in duplicate rules and matching rules that can catch new duplicates going forward, but they don’t retroactively clean data that’s already messy at import. Run de-duplication on the source data before migration (see the general CRM migration guide for the process), then configure Salesforce’s duplicate rules to prevent the same mess from recurring after go-live.

Matching rules typically compare on fuzzy criteria — company name similarity, email domain, phone number format — and it’s worth tuning these deliberately rather than accepting the defaults. A matching rule set too loosely flags legitimate separate accounts (two different companies that happen to share a common word in their name) as duplicates and trains users to ignore duplicate warnings entirely; one set too tightly lets real duplicates back in within weeks of go-live.

Use a sandbox — not production — to test the real migration

Salesforce sandboxes exist specifically for this: run the full migration into a full or partial sandbox first, using real (anonymized where needed) data volume, and validate reports, dashboards and automation against it before touching production. A migration that looks clean with 200 test records can behave very differently at 50,000 real ones — sandbox testing at realistic volume is the only way to catch that before go-live.

Have actual end users — not just the admin who built the migration — check their own records, pipelines and reports in the sandbox before cutover. Admins tend to check that the data loaded correctly; sales reps notice when a deal’s stage history looks wrong or a report is missing a filter they rely on daily. Budget real calendar time for this round of user validation rather than treating it as a formality between “migration complete” and “go-live” — it’s usually where the last real issues surface before they become production problems.

Plan the cutover window deliberately

Pick a specific cutover date rather than “sometime after testing wraps up.” In the days before cutover, freeze significant changes to the source system or run a delta sync so the final migration captures everything created since the sandbox test. Communicate the freeze window clearly to the whole team, not just the admins — most post-migration complaints trace back to a record created or changed during an undocumented freeze window, not to the migration logic itself. After go-live, budget at least a week of close monitoring: spot-check migrated records against the source system, confirm automation fires correctly on real new records, and verify integrations are sending and receiving data before calling the migration complete.

What a Salesforce migration typically costs

Data migration is usually the largest variable within a Salesforce implementation budget — see the Salesforce implementation cost guide for cited industry ranges by company size and the specific cost drivers, including hidden costs like sandbox/environment licensing and AppExchange package fees that a simple license-price comparison misses.

Get your migration scoped

A free 30-minute call reviews your current setup — whatever platform you’re on now — and gives you a written read on what a Salesforce migration for your specific data and process actually involves.