The Definitive Guide to Migrating to Salesforce

Salesforce, Inc. was founded by former Oracle executive Marc Benioff in March 1999 and is headquartered in San Francisco, California ¹. For fiscal year 2026 the company reported $41.5 billion in annual revenue, and Sales Cloud sits at the centre of a broader stack that includes Service Cloud, Marketing Cloud, Revenue Cloud, Tableau, Slack and the Agentforce AI layer ¹.

The typical Sales Cloud customer is a mid-market or enterprise revenue team — usually 100 to 10,000+ users — that needs deep customisation through Apex code, Flow, Validation Rules and a Role Hierarchy / Sharing Rules access model. Compared with HubSpot or Pipedrive, Salesforce positions on configurability and ecosystem depth rather than time-to-value; compared with Microsoft Dynamics 365, it positions on the AppExchange marketplace and a wider partner network.

The shapes of migration that actually land on Salesforce fall into four patterns. First, legacy consolidation: spreadsheets, Act!, SugarCRM, on-prem Microsoft Dynamics, or a homegrown SQL database where the source schema is loose and the project is really a re-architecture. Second, competitor exits from HubSpot, Pipedrive, Zoho or Insightly when the customer outgrows the source tier or needs Apex-level customisation ¹³¹⁴.

Third, multi-org consolidation, where two or more Salesforce orgs from past M&A activity are merged into one — typically the hardest shape because both sides carry incompatible Record Types, Sharing Rules and Apex Triggers. Fourth, platform standardisation, where a parent enterprise standardises acquired business units onto a single Sales Cloud org.

What makes migrating *to* Salesforce harder than the category average is the automation that runs on insert. Validation Rules, Apex Triggers, Workflow Rules, Process Builder and Flow all evaluate every imported record, and a workflow that expects a 10-digit phone number breaks the moment legacy data shows up with a country code ²². Most migration teams disable automation during the load and re-enable it post-cutover.

What makes it easier than the average is the External ID field type — a first-class upsert mechanism on every object, capped at 25 external IDs per object, that lets you match records by a value from the source system rather than by Salesforce's 18-character Record ID ³. Combined with the platform's job-based async loader and the load order discipline that External IDs enforce, the platform rewards teams that plan their upsert keys before writing a single row.

Apex Triggers, Flows, Validation Rules and Reports do not import — they are rebuilt from documentation. Teams that scope for that work up front finish on time; teams that assume parity do not.

The destination has a richer automation layer than the source, and it fires on every imported row unless you actively quiet it.

Salesforce's data model is built around Standard Objects (Account, Contact, Lead, Opportunity, Case, Campaign and others), Custom Objects you define yourself, and a Relationship model that includes Lookups, Master-Detail relationships and Junction Objects for many-to-many cases.

Before you can map a field, you need to know which Standard Object the row belongs on, which Record Type applies inside that object, which required fields the page layout enforces, and which field you will use as the External ID for upsert. The table below summarises the objects you will touch in a Sales Cloud migration.

Salesforce assigns an 18-character Record ID (the canonical primary key) to every record on insert. You cannot set Record IDs on import — they are system-generated. The migration pattern is to use External ID fields instead: up to 25 custom fields per object (auto-number, email, number or text type) that you flag as External ID and use as the upsert match key ³.

Mark the External ID as *Unique* and case-sensitive to prevent silent duplicate merges. The async loader references the External ID by name in the job payload; if the value exists, the row updates, if not it inserts.

Relationships come in three shapes. Lookup is a loose one-to-many — deleting the parent does not cascade. Master-Detail is a tightly-coupled one-to-many where the child inherits ownership and sharing from the master and is deleted with it. Junction Object is a custom object with two Master-Detail relationships used to model many-to-many — OpportunityContactRole is the standard example connecting Opportunities to Contacts. Custom field types determine validation and storage; the catalogue below covers what you can model.

Record Types add a second axis: one Custom Object can have multiple Record Types, each with its own Page Layout, picklist value subset, and required-fields list. A Lead inserted with the wrong Record Type silently displays the wrong fields to the rep on day one — and the value RecordTypeId on every imported row decides which one it lands on.

Custom Objects participate in relationships exactly like Standard Objects, with the same Master-Detail cascade and Junction Object patterns. Big Objects (the platform's archive tier) default to 1 million records — you contact your Account Executive to raise that ceiling, and they are not used for active migration loads ¹¹.

The single best predictor of a clean Sales Cloud migration is how much work you do on the source side before the first load job is submitted. Practitioners consistently report that field-mismatch breakage is not really about the fields — it is about the Validation Rules, Apex Triggers and Flows that fire on every imported row and reject anything the legacy data does not perfectly match ²².

Disable Validation Rules and Triggers during the load, then re-enable and run regression tests. Most migration teams skip the regression step — and pay for it on day five.

Treat the source export as raw material shaped to Salesforce's expected formats — email validated, phone normalised to international format, picklist values converted to the destination's exact case-sensitive values, dates rewritten to ISO-8601, owner emails resolved to Salesforce User IDs.

Source-side prep

• Audit and dedup the source before export — Cloudingo, DemandTools and Plauti Duplicate Check are the Salesforce-native dedup tools most teams reach for, and they catch fuzzy-match duplicates that Salesforce's built-in Matching Rule and Duplicate Rule will silently merge during insert ²⁵.
• Stamp a stable External ID on every record in the source export — the legacy primary key, a UUID, or a composite key — and create a custom field on each destination object marked *External ID* + *Unique* + case-sensitive to land it ³.
• Convert picklist values to the exact destination case — Salesforce restricted picklists enforce strict ENUM matching and reject any typo, casing difference or trailing space with bad value for restricted picklist field. Build a transform table per picklist.
• Resolve owners by exporting your destination Salesforce User list (User.Id, Username, FederationIdentifier) and joining it to the source owner column. Rows whose OwnerId cannot be resolved fall to the integration user, which silently breaks owner-based Sharing Rules.
• Decide what is in scope for historical activities. Tasks and Events can be inserted with backdated ActivityDate, but they archive automatically after 365 days and the IsArchived flag is not updatable directly ¹⁶.

Destination-side prep

• Create a Full Sandbox (or Partial Copy on lower editions) from Setup → Sandboxes — a Full Sandbox copies production data and metadata for end-to-end dry-runs and the refresh interval is 29 days ¹⁷.
• Provision users first, ideally through your identity provider (Okta or Microsoft Entra ID), and assign Permission Sets and Profiles before the load — Apex Triggers reference running user context and ownership assignment silently falls to the integration user if a referenced User does not yet exist.
• Deploy every custom field, Record Type, Page Layout and picklist value to production via a deployment tool before importing — fields created in the destination after a row arrives cannot be back-populated cleanly.
• Disable Validation Rules, Workflow Rules, Process Builder Flows and Apex Triggers that should not fire on bulk insert (or wrap them in an Trigger.New0.Bypass__c = true skip flag pattern). Re-enable post-cutover with a regression test plan ²².
• Pre-create Pricebooks, PricebookEntries and Products before any OpportunityLineItem load — a Line Item targeting a missing PricebookEntry fails with INVALID_OR_NULL_FOR_RESTRICTED_PICKLIST and the row is rejected.

People prep

Cutover works only when humans cooperate. Lock down a source-system freeze window — typically 24 to 72 hours — and communicate it to every department touching the CRM. Train sales reps on Sales Cloud daily workflows, Opportunity stage management and List Views before go-live, not after. A clean legacy-CRM migration of under 25,000 records often lands in a week; a multi-org consolidation with Apex rebuild and Pricebook reconciliation runs four to twelve weeks.

Salesforce exposes multiple load paths and the right one depends on dataset size, object mix, and whether you need to re-run idempotently. Data Import Wizard covers small, simple loads on a handful of objects. Data Loader and Workbench cover the medium tier. For programmatic, repeatable and very large loads, Data Loader's async mode (or a third-party iPaaS) takes over. Third-party tools sit on top of all of them.

Data Import Wizard

The native UI tool lives at Setup → Data Import Wizard and supports a deliberately limited set of objects: Leads, Accounts, Contacts, Campaign Members, Solutions, Person Accounts and Custom Objects. It does not support Opportunities, Cases or Products — for those you escalate to Data Loader. The record limit is 50,000 per import, file format must be CSV with UTF-8 encoding (not UTF-8 BOM, not ANSI), and dates must be in the org's locale format.

The Wizard's killer feature is built-in Duplicate Rule + Matching Rule enforcement on Accounts and Contacts — but that same feature silently blocks rows that should pass, so know to set the Allow Duplicates flag explicitly when the source rows are legitimately new ²⁵. Use the Wizard for one-shot loads under 50,000 records on supported objects, or any time you want a visual mapping review.

Data Loader and Workbench

Data Loader is the desktop app (Windows/macOS) that ships from Salesforce. It supports every Standard and Custom Object, runs Insert / Update / Upsert / Delete / Hard Delete / Export operations, and supports both interactive and CLI modes for scheduled jobs. Workbench is the browser equivalent — useful for one-off jobs without local install.

Large-volume async loading

For programmatic, repeatable and very large loads, Data Loader can be configured to use the platform's async load mode. The job model is: create an ingest job with operation (insert/update/upsert/delete) and object, upload CSV data, then mark the upload complete to enqueue. Salesforce auto-chunks server-side — you do not size batches yourself.

Per-transaction limits compound on top: 100 SOQL queries and 150 DML statements per transaction — relevant because Apex Triggers firing on your import consume those quotas. Bulk operations also share a daily submission cap, so naive code that submits tiny batches will exhaust the daily allocation ²⁷.

Third-party staging tools

Dataloader.io (web Data Loader from MuleSoft), Skyvia, Talend, Informatica Cloud, Jitterbit, MuleSoft Anypoint and ETL platforms like Fivetran, Airbyte and Stitch all handle Salesforce loads. For one-time migrations the value is repeatability under failure and built-in schema mapping; for ongoing syncs they become the system of integration. Most enterprise migrations end up on MuleSoft or Informatica when the source database is on-prem and the company already has an iPaaS licence.

Mapping is where every Salesforce migration earns its scars. The schema decisions you make in your mapping spreadsheet determine whether Reports work on day two, whether Validation Rules accept user edits on day five, and whether your sales team trusts the data on day thirty.

Work object by object, top to bottom of the load order: Users first (already done in prep), then Accounts, then Contacts, then Leads, then Opportunities, then OpportunityLineItems, then Tasks/Events, then Custom Objects. Load order matters because every child row needs a parent External ID that already exists.

Account

Contact

Opportunity and pipeline stages

Recreate every Sales Process and every Opportunity stage in Salesforce before importing Opportunities. Each stage has a StageName value, a ForecastCategoryName, a numeric Probability and a Boolean IsClosed / IsWon. Stage history is preserved in OpportunityHistory, which is read-only — you cannot insert historical stage transitions directly. To preserve the timeline, populate custom datetime fields like Stage_Entered_Qualification__c from the source.

Opportunities that target a stage value not present in the assigned Record Type's Sales Process are rejected with bad value for restricted picklist field. Map source stages to destination stages explicitly per Record Type.

Custom-field mapping strategy

Resist the urge to map every source custom field one-to-one. Enterprise Edition caps Custom Fields at 500 per object, Unlimited at 800. Migrate only fields used by an active Validation Rule, Apex class, Flow, Report or List View in the last 12 months. Excess fields waste field allocation, slow down Page Layouts and clutter Search results.

For picklist fields where source values do not match the destination, either: (1) extend the destination picklist with the missing values *before* loading, (2) collapse adjacent values during transform, or (3) introduce a parallel custom Text field that holds the legacy value verbatim. Formula and Roll-Up Summary fields do not import — Salesforce recomputes them on-platform — so any source formula must be rebuilt as a Salesforce formula field after schema deploy.

Historical activities — Tasks, Events, Notes, Emails

Salesforce models activities through the virtual Activity parent object and two concrete children: Task (calls, completed work, to-dos) and Event (meetings) ¹⁶. Both support backdated ActivityDate and a WhoId (Lead/Contact) and WhatId (Account/Opportunity/Case) lookup pair that places the activity on the related record's timeline.

Critical gotcha: Tasks and Events archive automatically after 365 days, moving to the ArchivedActivity shadow table — and the IsArchived flag is not updatable, so you cannot insert records pre-archived ¹⁶. Older historical activities sit in live storage until Salesforce's nightly archive job catches up, which means a 5-year activity backfill briefly counts against your full data storage allocation.

Files and attachments

Salesforce has two file frameworks: the legacy Attachment object (25 MB cap per file, no metadata customisation) and the modern Files framework built on ContentVersion + ContentDocument + ContentDocumentLink (10 GB cap per file in Lightning Experience, full metadata support). New migrations should always land on Files.

The migration pattern is: upload a binary as a ContentVersion with the file body as VersionData (base64) and Title, capture the returned ContentDocumentId, then link it to the parent record via a ContentDocumentLink row. For large attachment estates (TBs), most teams keep originals in S3 or Azure Blob and store a deep link in a custom URL field on the Salesforce record — only the most-recent or most-referenced subset inlines.

Audit trail, ownership and original timestamps

By default Salesforce stamps CreatedDate, CreatedById, LastModifiedDate and LastModifiedById on insert and they are read-only. To preserve original audit trail, you submit a one-time support case requesting Create Audit Fields permission, which then lets the loader set those four fields explicitly during insert.

Once enabled, you set CreatedDate and the others in your load payload. The permission applies org-wide and is usually toggled off after migration completes to prevent users from rewriting history. Field History Tracking (which captures per-field change history) supports 20 fields per object by default; Field Audit Trail (paid add-on) extends to 60 fields per object with 10-year retention.

CRM-specific: lead scoring, email/calendar sync, Apex/Flow rebuild

Lead scoring in Sales Cloud is delivered via Einstein Lead Scoring (predictive, AI-trained on your historical conversion data) or via custom scoring formulas. Neither imports from the source — Einstein needs at least 1,000 converted leads in the destination to start scoring, and custom scoring formulas are rebuilt from documentation. If you must preserve historical scores, land them in a Legacy_Lead_Score__c custom number field and let Einstein/your new formula accrue forward.

Apex Triggers, Flows, Process Builder Processes, Validation Rules, Workflow Rules, Approval Processes, Reports and Dashboards do not import — they are rebuilt against the new schema. Process Builder is being end-of-lifed; new automation should land on Flow ¹⁷. Scope the rebuild before signing the scope.

Email and Calendar sync (Gmail/Outlook via Einstein Activity Capture, or the older Lightning Sync) is configured per user under Setup → Einstein Activity Capture *after* users and OwnerIds are stable. Enabling it during the import window backfills duplicate emails against the contacts you are still loading.

Validation is the bridge between the loader returning success and users being allowed in. Salesforce data-migration practitioners recommend a three-stage validation: a test load of 10 percent of records in a Full Sandbox with department-rep spot-checks, the full production load with real-time monitoring of partial-success counts, and a 30-day post-migration data-quality audit using DemandTools or Cloudingo to surface the merges the Matching Rule did silently³⁴.

Build a reconciliation queries spreadsheet that compares source and Salesforce on each of the counts below. Anything outside a 0.5 percent variance gets investigated before login access opens.

• Total Accounts inserted vs source, minus deliberately-excluded rows (test accounts, deactivated, role-based) — use SOQL SELECT COUNT() FROM Account WHERE Legacy_Account_ID__c != null to count only migrated rows.
• Total Contacts per Account spot-check — pick 20 high-value Accounts and verify Contact counts match source, catches Matching Rule merges that collapsed two distinct prospects.
• Total Opportunities per Stage per Record Type plus sum of Amount per Pipeline — a non-trivial dollar variance usually signals a stage-mapping error or a currency precision drop on multi-currency orgs.
• Total Tasks + Events per ActivityDate bucket vs source — confirm backdated ActivityDate round-tripped and the rows did not archive prematurely.
• OpportunityLineItem rollup: sum TotalPrice per Opportunity vs source line-item total — catches missing PricebookEntry references.
• OwnerId distribution — SELECT OwnerId, COUNT(Id) FROM Opportunity GROUP BY OwnerId and confirm no record landed on the integration user that should not have.
• External ID uniqueness — SELECT Legacy_Account_ID__c, COUNT(Id) FROM Account GROUP BY Legacy_Account_ID__c HAVING COUNT(Id) > 1 should return zero rows.

On top of reconciliation, run a manual spot-check protocol: pick 30 random records across objects and verify each field against the source UI. Pick five high-value Opportunities and trace the full graph — Account, Contacts, Line Items, Tasks, Quotes. If a non-trivial discrepancy shows up in three or more of the 30, halt the load, fix the root cause (almost always a Trigger or Validation Rule), and re-import the affected rows by Legacy_ID via Data Loader upsert.

Salesforce's native Recycle Bin holds deleted records for 15 days and can be used for small-scale undo from the UI ³⁴. Undoing an Import under Setup is available only for Data Import Wizard imports launched within the last 24 hours and only deletes records the import created ³⁴. For Data Loader there is no built-in undo — you delete by Legacy_Import_Batch_ID__c custom field and re-import from the cleaned source.

The rollback strategy practitioners actually use: full org backup via Salesforce Data Export (Setup → Data Export) or a third-party backup tool like Odaseva or OwnBackup *before* the migration starts, plus stamping every imported row with an Import_Batch_ID__c custom text field, so catastrophe means a SOQL delete by batch ID followed by re-import from clean source ³⁴.

Cutover sequencing: (1) source goes read-only and team is notified; (2) final delta export captures everything that changed during the sandbox-test window; (3) delta upsert via Data Loader using Legacy_ID External IDs; (4) reconciliation queries run; (5) Validation Rules and Triggers re-enabled with regression test pass; (6) users get login access and a 48-hour hyper-care window; (7) source decommission scheduled 30 to 90 days out, never same day.

The Salesforce Partner Program tiers consulting firms by Navigator certifications, Customer Satisfaction (CSAT) scores and Salesforce-credentialed engineer count. The named tiers are Global Strategic, Summit, Summit+, Crest and Ridge. 70 percent of Salesforce implementations are delivered through Partners rather than direct, and most non-trivial migrations end up with one.

Deloitte Digital, Accenture, Capgemini, IBM and Slalom dominate the global Strategic tier for enterprise multi-cloud rollouts. For mid-market Sales Cloud migration projects specifically, Summit-tier partners with explicit competitor-exit practices (Salesforce-from-HubSpot, Salesforce-from-Pipedrive, Salesforce-from-Microsoft Dynamics) tend to ship cleaner than generalist implementation shops. Salesforce also runs Professional Services in-house — typically the most expensive option but the one with deepest product-team access.

On the ETL and iPaaS side, MuleSoft (Salesforce-owned) is the default for enterprise integration with on-prem source systems, Informatica Cloud is common in regulated industries, and Fivetran, Airbyte, Stitch and Workato cover the warehouse-first stack. Their role in a migration is rarely the migration itself — it is the staging layer that lands source data, the transformation layer that converts picklist values and resolves OwnerIds, and the ongoing-sync layer that takes over once the one-time migration completes.

Dataloader.io and Skyvia sit in the lighter tier, useful for one-shot loader runs without writing code. Cloudingo and DemandTools handle the dedup-and-cleanse pass before insert.

Managed-migration cost ranges vary widely. A clean Pipedrive- or HubSpot-to-Salesforce move of under 25,000 records, standard objects only, no historical activities, typically lands in the $20,000–$60,000 range depending on data volume and the business-process re-mapping required. A multi-org consolidation with deal history, Custom Objects, OpportunityLineItem reconstruction and Apex/Flow rebuild runs $60,000–$500,000+, driven by record count, custom-field complexity, and integrations that need rebuilding ¹³.

For teams that want to outsource the migration end-to-end, FlitStack specialises in Salesforce migrations and handles the External ID schema design, async loader orchestration, Validation Rule and Trigger bypass setup, restricted-picklist transformation, historical-data preservation, and the reconciliation work described in Sections 5 and 7 of this guide. Pricing is fixed-fee, based on record count and source platform, with separate line items for Custom Objects, Apex/Flow rebuild scope and historical activity depth so the scope is transparent before signature.

This is one of several legitimate paths — the right choice for any given team depends on whether they want a Summit Partner with a wider services footprint, Salesforce Professional Services with deepest product-team access, an iPaaS-first approach via MuleSoft, or a specialist migration vendor focused on the load itself. Explore FlitStack →