A Salesforce migration costs what it does mostly because of what surrounds the data, not the row count. Object and relationship complexity, data quality, files and email history, transformation rules, and the automations and integrations you must rebuild drive most of the effort. Cutover style, testing, training and overlapping licenses add the rest. Buyers who describe those drivers clearly before asking for a quote get estimates that hold up.
Why does record count say so little about migration effort?
Volume affects load runs and storage, but structure decides the work. A large flat contact list is simpler to move than a small dataset with deep parent-child links, custom objects and many-to-many relationships.
Every relationship adds a dependency to the load order. Parents must exist before children, and each child needs a reliable key back to its parent. Lookups to users, record types and queues need their own mapping tables. Some legacy systems store links loosely, such as a company name typed into a text field. Someone then has to resolve each one by rule or by hand.
Ask any partner to count objects, relationships and distinct record types alongside the row totals. That breakdown predicts effort far better than one headline number.
How much does dirty data add to the bill?
Cleansing is often the least predictable line in the estimate. Duplicates, inconsistent formats and orphaned records all need decisions before load, and every decision needs an owner on your side.
Deduplication is rarely a pure tooling task. Software can flag likely matches, but someone who knows the customers must choose survivors and settle conflicts between records. Phone and address formats, free-text country values and blank owners each need a rule. Records with no parent, such as contacts tied to a deleted company, need a home or a deliberate decision to drop them.
The cheapest cleanup happens in the source system before extraction. Archiving stale records you will never report on shrinks every later step, from mapping to testing.
Do files, attachments and email history change the scope?
Yes, often more than buyers expect. Documents and logged emails carry their own extraction quirks, storage considerations and link-back work, so treat them as a separate workstream.
Files must be pulled from the source, matched to their parent records and loaded in a form Salesforce accepts. Salesforce counts file storage separately from data storage, so a large archive can change licensing or storage purchases. Confirm current storage allowances with your Salesforce account team.
Email history raises a different question: does it need to be activity records on each contact, or can it stay searchable in an archive? Moving years of logged emails as activities is slow and seldom read again. Many teams bring a recent window into Salesforce and keep older history in a read-only store.
What makes field mapping and transformation expensive?
Mapping costs little when fields line up one to one. It grows when a single source field must split into several targets, several sources must merge into one, or values need calculation along the way.
Picklist standardization is a common hidden task. Source systems collect years of near-identical values, such as three spellings of one industry or retired lead sources still on old records. Each list needs an agreed target set and a crosswalk from every old value. Stage and status values matter most, because they feed reports and automation from day one.
Keep the transformation rules in one shared document that both teams sign off. Rules that live only in a developer's script are hard to test and hard to defend later.
How far back does history need to come?
Decide this before the estimate, because the answer can multiply the work. Current-state records are one load; field-level change history and audit trails are a different and harder problem.
Most source systems store change history in a format with no direct Salesforce equivalent. Recreating it as native history entries is generally impractical. Teams instead load it into a custom history object or keep it in an external archive. Regulated firms should check retention duties with their compliance team first. That way the plan meets the obligation without importing more than it must.
Why is rebuilding automation and integrations the biggest cost?
Data moves once, but logic has to be redesigned. Workflows, assignment rules, email sequences, scoring models and every connected system must work again in Salesforce, and that redesign usually outweighs the data load.
Legacy CRMs hide a surprising amount of logic. Some lives in configured rules, some in third-party connectors and some in scripts nobody has documented. Each item needs to be found, judged worth keeping or not, then rebuilt with Flow, Apex or an integration platform. Moving between two Salesforce orgs is not exempt, since automation built for one data model rarely fits the other unchanged.
Integrations add their own testing burden. Every connected system, such as billing, marketing automation, telephony or a data warehouse, needs new credentials, field mapping, error handling and a cutover sequence. An inventory of these links is the most valuable document you can hand a partner.
How does the cutover approach shift effort?
A single big-bang cutover concentrates risk into one window but avoids keeping two systems in step. A phased move spreads risk, yet it needs interim sync or clear rules about which system owns what.
- Big bang: one data freeze, one final load and one switch date. It suits smaller user groups and simple integration landscapes.
- Phased by team, region or object: lower risk per step, but someone must manage interim data flows and user confusion.
- Parallel running: both systems live for a defined period. It offers reassurance, but double entry wears users down and splits the truth unless the period is short.
Whichever approach you choose, plan for a delta load. Records created or changed after the main load still have to arrive before go-live.
What should testing and reconciliation cover?
Testing proves the data arrived correctly and the business still works. Budget for both checks, because a migration that loads cleanly can still break a sales process.
Reconciliation compares counts and key totals between source and target, object by object. Spot checks then confirm that relationships, owners and dates survived the trip. User acceptance testing asks real staff to run their daily work against migrated records in a sandbox. Each test cycle that finds a mapping fault means another load, so good early sample loads lower total effort.
Do training, adoption and license overlap belong in the budget?
They should. Users who are not ready drift back to spreadsheets. Paying for two platforms during the transition is also a real cost that is easy to forget.
Training should use migrated records rather than demo data, so people see their own accounts on the first day. Role-based sessions beat one general walkthrough. Licensing overlap depends on the source contract's end date and your cutover plan. Check notice periods early so the old system is not renewed by accident.
Which tools affect the estimate?
Tool choice matters less than buyers assume. Salesforce's own Data Loader handles many straightforward loads, while ETL tools or integration platforms suit complex transformations, repeatable runs and large file volumes.
The deciding questions are how often you will rerun the load, how complex the transformations are and whether the same platform will run integrations afterward. Paying for a tool that also serves ongoing integrations can make sense. Buying one only for a single load usually does not.
| Driver | What raises effort | How to reduce it |
|---|---|---|
| Object and relationship complexity | Custom objects, many-to-many links, loosely stored relationships | Simplify the target model; agree external ID keys for every parent |
| Data quality and dedupe | Duplicates, orphaned records, inconsistent formats, no data owner | Clean and archive in the source; name a business owner for match decisions |
| Files and email history | Large archives, files linked to many records, years of logged emails | Set a cutoff date; archive older items in a read-only store |
| Mapping and transformation | Split or merged fields, calculated values, undocumented rules | Keep one signed-off mapping document; drop fields nobody reports on |
| Picklist standardization | Many near-duplicate values, retired values on old records | Agree target value sets early; build a crosswalk per field |
| History and audit | Field-level change history, regulatory retention duties | Load history to a custom object or archive; confirm duties with compliance |
| Automation rebuild | Hidden rules, undocumented scripts, scoring and routing logic | Inventory every rule; retire what no longer serves the process |
| Integration rebuild | Many connected systems, custom connectors, real-time sync needs | List each integration with owner, direction and frequency |
| Cutover approach | Phased moves needing interim sync, long parallel runs | Pick the simplest approach that fits risk; keep parallel runs short |
| Testing and reconciliation | Repeated full loads after late mapping faults | Run early sample loads; define reconciliation checks up front |
| Training and adoption | Generic sessions, demo data, no change champions | Train by role on migrated records; appoint champions per team |
| License overlap | Source contract renewing during transition | Check notice periods and align the cutover date |
What should you send a partner for an accurate migration quote?
Send facts about the source, not just the target vision. The more of this list you can answer, the narrower the range a partner can give you.
- Source system names and versions, plus any secondary tools holding customer data
- Object list with row counts, custom objects and how they relate
- Volume and type of files, attachments and logged emails, with a proposed cutoff date
- Known data quality issues and who on your side will make dedupe decisions
- History and audit retention requirements, confirmed with compliance where relevant
- An inventory of workflows, scoring, routing and scripts in the source system
- Every integration, with direction, frequency and the system owner
- Preferred cutover approach and any blackout periods for the business
- Number of users by role and how training should be delivered
- Contract end date for the current system and Salesforce licenses already owned
What do real migrations show about these drivers?
Abstrakt case studies show the same drivers in different shapes. Each project below differed in source system, scope and what had to be rebuilt.
- A PE-backed compliance-software firm left HubSpot for Sales Cloud plus Marketing Cloud Account Engagement. The migration covered accounts, contacts, leads, opportunities, tasks and activities. The team also connected Chili Piper and Gong and added CRM Analytics dashboards.
- A cybersecurity company replaced Nutshell and a homegrown ticketing tool with Sales Cloud and Service Cloud. It moved 2,300 accounts and contacts and used a crawl-walk-run rollout rather than one switch.
- A renewable-energy company replaced MailChimp with Account Engagement connected to its Sales Cloud org. Over 29,000 prospects were moved and deduplicated in the process, backed by regular hands-on training.
- A regional bank replaced ActiveCampaign with Marketing Cloud Account Engagement synced both ways with Salesforce. Custom prospect fields, a campaign hierarchy and suppression lists rebuilt its segmentation and compliance logic.
In each case the data load was only one part of the work. Rebuilding automation, integrations, scoring and segmentation made up much of the scope.
