8 min read
Almost every implementation budget I am asked to review has the same shape: a precise licence figure, a round number for "implementation", and nothing at all for the four or five things that end up consuming most of the calendar. The licence line is the easiest to get and the least useful for planning, because it is the only cost that does not depend on the state of your data.
Licences are the floor, not the budget
Per-seat pricing is public, tiered, and negotiable at volume, so it is the part of the estimate your team can source without help. What it does not tell you is how much work it takes to make those seats useful. Two companies can buy identical Sales Cloud licences and spend wildly different amounts getting to go-live, because one of them has a clean account hierarchy and the other has eleven years of spreadsheets.
Treat the licence number as a floor you cannot go under, then budget the implementation against the condition of what you are migrating and how many systems have to keep talking to each other afterwards.
Where the hours actually go
Across mid-market builds, the effort concentrates in a handful of places — and only the first is usually in the original scope.
- Data model and architecture: objects, relationships, record types and sharing rules settled before anything is automated.
- Data migration and cleanup: deduplication, field mapping, and deciding what legacy history is worth carrying forward at all.
- Integrations: every system that needs to read or write — ERP, billing, marketing automation, support, data warehouse.
- Automation build: the Flows and, where genuinely warranted, the Apex that replace named manual steps.
- UAT and training: the people who run the process daily testing it before launch, not after.
- Post-launch stabilisation: the first few weeks of real usage, which always surface something UAT did not.
The line items nobody scopes
Data migration is the single most common underestimate. Moving records is trivial; deciding which of four conflicting account records is the real one is not, and that decision has to be made by someone in your business, not by a consultant. If nobody has budgeted internal time for data decisions, the migration stalls and the project holds.
Integrations are the second. A scope that says "integrate with our ERP" is not a scope — it is a category. Which objects, in which direction, how often, and what happens when the two systems disagree are four separate questions, and each one has a different cost.
The third is the automation you already have. An org that has been running for years carries Workflow Rules, Process Builder flows, validation rules and triggers that nobody has inventoried. Some of it has to be rebuilt, some of it has to be retired, and all of it has to be understood before it can be safely replaced.
What moves the number up or down
Up: more source systems, more record types, more bespoke approval logic, regulated data, multiple business units on one org, and a hard external deadline that removes the option of phasing.
Down: a single clean source of truth, a willingness to launch a smaller first phase, an internal admin who can own configuration after handover, and a business process you are prepared to simplify rather than replicate exactly as it is.
That last one is worth more than any discount. The most expensive implementations are the ones that rebuild every quirk of the old system in the new one, then pay to maintain those quirks forever.
How to get a number you can plan against
A quote worth planning against comes after someone has looked in the org and asked what the automation inventory, the data quality and the integration surface actually look like. That is an afternoon of discovery, not a form. Anything quoted before that is a placeholder, and placeholders are what turn into change orders.