The market has moved and the question has changed
The dominant Salesforce services work is no longer first-time deployment. It is optimisation, modernisation and expansion of orgs that have been running for years — which means the question most mid-market companies are actually asking is not 'which CRM' but 'do we fix this one or leave'.
That question gets answered emotionally far more often than analytically, usually in the month after a painful release.
The four tests that genuinely justify replatforming
- 1. The data model is wrong for the business you are now. Not messy — wrong. If your objects encode a business you have outgrown and every workaround fights the model rather than extending it, that is structural.
- 2. Licensing exceeds value at any realistic usage. Run the arithmetic honestly, including the admin capacity a platform assumes. If it does not work at your actual seat count, it will not work after optimisation either.
- 3. A regulatory requirement cannot be met. Rare, and definitive when true. Data residency is the usual candidate.
- 4. Confidence is unrecoverable. If two rollouts have failed and the team has stopped believing anything will change, the technical assessment may be beside the point. This one is real, and it is a leadership judgement rather than a systems judgement.
If none of the four is true, you are looking at an optimisation problem wearing a replatforming costume.
What people mistake for replatforming signals
These feel decisive and are not:
- Configuration debt. Overlapping automations, unowned fields, validation rules that fight each other. Real, expensive, and fixable in place — usually in a quarter.
- Slow change delivery. Measure it before attributing it. Change requests queuing behind one admin is a capacity problem, not a platform problem.
- Low adoption. Adoption failures travel with you. A team that abandoned one system because it was designed for management reporting will abandon the next one for the same reason.
- A new leader who prefers something else. Legitimate as a preference; expensive as a strategy. Ask what specifically the alternative solves that the current org cannot.
The asymmetry nobody prices
Migration cost is real and quantifiable, and it is not the expensive part. The unrecoverable cost is organisational: a team that has been through one disruptive rollout is measurably harder to move a second time, and the second rollout inherits the scepticism of the first.
That is the asymmetry. Optimisation that disappoints costs you a quarter. Replatforming that disappoints costs you the credibility to try anything else for two years.
| Optimisation | Fails → you lost a quarter |
|---|---|
| Replatforming | Fails → you lost the mandate to try again |
| The implication | Optimise first unless one of the four tests is unambiguously true |
What a serious optimisation actually involves
If the four tests point at optimisation, this is the shape of it — and much of it you can run internally:
- Org health assessment. Inventory automations, fields, validation rules and permission sets. Identify what is unused, what conflicts, and what nobody owns.
- Configuration rationalisation. Retire the unused, resolve the conflicts, assign owners. Unglamorous, and it is where most of the recovered velocity comes from.
- Data remediation. Duplicates, dormant records, free-text fields that should be structured. Prerequisite for anything else, including agents.
- Process re-alignment. Stage definitions with entry and exit criteria in evidence terms. Usually the highest-leverage item and it costs nothing but calendar time.
- Adoption design. Fewer required fields, something useful returned to the person entering data, and leadership running reviews from the system rather than around it.
Where we would tell you not to hire us
If your org is small, your admin is capable and the problem is a backlog rather than a structural one, hire a fractional admin and skip the consulting engagement. That is a materially cheaper answer and it is often the right one.
And if one of the four tests is unambiguously true — particularly the data model — do not let us sell you an optimisation programme that postpones the inevitable by eighteen months. We would rather scope the migration properly than bill for a delay.