Enterprise and ERP. Salesforce
Replacing Salesforce with a system that doesn't need a full-time admin
Salesforce is the CRM every other CRM gets measured against. For a large sales organization with the people to run it, that reputation is earned, and there's a real platform underneath with a deep bench of consultants around it. We've integrated it with a client's project system, and we were never a partner to it.
Nobody leaves Salesforce because the software is bad. They leave because you pay twice to make it yours. Once in licenses that climb by edition and by seat, and again in the implementation, the administrator, and the consultants who keep it upright. At the end of that you've got a heavily customized system you still don't own.
For what that implementation costs and how long it runs by company size, see our sourced research on Salesforce and NetSuite implementation.
Where it fits
Where does Salesforce fit?
We sell no Salesforce licenses and take no referral fees, so this is not a hit piece. These are the cases where keeping it is the honest advice, and if yours is one of them, we will say so on the call.
A large sales organization with the headcount for a dedicated administrator, preferably more than one. Salesforce rewards the company that staffs it and punishes the one that doesn't.
Regulated or audited environments. A widely recognized platform of record shortens the procurement conversation before anyone gets to a feature list.
Complex sales structures. Territories, quotas, forecast hierarchies and partner channels, where the standard model already matches how the business runs.
A company several years in, customization under control, no daily fight with the tool. If that's you, we'll tell you so. There's no rebuild to sell.
Where it breaks
Where does Salesforce break down?
The failure modes below are the ones that show up again and again as a company grows.
Editions gate the platform. API access, deeper automation, finer permissions, sandboxes, and the reporting a growing company reaches for all sit above the tier most companies start on. The upgrade applies to every seat.
Almost nothing is licensed once. Sales, service, marketing, quoting, analytics and portals are all separate products. Ask for something new and the answer is another cloud, another add-on, or an AppExchange package carrying its own subscription.
External users cost. Letting customers, subcontractors or field partners see their own data means portal licensing on top, priced by member or by login. It's why so many Salesforce customers still email status updates as PDFs.
The implementation is its own project. It runs through an outside integrator, priced in service hours, and published guides put those services at or above the first year of licensing. Mid-sized rollouts get measured in months. Enterprise programs run considerably longer.
Customization is a career. Apex, flows, validation rules, managed packages and the sharing model all reward specialists, so the system ends up depending on an admin or an agency. A change that should take an afternoon waits for a release window.
It compounds. Five years of administrators, each solving the request in front of them, leaves duplicate fields, dead flows and permission sets nobody will delete. The renewal comes due whether or not anyone can explain what's in there.
The replacement
What does replacing Salesforce look like?
A custom system starts from your sales and delivery process. Salesforce starts from an object model built to cover every industry at once. The records carry the names your business uses. The automation is ordinary code a developer reads in an afternoon, and the reports are screens built for the questions leadership actually asks. No edition to climb into, no analytics product to license separately.
Salesforce is good at letting your data out. Accounts, contacts, opportunities, activities, custom objects, notes, files and history all come across through the API, with a field-by-field mapping you approve before anything moves. The migration doubles as an audit. Fields nobody's written to in years, flows firing into nothing, duplicate records, they all surface, and you decide what earns a place.
We read Apex classes, flows and validation rules for the rules they encode. Nothing gets copied across. The logic that still matters is rebuilt in a mainstream language any developer can maintain, and whatever only existed to work around a platform limit disappears with the platform. Portals for customers and subcontractors are part of the build, no licensed seats.
You own the result. Source code in a repository in your name, database and hosting on accounts in your name, unlimited internal and external users, no editions. We're added as administrators to build it and support it, and you can remove us whenever you want.
The stakes
What does it cost to get this wrong?
More than the software. A replacement that goes badly costs you the one thing the old system was still doing, a single place your team agrees on. The failures below each turn a rebuild into a year of parallel systems, so they are the ones we plan around.
Managed packages hold their data in objects the package owns. Let a license lapse before that data is extracted and the records are still sitting in the org with nobody able to read them. Getting them out turns into a negotiation with a vendor you've already left.
Everything in Salesforce is joined by 18 character record ids. Extract children before parents, or import without remapping those ids, and you end up with a database where activities point at accounts that don't exist. Nobody can reconcile the history after that.
Formula fields and roll-up summaries are calculated, never stored. They export as whatever value they held at the moment of the pull. So a number your leadership has trusted for years lands in the new system frozen, and it will never move again.
The order of work
What happens, in what order, when you leave Salesforce?
Each step exists because skipping it is how the previous attempt failed. The sequence is fixed. The runway is not, and it goes in your written scope once we know the shape of your data rather than on this page as a calendar promise.
- 01
Org audit before anything
We map the org. Objects with records written this year against objects nobody has touched, flows and Apex triggers that still fire, validation rules, permission sets, the sharing model, every managed package and whatever depends on it. Five years of administrators leaves dead configuration behind. This step separates the system from the sediment.
- 02
Extraction in dependency order
Salesforce lets data out cleanly through its export service and the Bulk API. Order matters. Parents come before children, and record ids are kept so relationships can be remapped later with no guesswork. Files and attachments come out separately from records. Field history only covers the fields tracking was switched on for, so we find those gaps early.
- 03
Apex and flows as rules
Metadata comes out. Apex classes, flows, validation rules and sharing rules are platform logic, and platform logic doesn't port. We read each one for the rule it enforces and confirm it with the person who relies on it. Code that only existed to dodge a platform limit goes away with the platform. What's left gets rebuilt in a mainstream language, with tests.
- 04
Build while the org runs
The new system gets built while Salesforce keeps running, importing through the API on a schedule so both hold the same records. Portals for customers, subcontractors and field partners are part of the build, with no licensed seats behind them. That's usually the first thing leadership notices, because it removes the reason status still goes out as a PDF.
- 05
Cut over, then the renewal
Both run while your team checks opportunity counts and amounts by stage, activity history, and the forecast leadership reads. When those reconcile, the org goes read-only. Cutover lands ahead of the renewal date, because the contract is annual and the saving only starts at the term boundary.
Limits
What we will not do
Saying this out loud is cheaper for both of us than finding out in month two. If one of these is what you actually want, we are the wrong firm and we will say so on the first call.
- We won't rebuild your org as it stands. Duplicate fields, dead flows and permission sets nobody will delete are what five years of good intentions costs. Carry them across and you've bought a new system with the same sediment in it.
- We won't tell a company with a working Salesforce org to replace it. If your customization is under control and your admin isn't fighting the tool every day, you'll hear that on the call. There's no sale in it for us.
- We won't hold any account the system runs on. The repository, database, hosting and mail domain are created in your company name, and we're administrators you can remove. We never hold the keys to your castle.
Questions
What people ask about leaving Salesforce
Can a custom system really match Salesforce?
Not feature for feature, and it isn't trying to. Salesforce carries thousands of capabilities because it has to cover every industry at once, and your company uses a small fraction of them. We map your org before scoping, so the comparison runs on what your team actually touches. What the platform advertises isn't the measure.
We have years of data and heavy customization. Can all of it move?
The data, yes. Standard objects, custom objects, activity history, notes, files and attachments all export through the API with a mapping you approve. The customization moves as rules, and we rebuild from there. Anything the platform won't hand over cleanly gets flagged during scoping, so you don't find it on cutover day.
What happens to our AppExchange packages and integrations?
We list each one with what it does and who depends on it. Connections to accounting, e-signature, marketing and telephony get rebuilt as direct integrations, which usually retires several packages at once. Anything genuinely specialist stays where it is and connects to the new system.
Our administrator does nothing but Salesforce. What happens to that role?
They usually become the most valuable person on the new system. Nobody else in the building understands the process that well. The work changes from keeping a platform configured to deciding what the business needs next.
What does replacing Salesforce cost?
It depends on how many clouds are in real use, how much custom logic has to be rebuilt, and how many people need access, so we don't publish figures for our own work. We do publish sourced ranges for what a Salesforce implementation costs by company size, and that's a fair place to start. After a strategy call you get a written scope naming every deliverable and what it costs, set against your renewal.
Is our data safe during a migration of this size?
Salesforce stays the system of record until you decide otherwise, and every extract is a read, so nothing the new system does can touch your live org. The new database sits on hosting your company owns, encrypted at rest, with access by named role and every change logged. Credentials go into a secrets manager, never into code or a chat window. Paste a key into a message and it gets rotated, not used. You're offered a security audit at the end of the engagement whether or not you carry on with us.
Can we run Salesforce and the new system in parallel?
Yes, and at this size you should. The new system imports from Salesforce through the API on a schedule so both hold the same records, and one business unit can move first while the rest of the company carries on in the org. Two-way sync is possible where a team needs to keep writing into Salesforce. One rule. The parallel period gets a defined end in the scope, along with the reconciliation that has to pass before cutover, because an open-ended parallel run is how companies end up paying for both.
What happens when we need a change after handover?
It stops being a release window and becomes a normal piece of work. You can ask us under an optional support plan, hand the repository to any developer, or do it in house. The code is mainstream and tested, so a developer who's never seen it reads it quickly with AI assistance. That's what killed the old risk of custom software depending on one person. In a managed org the same change waits on an admin, a sandbox and a deployment slot.
From the knowledge base
Guides for people weighing up Salesforce
Reference pages, not sales pages. Each one is useful even if you decide to stay exactly where you are.
How to tell whether your business actually needs custom software
Seven tests you can run against your own operation this week. Most businesses that run them find a configuration problem, not a build.
Salesforce and NetSuite implementation cost and timeline, by company size
A sourced comparison table at 50, 100, 250, 500, and 1,000 employees. Every figure is cited and dated, and the thin-data cells say so.
Related
Coming from a different tool?
The same honest treatment for the other platforms we used to implement, and the pages that explain the custom model itself.
Tell us where Salesforce stopped fitting
Book a strategy call, or send a short note about the workarounds your team runs today. If keeping Salesforce is the right answer, you will hear that first.