“How much does a Salesforce implementation cost?” is one of the most searched questions about the platform, and almost every answer online is the same: it depends, followed by a range wide enough to be meaningless, followed by a contact form.
The range is genuinely wide. That part is honest. What is not honest is stopping there, because the variables driving that range are knowable, and most of them you can assess yourself before you speak to anybody.
This is what actually moves the number. Not so you can price the project yourself, but so you can tell the difference between a quote that has been thought about and one that has been guessed.
01Scope is not the number of users
The first question most buyers ask themselves is how many licences they need. That is a Salesforce cost, not an implementation cost, and the two behave differently. What drives implementation effort is:
- How many clouds. Sales Cloud alone is a different project from Sales plus Service plus Experience Cloud. Each additional cloud brings its own data model, its own configuration surface, and its own integration points between them.
- How many objects, and how many are custom. A standard opportunity pipeline is well-trodden. A custom object modelling something specific to your industry — policies, inspections, shipments, claims — means designing a data model from scratch, and everything downstream inherits that decision.
- How many distinct processes. Five sales teams with five genuinely different processes is close to five projects. The most expensive discovery finding is usually that a business assumed it had one process and actually has several.
- How many user profiles and permission sets. Every distinct way of seeing the system is a design decision, a build task and a test case.
The useful question is not “how many users” but “how many different things are those users doing.”
02Data quality is the largest hidden variable
This is the one that most often turns a comfortable budget into an uncomfortable one, and it is almost never visible at quoting time. Two organisations can migrate the same record count with wildly different effort. What separates them:
- Whether records have a reliable unique identifier, or whether one has to be constructed
- Duplicate rate in the source, and whether anyone has agreed how to resolve them
- Field completeness — a contact table where 40% of the emails are missing needs a business decision, not a technical one
- Referential integrity — orphaned child records have to be dropped or reparented, and someone has to decide which
- How many source systems feed the same object, and whether they agree with each other
- Whether historical data is being brought across, and how far back
None of that is exotic. All of it is invisible until someone profiles the source. A partner who quotes migration effort without asking to look at your data is guessing, and the guess is usually low. We wrote up the mechanics of getting this right in The Salesforce Data Migration Checklist.
03Integrations are individual projects
Every system Salesforce has to talk to is a small project with its own discovery, build, test and failure modes. The count matters, but the shape matters more.
- A modern system with a documented REST API is close to routine work.
- A legacy system without one is a different proposition. You are building or buying middleware, negotiating access, and often working around a system nobody currently owns.
- Real-time versus batch changes the engineering substantially. Nightly synchronisation is straightforward. Sub-second bidirectional synchronisation with conflict resolution is not.
- Bidirectional anything roughly doubles the work of one-directional, because now you need to decide what happens when both sides change the same record.
- Who owns the other end. If the counterpart system belongs to a vendor with their own release cycle and priorities, your timeline is partly theirs.
A useful exercise before any conversation with a partner: list every system, note whether it has a documented API, and note who you would call if it broke. The gaps in that list are where your budget risk sits.
04Configuration versus code
Salesforce is designed so that a great deal can be built declaratively — flows, validation rules, page layouts — without writing code. Declarative work is faster to build, cheaper to change, and easier for your own team to maintain after go-live.
Custom code changes the economics. Apex and Lightning Web Components mean development, unit tests to meet Salesforce’s coverage requirements, code review, deployment pipelines, and a maintenance burden that persists long after the project ends.
Sometimes code is genuinely required. Often it is chosen because the requirement was never challenged. The commercially relevant point is not that code is bad — it is that the ratio of configuration to code is one of the largest levers on both build cost and ongoing cost of ownership, and it should be an explicit conversation rather than an accident of how the requirements were written.
05Change management is the cost that gets cut first
Technical delivery is only half of a CRM implementation. The other half is people changing how they work, and it is the half that gets removed when a budget needs trimming. It covers:
- Process redesign — deciding how work should happen, not just replicating how it currently does
- Training, differentiated by role
- Data entry standards, and who enforces them
- Reporting and dashboard design for the people who will actually use them
- Post-go-live support while people are still learning
- Someone internal owning the system afterwards
A technically perfect Salesforce implementation that nobody adopts has produced no value at all. That is not a rhetorical point — it is the most common way these projects fail, and it fails quietly, over months, after everyone has declared success.
If a quote does not include change management, it is not cheaper. It has moved a cost onto your own team without saying so.
06Whether you are starting clean or inheriting an org
Greenfield implementations and existing-org work are different disciplines.
A new org is comparatively predictable. You are designing rather than negotiating.
An existing org carries whatever has accumulated: unused custom fields, overlapping automations built by different people at different times, deactivated-but-not-deleted objects, unclear ownership, and occasionally an integration nobody remembers commissioning. Before you can add anything safely, someone has to understand what is already there.
That assessment is real work, and it is the phase most likely to be missing from an optimistic quote. It is also the phase that most often changes the plan — technical debt discovered in week two has a way of reordering the roadmap.
07Timeline, and the cost of compressing it
Compressing a timeline does not scale linearly. Adding people to a project with a fixed critical path increases coordination overhead faster than it increases throughput, and some sequences cannot be parallelised at all — data migration cannot begin before the data model is settled.
Where a hard date exists, the honest lever is usually scope, not resourcing. A partner who agrees to an aggressive date without proposing a phased scope is either absorbing risk they have not priced, or planning to have that conversation later, when you have less room to move.
What a low quote usually excludes
Quotes vary more than the work does. When one comes in materially below the others, the difference is normally in what has been left out:
- Data migration treated as a line item rather than a workstream
- Integration discovery assumed rather than scoped
- No sandbox strategy — testing in production, in effect
- Training as a single session rather than a programme
- No hypercare after go-live, when adoption is actually determined
- Documentation and handover absent, so you cannot maintain what you have bought
- A change request process designed to recover margin later
None of these are dishonest by themselves. They become a problem when they are unstated, because you end up comparing two quotes that describe different projects.
Questions worth answering before you ask for a quote
You will get a materially better estimate — and a materially better project — if you can answer these first:
- Which clouds, and which processes within them?
- How many genuinely different user groups, and what does each need to see?
- Which systems must Salesforce talk to, and does each have a documented API?
- Which of those need to be real-time, and which can be batch?
- How many source systems hold the data being migrated?
- Has anyone profiled that data for duplicates and completeness?
- How much history are you bringing across?
- Is this a new org or an existing one?
- Who internally will own the system after go-live?
- What is the date, and what is actually driving it?
A partner who asks these unprompted is scoping. One who quotes without them is guessing.
Frequently asked questions
Why won't anyone give a fixed price for a Salesforce implementation?
Because the variables that determine effort — data quality, integration complexity, process count, existing org state — cannot be assessed from a brief. A fixed price quoted without that assessment is either padded to cover the unknowns or will be revisited through change requests. Neither serves you well.
Is Salesforce implementation cost related to the number of licences?
Only loosely. Licences are a Salesforce cost. Implementation cost is driven by how many distinct processes, objects, integrations and user groups are involved. A hundred users doing one thing is a smaller project than twenty users doing six.
What is the most underestimated cost in a Salesforce project?
Data migration, and specifically data cleanup. Effort scales with data quality far more than with record count, and quality is invisible until someone profiles the source.
Should we build custom or configure?
Configure by default. Custom code is sometimes necessary, but it carries development, testing, deployment and long-term maintenance costs that declarative work does not. The ratio of configuration to code is one of the largest levers on total cost of ownership.
How do we compare Salesforce quotes that differ significantly?
Compare inclusions, not totals. Check specifically for data migration scope, integration discovery, sandbox strategy, training, post-go-live support and the change request process. Large differences in price usually reflect differences in what is being delivered.
We scope before we quote, which is why our engagements start with Discover rather than a proposal. If you have worked through the questions above and want a second opinion on the answers, start a conversation — or read how we approach Salesforce delivery.