Somebody built this. Nobody knows what it does.
Most Salesforce work is not implementation. It is reading fourteen years of decisions made by people who have left, and deciding which of them still matter.
Thirty minutes · no predetermined package
Three of these are cheaper than the one everybody asks for.
The frustration usually says replace. The findings usually say configure.
Fix what is there
Most orgs do not need replacing. They need the fourteen years of accumulated exceptions removed and the process re-modelled properly.
Build alongside
Custom modules for the parts Salesforce will never model — underwriting, commissions, a portal — reading and writing the same records.
Keep it running
Ongoing administration, release management and the person who actually knows what the automations do.
Build your own
Only when the data model itself is wrong. We have done it once, for a lender whose process could not be expressed in Salesforce objects.
Six kinds of Salesforce engagement.
Most start as one of the first two, and the second one frequently ends there.
Implementation
A new org, or a first proper one
Object model, permissions, automation, integrations, migration and training. Most of the work happens before anything is configured.
Health check and audit
Read an inherited org
Every automation, field, profile and licence documented, with what depends on each. Delivered as a written report whether or not we do the work.
Managed services
Someone who owns it
Ongoing administration, release management and user support, for orgs that are functionally fine and have no owner.
Data migration
Move it without losing it
Object by object against a mapping you approve, with the source readable until the new system is trusted.
Org merge and consolidation
Two orgs, one business
Two object models, two sets of automation, two definitions of the same field. The reconciliation is the project.
Custom development
The parts it will not model
Apex, custom objects, or an application alongside it, when configuration has genuinely run out.
What an inherited org feels like from inside.
The person who understood the org left, and what it does now is discovered by changing something and seeing what breaks.
Two automations fire on the same field and the last one wins, which nobody decided.
Reps have a private spreadsheet because the system asks for things it does not need and cannot record what it does.
A release goes out and something unrelated stops working.
Licences renew for people who left, because nobody owns the list.
A report exists for every question ever asked, and forty of the two thousand get opened.
Six questions the Salesforce health check answers.
Nobody should propose a change to an org before answering these, and most proposals do.
Five stages, and reading comes before writing.
Read the org
the findingsEvery automation, field, profile, validation rule and licence, documented. Delivered as a written report whether or not we do anything after it.
Agree what stays
the boundaryWhat gets fixed, what gets removed, what gets built alongside and what is genuinely fine. Signed off before any change.
Clean in a sandbox
testedChanges staged and tested rather than applied to production and hoped for. This is the part most inherited orgs have never had.
Deploy in slices
workingSmall releases with a rollback path, so a bad change costs an hour rather than a week.
Document and hand over
the runbookWhat every automation does and why, written for the next person. The absence of this document is how the org got here.
The org differs. The archaeology does not.
Financial services
Compliance, retention and audit obligations that constrain what can be removed and what has to be kept.
Lending
Origination processes that stretch the standard object model, usually with a decade of custom fields as evidence.
Professional services
Engagement-level work modelled as opportunities, which is where most of the workarounds come from.
Manufacturing and distribution
Quote-to-order flows and dealer relationships that rarely fit the out-of-the-box pipeline.
What people ask about Salesforce implementation and support.
What do Salesforce implementation services include?
Object and field modelling, permissions, automation, integrations, data migration and training. Done well it is mostly a data-modelling exercise; the configuration follows from decisions made in the first week.
What is a Salesforce health check?
An audit of what an org actually contains — automations, fields, profiles, validation rules, licences and reports — with what depends on each. Most inherited orgs have never had one.
What are Salesforce managed services?
Ongoing administration, release management, user support and someone who knows what the automations do. Most useful for orgs that are functionally fine but have no owner.
How do you deal with Salesforce technical debt?
Document first, then decide. The findings usually show a small number of automations doing real work and a large number nobody can account for. Removing the second group is safe once documented.
What does a Salesforce implementation partner actually do?
Translates a business process into an object model, then configures around it. The good ones spend the first week reading and asking rather than building, because a wrong data model is expensive to unwind.
What should a Salesforce implementation checklist cover?
Object model, field-level security, profiles and permission sets, automation inventory, integration map, data migration mapping, sandbox and release process, and who owns the org afterwards.
How much does a Salesforce consultant cost?
It scales with integration count and data complexity rather than user count. A single-object cleanup and a multi-system implementation are different projects that get quoted under the same name.
What is Salesforce Sales Cloud implementation?
Configuring the core sales objects — leads, accounts, contacts, opportunities — around a specific pipeline, with the automation, permissions and reporting that go with it. The most common starting point.
How does Salesforce data migration work?
Object by object, against a field mapping you approve before anything moves, with the source system readable until the new one is trusted. The mapping takes longer than the migration.
Can you merge two Salesforce orgs?
Yes, and it is harder than it sounds. Two orgs mean two object models, two sets of automation and two definitions of the same field. The reconciliation is the project; the merge is the last step.
What is a Salesforce Lightning migration?
Moving from the Classic interface to Lightning. It surfaces every customisation that was written against the old one, which is why it usually becomes a broader cleanup than anyone budgeted for.
Should we replace Salesforce or fix it?
Fix it, in most cases. Replacing is right only when the object model itself cannot express your process — and that is rarer than the frustration suggests.
What are Salesforce implementation best practices?
Model before you configure. Document every automation as you build it. Test in a sandbox. Ship small releases with a rollback path. Decide who owns the org before the project ends, not after.
Do you take commission from Salesforce?
No. No commission, referral fee or partner margin on any software we recommend, which is what lets us tell you to stay on what you have.