About once a week, someone asks us what a Salesforce implementation should cost. The honest answer is a range, and the range is wider than most sales decks admit. Here is how we actually scope it, what drives the number, and where the hidden costs live.
About once a week, someone asks us what a Salesforce implementation should cost. It is a reasonable question, and it is almost impossible to answer in the abstract. The range we have seen across real projects spans two orders of magnitude, and the difference between a $75k project and a $1.5M one is not always obvious from the outside.
Here is how we actually think about it, what drives the final number, and where the costs that nobody mentions upfront tend to live.
The rough ranges we see
Ranges, not quotes. Every project is different, but these bands cover most of the work we scope.
Small implementation. Under 50 users, single cloud (usually Sales Cloud or Service Cloud), modest automation, one or two integrations, standard reporting. Expect $50k to $150k to implement well. Anything significantly below that floor is a template drop rather than an implementation, and you will pay the difference in rework within the year.
Mid-market implementation. 50 to 250 users, two or three clouds, a few integrations, custom objects, moderate automation, real reporting needs. $150k to $500k is the honest band. Most of our consulting work sits in here.
Enterprise implementation. 250+ users, multi-cloud, complex integrations, custom LWC work, heavy data migration, governance requirements. $500k to $2M+ over six to eighteen months. The high end is multi-year transformation work that includes MuleSoft, CPQ, and a full Experience Cloud rollout.
Greenfield product build on Salesforce. Custom portals, branded partner experiences, product-grade applications built on top of the platform. $400k to $3M+, with the spread depending almost entirely on UX ambition and integration depth.
These numbers are services only. Licenses are a separate conversation.
What actually drives the cost
The variable that dominates the estimate is not user count. It is integration complexity. A 50-user org with six integrations and a non-trivial data migration is a bigger job than a 500-user org with one clean API and a fresh start.
In rough order, here is what we actually use to size a project.
1. Integrations
Every integration is a negotiation between two systems with their own opinions. We budget two to eight weeks of work per integration depending on the source system, the data volume, the error handling requirements, and whether the other side is being built or already exists. If you have seven integrations on the list, that is three to twelve months of work on just that slice.
That range is for direct, platform-native integrations written in Apex or orchestrated with platform events and External Services. Middleware-based integrations sit on top of this and carry their own implementation weight. A first-time MuleSoft implementation alone runs $50k to $200k before you start integrating anything, and the DataWeave and API-led scaffolding does not transfer cleanly between projects. If you are buying middleware as part of the program, it is a separate workstream with its own budget.
2. Data migration
Under-budgeted on almost every project we come into. If you are migrating from a legacy CRM with years of accumulated data, allow for a full parallel migration stream: profiling the source, mapping fields, cleaning records, running trial loads, reconciling differences, cutting over. On larger projects this is a three- to four-person team running for months.
A decent rule: data migration is almost never less than 15 percent of total project effort, and on a legacy-heavy org it can be 30.
3. Custom UI
Every custom Lightning component is a design decision, a development task, a test suite, and a maintenance burden. We budget one to three weeks per meaningful custom component, and more for anything genuinely product-grade. A portal with twenty custom components is a real engagement regardless of user count.
4. Automation complexity
Simple automation (a few flows, basic validation) is cheap. Sophisticated automation (orchestrated flows across multiple objects, approval hierarchies, escalation logic, bulk Apex handlers with edge cases) is one of the longest-running workstreams on any project. If the business process is genuinely complex, this is where most of the calendar time goes.
5. The number of stakeholders
Underrated. A project with one decision-maker ships faster than a project with seven, everything else being equal. We include stakeholder management in our scoping because it is a real cost. Four cross-functional review meetings a week is a half-time job for someone on the delivery team.
6. Change management and training
The line item most often cut when budgets get tight, and the one that predicts adoption most reliably. A beautifully built Salesforce org that nobody uses is a zero-ROI project. Budget 8 to 15 percent of services for training and rollout, more if the user base is distributed or change-averse.
The costs that are not on the quote
Six line items that new buyers tend to miss.
Licenses. Not the implementation cost. The ongoing cost. Salesforce licensing is a multi-year commitment and it compounds as you add users and clouds. Before signing an implementation contract, model the three-year licensing cost, not just year one. It will usually exceed the implementation cost by year two.
Sandbox strategy. Partial and full copy sandboxes are priced separately and they are not trivial at enterprise scale. You need them to do anything serious, so plan accordingly.
API call volume.Integrations consume API calls against your org's daily allocation. Heavy integrations can push you into needing extra API capacity, which is purchased separately.
Third-party tools. CI/CD platforms, data migration tooling, monitoring, documentation, testing tools. Budget $15k to $80k per year depending on team size.
Ongoing development. The implementation is the start. Budget for a continuing capacity of at least 20 to 40 hours a week of development and admin work post go-live. Either internal hires or a platform partner engagement. Skipping this is why so many implementations slowly rot over their first two years.
Change orders. Most implementations have them. Well-scoped projects have fewer, but a 10 to 20 percent reserve on the services budget is realistic for discovered requirements. It is better to plan for it than to pretend it will not happen.
Year two economics
Here is the part that gets glossed over most often. The total cost of ownership of a Salesforce org for year two onward is usually comparable to the implementation cost itself.
A $250k implementation for a 100-user org is not a $250k decision. Sales Cloud Enterprise lists at $165 per user per month in 2026, so a 100-seat deployment runs around $200k a year on that one cloud alone, before any negotiated discount and before layering in Service Cloud, CPQ, or Agentforce consumption. Add $120k a year for ongoing development, and the real picture is $250k upfront plus roughly $300k a year for the life of the org. Over three years, the services portion of that total is the smaller line.
This is not a reason to skip the implementation or pick the cheapest bid. It is a reason to pick the bid that sets the org up to be cheap to run later, because the run cost dwarfs the build cost over any meaningful time horizon.
How we scope
Our scoping process is honestly not complicated. It runs two to four weeks for a substantial project, a few days for a small one.
- A discovery kickoff with the client team to understand the business problem, not the Salesforce problem.
- Workshops with each functional area. One to two hours each. The goal is to hear the workflow in their words.
- A data and integration mapping session. This is where most of the surprises surface.
- A first architecture proposal. Not a quote yet. A working hypothesis of the shape of the solution.
- Internal scoping against the proposal: effort per workstream, roles required, phasing options, risk register.
- A fixed-fee or capped T&M proposal with explicit phases and exit criteria.
If a firm offers you a quote without at least the first three steps, be careful. Either they are drawing from a template (which may fit you, but probably will not) or they are planning to price low and change-order up later.
The cheap bid problem
We lose bids to firms that come in at 40 percent of our price. We also get called in to fix those projects about 18 months later. This is not a complaint. It is the pattern we see often enough that it is worth naming.
The cheapest implementation is almost never the cheapest implementation by year two. It is the one that compounds into rework, a tired team, and a second engagement that costs more than the first would have if it had been done well. Nobody writes this in the sales cycle, but it is the math.
The right question is not "who is cheapest." It is "who will build something that is still valuable three years from now." That is usually not the same answer.
A sane place to start
If you are in early scoping and you want a gut check on your budget, here is a rough frame.
Services budget typically runs 2x to 3x your year-one license spend for a reasonably scoped project, and 3x to 4x when things get genuinely complex (multi-cloud, middleware like MuleSoft, CPQ, Agentforce at scale, heavy custom UI, or regulated-industry requirements). If your licenses are coming in at $100k a year, expect $200k to $300k in services for a well-scoped project and $400k+ if complexity pushes it. License spend at $500k a year usually implies $1M to $2M in services to build something worth the license cost.
This is a rule of thumb, not a quote. But it is a better starting point than most of the back-of-envelope numbers we see prospects walk in with.
If you want a real scoping conversation, that is what we are here for. The best version of that conversation is the one that happens before the budget gets set, not after.