Salesforce Data Migration: The 2026 Plan (Tools, Cost, Step-by-Step)

Posted by Maxim Orlovsky

Updated May 22, 2026

A Salesforce data migration is rarely what people expect at the start. Teams plan it as just moving data, but find it also involves structure, ownership, and checking accuracy. If you plan it wrong, you spend months fixing broken records, missing dates, and inactive agents still showing up in your reports.
​
This guide is the exact plan our team has used with over 40,000 companies that have migrated to Agentforce Service (Salesforce) through Help Desk Migration since 2016. It covers the five phases, load order, tool tradeoffs (manual CSV, Salesforce Data Loader, Skyvia, Help Desk Migration, and managed services), realistic timelines, and the validation work that determines whether your first Salesforce Monday is calm or a fire drill.
​
If your source system is a help desk like Zendesk, Freshdesk, Intercom, HelpDesk, or Dixa, a dedicated section appears near the end. This path follows different rules from a typical CRM-to-Salesforce migration, and mos

TL;DR

What is Salesforce data migration?

Salesforce data migration is the process of moving records—customers, contacts, cases, attachments, KB articles, and custom objects—from a source system into Salesforce Sales Cloud or Service Cloud. It includes data extraction, cleansing, field mapping, loading, and post-migration validation.

You typically need one of these:

• A greenfield migration — your team is new to Salesforce and importing initial data from spreadsheets, a legacy CRM, or a help desk.
• A switch from another platform — moving from Zendesk, Freshdesk, HubSpot, ServiceNow, or another CRM into Salesforce.
• A Salesforce Classic to Lightning migration — a UI/data-model upgrade inside Salesforce.
• An org consolidation — merging two or more Salesforce orgs after an acquisition.

This guide focuses on the first two — most readers are planning a switch from another help desk platform to Salesforce.

Your Salesforce data migration plan in 5 phases

Big consulting firms offer 10-step plans. In reality, five steps determine if you move clean customer data or spend your first month fixing problems.

Phase 1 — Scope and inventory

Begin by counting records, not matching fields. Count tickets, contacts, accounts, attachments, knowledge base articles, and custom items from every source. Note how old the records are — data older than 3 to 5 years usually does not need to be moved.

The result of this step is a table showing record counts and a written decision about what to move ("we migrate active customers, the last 3 years of cases, and the full KB").

Phase 2 — Data cleansing and preparation

Clean your data before moving it, not after. Once messy data is in Salesforce, automatic processes run on every change, and users start working. Fixing problems while running is expensive. Remove duplicate contacts, fill required fields, delete test records, archive closed and inactive cases, and decide what to do with inactive agents.

Use Help Desk Migration's Salesforce data migration checklist. It has 47 items and catches most problems before migration.

Phase 3 — Field mapping

Create a mapping document. Each source field is shown in a row with its name, type, matching Salesforce object, target field name, required changes, and responsible person.

Most projects quietly fail here. Salesforce field types are strict. A free-text "Status" in Zendesk must become a Salesforce picklist value already in your system. Create the picklist values first, then map them.

Phase 4 — Migration (trial, then full)

Begin with a Demo Migration by moving 20 random tickets and articles. Validate the migration results and identify any broken records or fields. Test everything on a small, easy-to-handle dataset before it influences live data. Then initiate the Full Data Migration.

With Help Desk Migration, the pilot is the Free Demo migration — it runs automatically, uses real records from your source, and lands them in your Salesforce instance. You can also run it in a Sandbox environment to avoid mixing real and test records.

Phase 5 — Validation and post-migration monitoring

Before going live: count records in the source and target, check 20 records to ensure field mappings match, confirm that lookups work, run a sample report, and compare it to the source. After going live, watch for two weeks for missing records, failed automations, and drops in data quality.

Plan a Delta Migration for the final hours before cutover — it syncs any records created or updated in the source during your validation.

Salesforce data migration tools compared

There are three main types of Salesforce data migration tools: manual CSV file import, built-in Salesforce tools, and third-party automated services. The best option depends on how much data you have, where it comes from, and how much technical help you have.

A few honest notes on the tradeoffs.

Using a manual CSV file is fine for moving a few thousand contacts just once. But it does not work well for linked data, attachments, or important past information.

Salesforce Data Loader is free, but it is an admin tool, not a migration tool. You can design the load order, rebuild data relations, and handle errors. It is useful for ongoing data work, but clunky for a one-time data import with a deadline.

Skyvia is an adaptable ETL platform. If you want a single tool that handles Agentforce Service migration, warehouse syncs, and ongoing data work, it may be a good choice. The trade-off for Agentforce Service import is that knowledge base records, side conversations, CCs, and inline images each require their own migration packages. You also have to manually map created_at to Salesforce's import API field to keep timestamps. Plan for 4–6 packages and a few days of mapping work.

Help Desk Migration is help-desk-native and designed for this exact job. The Wizard Migration handles tickets, public/private comments, KB articles, side conversations, CCs, inline images, attachments, agents, organizations, and customers in one pass. Timestamps, legacy IDs, and statuses are preserved automatically. Pricing is per-record, one-time, with a non-linear curve that drops the price per record as volume grows.

Object load order — why dependencies matter

Salesforce records have parent-child dependencies. Load them out of order, and your lookups break — the contact loads, but its account_id points at nothing, and Agentforce Service silently sets it to null.

The standard load order for a Sales Cloud migration:

1. Accounts (parent of nearly everything else)
2. Contacts (require an Account)
3. Leads (independent — can load in parallel with Contacts)
4. Opportunities (require an Account and usually Contacts)
5. Activities (Tasks, Events — point at Accounts/Contacts/Opportunities)
6. Attachments / Files (point at any of the above)

For a Service Cloud migration from a help desk, the equivalent order is:

1. Users / Agents (so tickets have valid owners)
2. Accounts / Organizations
3. Contacts / Customers
4. Cases (the ticket equivalent) — with public and internal comments
5. Knowledge articles
6. Attachments and inline images

How long does a Salesforce data migration take?

A Salesforce data migration takes anywhere from a few hours to 8–16 weeks. The driver isn't tool choice — it's record volume, custom-field count, integration complexity, and the amount of validation time the business allocates.

The rough timelines for Agentforce Service migration with Help Desk Migration:

• SMB (under 50,000 records): 4 to 24 hours of migration runtime; 2 to 3 days total, including prep work and verification of migration results.
• Mid-sized migration (50,000 to 500,000 records): 1 to 3 days of migration runtime; generally, 1 to 2 weeks.
• Enterprise migration (500,000+ records): 2 to 7 days of migration runtime; 2 to 6 weeks total, including phased transfers and two Delta Migrations.

A managed consultancy will quote 8 to 16 weeks for the same enterprise scope — most of that time is discovery and assessment, not migration. Automation compresses it because the work that's repeated for every migration (field detection, schema mapping, error handling) is built into the tool.

Cost of a Salesforce data migration

Three pricing models dominate the market: per-record one-time, per-month subscription, and per-project consultancy. They look comparable in headline numbers and differ wildly in total cost.

• Per-record automated service charge based on the volume migrated. Help Desk Migration is ~$1,600–$2,000 for 100,000 records, one-time. The per-record rate drops as volume grows.
• Monthly subscription tools (Skyvia or Fivetran) can cost $79-$159 per month for the advanced mapping tier. This model seems affordable at first, but a complex data migration can take 3 to 6 months, and the subscription keeps charging afterward.
• Project-based services start from $15,000, with mandatory assessments costing $5,000 to $10,000. Worth it if your schema is genuinely complex; expensive overkill if it isn't.

A useful test is to add up your total expected cost over the entire migration timeline, not just the first month. Subscription tools look cheaper per month but cost more per project for one-time work.

Salesforce data migration best practices

Seven rules from teams that have shipped clean Salesforce migrations.

Common Salesforce migration mistakes (and how to avoid them)

Six patterns we see again and again in projects that come to us mid-disaster.

• Wrong load order. Loading contacts before accounts causes lookups to return null values. Fix: load parents first and verify with a count query before moving to the next layer.
• Dirty source data includes duplicate contacts, empty required fields, and deleted end-users. Fix: cleanse data before migration. The Agentforce Service migration checklist covers common issues.
• No rollback plan. A migration that cannot be reversed forces companies to transfer corrupted data, as the alternative is to start over. Fix: Take a Salesforce sandbox snapshot before the load and document a reversion path.
• Validation rules and triggers can glitch during Full Migration. They were written for one-at-a-time data entry, not for a 100,000-record upload. Fix: Temporarily turn them off during the Full Migration, then re-enable after.
• Missing custom field mapping. A migration that "succeeded" but dropped 80 custom fields is a failed migration that users will discover later. Fix: Explicitly match custom fields and validate that the target picklist values exist before the Full Migration.
• No UAT before going live. "It migrated fine" is not validation. Fix: Verify at least 50 records and compare them on the Source and Agentforce Service. Then have a real user try out the Target platform before the final cutover.

Migrating a help desk platform to Agentforce Service

Help desk data is not CRM data. Tickets, side conversations, knowledge base articles, agent histories, and customer support context need different handling than accounts and opportunities — and most generic Salesforce migration guides skip this entirely.

Here's the short version by source platform. Each link points to the dedicated migration page, which includes the field-level mapping table and a Free Demo path.

From Zendesk

Zendesk to Salesforce Service Cloud migration →

Here is how Zendesk records migrate to Agentforce Service: Zendesk tickets become Salesforce cases. Public comments become case comments, and internal notes map to internal case comments. Knowledge base articles move into Salesforce Knowledge, along with categories and sections. CCs, inline images, and attachments also transfer. Side conversations transfer as private comments. Call recordings migrate as MP3 attachments. Agents map to Salesforce users, and customers become contacts.

From Freshdesk

Freshdesk to Salesforce Service Cloud migration →

Freshdesk tickets become cases, while agents migrate as users to Agentforce Service. Public and private notes map to case comments. Companies become Salesforce accounts; contacts become contacts. As for knowledge base migration, categories and folders are converted into top- and second-level categories.

Custom fields, tags, and attachments transfer. Inline images migrate as attachments. Moreover, you can also migrate content translations and update cross-links between articles with automated options.

From HelpDesk, Intercom, Dixa, and others

See all supported sources →

The migration pattern is the same: tickets become Cases, conversations become Comments, and KB content becomes Knowledge. You can check the mapping tables and demo flows on each platform-pair page.

Case study: Pandora

See how Pandora migrated from Zendesk to Salesforce →

Pandora, the world's largest jewelry brand, needed to migrate years of customer support data from Zendesk to Agentforce Service (Salesforce Service Cloud) without a single minute of downtime. At their scale, any disruption could cost millions.

The result? A seamless, zero-downtime transition that gave Pandora's agents a unified 360-degree view of every customer's purchase history, repair claims, and past interactions was included.

Ready to migrate to Salesforce?

Most of the work in a Salesforce data migration is decisions: scope, mapping, load order, and validation criteria. The actual migration, if you're using an automated tool that understands help desk data, is hours, not weeks.

Start with a Free Demo migration. Help Desk Migration moves 20 real records from your source into your Salesforce sandbox so you can see exactly how tickets, comments, KB articles, and attachments will look in Agentforce Service before you commit to the Full Migration. No credit card, no sales call required.

Have a complex schema or a regulated industry? Talk to a Migration Expert →

Frequently Asked Questions