Every published answer to this question is right, and that is exactly why they are useless together. Search it and you will be told a CRM migration costs $1,500. And $8,000. And $67,000. And $175,000. The ranges do not overlap, the articles rarely explain themselves, and you still cannot give your CFO a number.
Here is the reconciliation: those quotes are measuring three different bills. Once you separate them, the number stops moving.
The short version: budget $3,000 to $10,000 per user, all-in. A typical 15-person team lands around $85,000, and roughly half of that never appears on an invoice.
Why every published number disagrees
The disagreement is not sloppiness. It is scope, undeclared.
| What you're reading | Typical published range | What it actually covers |
|---|---|---|
| The invoice | $1,500 – $15,000 | Services to export, map, dedupe and load your records. Sometimes a basic automation rebuild. |
| The project | $12,000 – $175,000 | The above, plus integration rebuilds, custom object mapping, UAT, training delivery and post-launch support. |
| The economic cost | $40,000 – $150,000+ | The above, plus subscription overlap and the weeks your team spends being worse at their jobs. |
GetCRMConsultant publishes $1,500–$15,000 and says most small-business migrations land in the $2,500–$6,000 range. DataSovren, writing from the perspective of a COO who tried to budget one, publishes $12,000–$31,000 for a 10-user company and $67,000–$175,000 for a 50-user one. Dench models a 15-person team at $38,350–$87,350. All three are internally consistent. They are answering different questions.
Watch out
The question that exposes scope in one sentence. Ask any migration quote: "Does this include rebuilding my existing automations, or just moving contact data?" If the answer is vague, you are looking at the invoice layer priced as though it were the project layer, and you will pay for the rest later, at a worse rate.
So price all three layers. Here is what goes in each.
Layer 1: The invoice, and why it goes to zero in 2027
This is the smallest layer and the only one that is genuinely shrinking.
| Line item | Low | Typical | High |
|---|---|---|---|
| Subscription overlap (6–10 weeks, both systems) | $1,500 | $3,000 | $5,000 |
| New platform onboarding / setup fee | $0 | $1,500 | $3,000 |
| Migration tooling or per-record service fees | $200 | $1,000 | $2,000 |
| Exit, egress or export-assistance charges | $0 | $500 | $1,500 |
| Layer 1 subtotal | $3,000 | $6,000 | $10,000 |
Two of these are worth arguing about before you sign anything.
Subscription overlap is not waste, it is insurance, and you should buy more of it than feels comfortable. Practitioners who run migrations for a living recommend three to six months of parallel running, not the two weeks most plans assume. One consultant on r/CRM put the general rule bluntly: "Budget 2-3x whatever anyone quotes you, and assume 3-6 months of parallel running." An extra billing cycle on the old system is the cheapest risk control in the entire project.
Exit fees are on a clock. Article 29 of the EU Data Act phases out switching charges in stages: since January 2024 providers have only been permitted to pass through the direct costs of assisting a switch, and from 12 January 2027 switching charges are prohibited outright, a provider cannot bill you for the act of leaving. The rules cover software services, so a CRM subscription sits squarely in scope, and they apply extraterritorially: a vendor headquartered in California serving a customer in Stockholm is covered the same way a European provider is.
The Act does more than delete a line item. It sets the mechanics of an exit: you can start a switch on a maximum of two months' notice, the provider must complete it within 30 days of that period ending, contracts must state which data and digital assets are portable and which are not, and providers must support running the old and new services in parallel during transition.
By the numbers
What the 2027 date is actually worth. Exit fees have always been the smallest of the five migration cost lines, often a rounding error. So the ban does not make switching cheap. It makes the remaining cost honest, and it hands you a renewal conversation you did not previously have. If you have EU customers or entities, note which of your CRM contracts renew either side of 12 January 2027 before you negotiate anything.
If you are outside the EU, this still matters indirectly. Vendors rarely build two exit processes, and commercial teams tend to respond to a date like this before it lands rather than after.
Layer 2: The project, where discovery eats the budget
This is the labour to actually move. Whether you pay it in cash to an agency or in salary to your own team, it is the same work.
| Workstream | Hours (low) | Hours (high) |
|---|---|---|
| Discovery & process mapping | 30 | 60 |
| Data audit, dedupe, remediation | 25 | 60 |
| Field mapping, test loads, reconciliation | 30 | 70 |
| Automation & workflow rebuild | 40 | 120 |
| Reports & dashboard rebuild | 20 | 50 |
| Integration reconnection | 20 | 60 |
| UAT & cutover | 15 | 40 |
| Total | 180 hrs | 460 hrs |
At a loaded internal rate of $90/hour, or $150/hour for an agency, that is $16,000 to $69,000, with a typical 300-hour project at $115/hour landing near $34,500.
Notice what is not the biggest line. Moving records, the part everyone pictures when they hear "migration", is roughly a quarter of it. The costly work is upstream and downstream.
Discovery is the single largest line, and almost nobody quotes it separately. A migration consultant answering a small business on r/CRM was specific about why:
"The expensive part isn't the data, it's your custom objects and automation. Standard objects, contacts, and history move cleanly. The pain is every flow, validation rule, and custom-object relationship you've built since 2019, because those encode operating logic that has to be re-expressed on the new platform, not copied. Budget it as a rebuild of your logic layer, and the biggest line is discovery, figuring out what each customization actually does and whether you still need it, more than the rebuild itself." , u/KingKeystone, r/CRM
That framing has a payoff attached. If discovery is the biggest line, then doing discovery first, on your own is the cheapest lever you have, because a serious audit deletes scope. Two independent practitioners in the same thread put the same number on it: "in most migrations I've seen, a third of the customization quietly disappears," and "a big chunk of most 2019-era orgs is workarounds you wouldn't recreate." A CRM consultancy writing about portability reviews reports the same effect from the other direction, a real process review commonly removes about a quarter of the customisation from a migration scope, and that reduction compounds through testing, training and support.
Run the audit before you request a quote and you are not just better informed. You are buying a smaller project.
Layer 3: The payroll, the bill nobody invoices
Here is the layer that makes migrations feel more expensive than they were budgeted, because it is paid in salary you were already paying, for work that does not get done.
For a 15-person team where 10 are revenue-facing, at a $90,000 loaded cost per head:
| Line item | Low | Typical | High |
|---|---|---|---|
| Training delivery (15 users × 6–10 hrs) | $6,300 | $8,400 | $10,500 |
| Reduced selling capacity (10 users × 6–10 weeks × 15–25%) | $15,600 | $27,700 | $43,300 |
| Manager & ops oversight during the project | $6,000 | $10,000 | $18,000 |
| Layer 3 subtotal | $28,000 | $46,000 | $72,000 |
The middle row is the one people argue with, so be clear about what it claims: for six to ten weeks after cutover, people who sell for a living are slower at the administrative half of their job. Not useless, slower. A 20% reduction across ten revenue-facing people for eight weeks is roughly $27,700 of capacity that quietly does not exist. It never shows up on a budget line, which is precisely why it is the most under-forecast number in the entire exercise.
The full model: what a 15-person migration actually costs
| Layer | Low | Typical | High |
|---|---|---|---|
| 1. Invoice (subscriptions, fees, tooling) | $3,000 | $6,000 | $10,000 |
| 2. Project (180–460 hrs of labour) | $16,000 | $34,500 | $69,000 |
| 3. Payroll (training, capacity, oversight) | $28,000 | $46,000 | $72,000 |
| All-in | $47,000 | $86,500 | $151,000 |
| Per user | $3,100 | $5,800 | $10,100 |
Two sanity checks against reality, because a model that only agrees with itself is worthless.
A business owner on r/CRM who moved an 18-person team off Salesforce last year reported the project "took about 4 months and cost around 40k between implementation help and lost productivity", sitting just below my low band, for a team they described as less customised than average. Their annual CRM spend went from $90,000 to under $25,000, so it repaid inside a year. Separately, DataSovren's services-only figures, $31,000–$82,000 for a 25-user company, fall neatly inside my Layers 1 and 2 combined. The model holds at both ends.
The formula, if your team is not fifteen people:
All-in cost = (weeks of overlap × monthly subscription) + (project hours × loaded rate) + (revenue-facing headcount × loaded salary × weeks of ramp ÷ 52 × productivity drop)
Run it with your own numbers before anyone quotes you. A quote you can already model is a quote you can negotiate.
Here is the uncomfortable arithmetic this model exposes: for a 15-person team, the cost of moving between two off-the-shelf CRMs overlaps almost exactly with the cost of building one that fits. If a meaningful share of your $34,500 rebuild line exists only because your last platform could not model how you actually work, you are about to pay to recreate someone else's constraints on a new logo. We build custom CRMs around an existing process rather than around a vendor's object model, worth a conversation before you commit to migration number two.
What will not come out of your old CRM
Every competitor guide warns vaguely that "some activity history may not migrate." The vendors' own documentation is far more specific, and far worse. This is the part to read before you promise your team a clean move.
Salesforce. Per Salesforce's own Data Export FAQ, updated August 2026:
- Formula and roll-up summary fields are always excluded from exports. Not sometimes. Always. Every calculated field in your org is logic you must re-derive.
- Recycle Bin data is never included.
- Weekly exports are available only on Enterprise, Performance and Unlimited. Everything else is limited to one export every 29 days.
- Export files are downloadable for 48 hours, and are deleted the moment a new export is queued, even inside that window. Once removed, "there is no way for either customers or support to recover or download them."
- There is no SLA. Salesforce states a request may take longer than a week, and support cannot expedite it.
- Downloads are throttled to one file at a time with a 60-second wait between them, returning HTTP 429 if you go faster. A large org exports as many 512 MB zip archives.
HubSpot. Per HubSpot's own export documentation, updated July 2026:
- Automation does not export as automation. You can export "a spreadsheet containing information about all of your workflows" and "images of individual workflows", the individual workflow export is literally a .PNG file. You get a picture of your logic and rebuild it by hand.
- Workflow exports exclude performance data and workflow history entirely.
- Full workflow action logs are retained for 180 days.
- HubSpot states plainly that "there is no way to merge all the data between HubSpot accounts."
Tip
The one-hour test that de-risks the whole project. Before you sign anything, run one real export of your most important object and open the file. Confirm you can read it, that the fields you rely on are actually present, and that the associations survived. Teams that do this find their gaps while they still have leverage, rather than at cutover. It is also the single best piece of preparation for the 2027 portability rules, and the findings are an improvement backlog for your current platform whether you move or not.
Four decision rules practitioners actually use
Beating the cost model is easy. The harder question is whether to spend it at all. These are the heuristics that came up repeatedly from people who have run migrations, rather than sold them.
1. The 2% rule. If your CRM costs less than about 2% of top-line revenue, the saving probably will not repay the disruption. As one operator framed it on r/CRM, responding to the suggestion that an 80% cost reduction should obviously justify a move:
"If the business is spending <2% of their top line on a CRM, then even an 80% cost reduction still might not be worth the switching effort. Sometimes it's not about the cost of CRM, but instead the time and cost of humans having to adapt and relearn processes." , u/aComplicatedCanadian, r/CRM
2. Multiply the quote. The consistent advice from people who do this professionally is to budget 2–3x the quoted figure and timeline. Not because vendors lie, but because discovery reliably finds things nobody scoped.
3. Fix the process before you move it. Migrating an unexamined process buys you the same problems in a more expensive building. A veteran on r/CRM: "You likely have some wacko processes because of the Frankenstein network of systems cobbled together. Streamlining and improving the processes BEFORE you change them will help identify your true software needs. Otherwise you end up with same bad process in new software without many gains."
4. Separate structural limits from configuration limits. If the platform genuinely cannot represent your core business object, or the feature you need sits behind a tier that costs more than switching, that is structural, move. If the capability exists and nobody configured it, that is an implementation problem, and it will follow you. Only 6–10% of CRM failures are caused by the platform itself. We wrote the full diagnostic in signs you've outgrown your CRM; read it before you price anything.
How to cut the bill by 30–40%
In rough order of return per hour spent:
- Audit customisations first, keep / kill / simplify. Expect to delete about a third. This is the highest-leverage hour in the project and it doubles as a requirements document no implementation partner can pad.
- Archive before you migrate, not after. Deals older than two years and contacts with no activity in three go to cold storage, not into the new system. Cleaning before the move costs a fraction of cleaning after it.
- Migrate in phases with verification gates. Contacts, verify, deals, verify, automations. Record counts before and after each stage. A migration with no reconciliation step has no way to prove nothing was lost.
- Scope every integration in writing before quoting. Undiscovered integrations get re-quoted mid-project at the worst possible moment.
- Pilot with 2–3 power users on 100 representative records for two weeks. Every problem found here is an order of magnitude cheaper than the same problem found at cutover.
- Keep the old system live for 60+ days past go-live. See Layer 1. It is the cheapest insurance in the budget.
- Cutover in cohorts, not on a weekend. Under the Data Act's parallel-running provision this is becoming the contractual default anyway, and it caps how much pipeline any single failure can put at risk.
When switching is the wrong answer
Three situations where the model says stop:
- Adoption is the complaint. If your team avoids the current CRM, a migration produces a team that avoids a different CRM, six months and $86,500 later. Diagnose the friction first; we covered the mechanics in how to get your sales team to actually use the CRM.
- Data quality is the complaint. Dirty data is a reason to clean, not to move. Migrating it faithfully replicates the mess and destroys trust in the new system on day one.
- The three-year saving does not clear the all-in cost. Compare (current annual cost − new annual cost) × 3 against the full three-layer number, not the invoice. If it is close, staying and renegotiating, especially with a credible, documented alternative and a renewal date near January 2027, is usually the better trade.
Switching CRM is a legitimate and sometimes overdue decision. It is just rarely a $5,000 one, and the people who are disappointed by it are almost always the ones who priced Layer 1 and got billed for all three.