The pattern is consistent enough that we can describe it from memory. A growing services firm decides they need a real CRM and operations platform. They choose Salesforce because Salesforce is the safe choice. They sign a 12 to 18 month implementation contract with a partner, with a budget somewhere between $300,000 and $1 million depending on company size and ambition.
Six to nine months in, they are 60 to 85 percent through the migration. The data has been mapped, the objects have been customized, the page layouts have been built, and the integrations are in flight. And then leadership starts asking two uncomfortable questions.
The first question is about money. The remaining 15 to 40 percent of the migration is going to cost as much as the work already done, sometimes more, because the hardest integrations were left for last. The Salesforce license cost has compounded across more seats than originally projected. The implementation partner keeps finding edge cases that require change orders.
The second question is about value. Even when the migration is finished, the system will not solve the actual problem. The actual problem was that project knowledge, customer history, and operational data live in six or more systems, and Salesforce was supposed to unify them. But Salesforce is good at the data model, not the search-across-everything user experience that the team actually needs to do their work.
That is when the walkaway conversation starts.
The Walkaway Math
Walking away from a Salesforce migration sounds reckless until you run the numbers. Let us use a representative example: a 50-employee firm, $600,000 budgeted, 70 percent through.
They have spent $420,000 to date. To finish, they need another $300,000 (because the remaining work is harder than the work already done). Once finished, they will pay $200 to $300 per user per month in Salesforce licensing, plus $80 to $150 per user per month in connector and add-on costs. For 50 users, that is roughly $180,000 to $270,000 per year in ongoing platform fees, before any further customization.
If they walk away today and replace Salesforce with a custom-built operations platform, the math looks different. A custom build for a firm that size typically runs $150,000 to $250,000 over four to six months, deployed against the same data sources Salesforce was supposed to unify. There are no per-seat fees because there is no platform vendor. The only ongoing cost is hosting, which for the architecture we use is in the low four figures per month for a 50-seat firm.
The five-year total cost difference is staggering. Finish Salesforce: roughly $720,000 in remaining build cost plus $1.0 to $1.4 million in five-year licensing equals $1.7 to $2.1 million. Walk away and replace: $150,000 to $250,000 build plus roughly $80,000 in five-year hosting equals $230,000 to $330,000. The walkaway saves approximately $1.5 to $1.8 million over five years for a firm of this size.
Even if you write off the $420,000 already spent on Salesforce as a sunk cost, the walkaway is still cheaper. That is the part that surprises people.
What Custom Can Do That Salesforce Admin Cannot
The math alone is not enough to justify a walkaway. The capability has to be there too. Here is what a custom-built operations platform delivers that a Salesforce admin cannot.
Search across all your data, not just Salesforce data. Salesforce searches what is in Salesforce. A custom platform searches across Salesforce, SharePoint, OneDrive, QuickBooks, your case management system, your project management tool, your email, your meeting transcripts, and any other system you connect. That is the unification problem Salesforce was supposed to solve and never quite did.
AI agents trained on your matter, case, or project history. Salesforce Einstein is trained on aggregated patterns across all Salesforce customers. A custom AI layer is trained on your data and your conventions, so it actually understands what your firm does and how your firm does it.
Custom UI per role. Salesforce gives every user the same object-record-list interface. A custom dashboard gives a partner the partner view, a paralegal the paralegal view, an account manager the account manager view, and so on. Each role sees the data and actions they actually use.
Mobile-first field interface. Salesforce mobile is a port of the desktop experience. A custom mobile interface is built for the field workflow: photos, voice notes, geolocation, offline capture, sync when reconnected. For field teams this is not a nice-to-have. It is the difference between getting reports done in the field versus getting them done at 9 PM at home.
No vendor lockup on data, format, or workflow. Your data lives in your databases on your hosting. Your workflows live in code you own. If you outgrow your AI vendor, you take everything with you.
The Replacement Architecture
Here is the technical pattern we use for Salesforce replacement engagements.
Edge layer. Cloudflare Workers and Pages for the application frontend. Cloudflare Zero Trust for authentication, with SSO via Microsoft Entra ID, Google Workspace, or Okta depending on your stack. The edge layer also handles rate limiting, geographic routing, and DDoS protection.
Application layer. Custom dashboards built per role. Each role gets its own view, its own quick actions, and its own AI assistant scope. Built with React or HTMX depending on the team's preference. Mobile-first responsive design.
Data layer. Cloudflare D1 or Hyperdrive-fronted Postgres for transactional data. Vector store for AI search (Cloudflare Vectorize, Pinecone, or self-hosted depending on volume). All data in your hosting, under your control, with full export at any time.
Integration layer. Read-only and read-write connectors to your operational systems. The systems that were supposed to consolidate into Salesforce keep doing what they do well, but a unified layer reads from all of them so users get one place to search.
AI reasoning layer. Anthropic Claude for primary reasoning, OpenAI for image generation, Perplexity for deep research. Right-model selection per workflow, with audit logging on every AI decision.
Governance layer. ISO 42001-aligned controls, role-based access control, audit logs, retention policies, and change management workflows. Compliance is built in, not bolted on.
The Flagship Case Study
California's largest hillside structural engineering firm came to us 85 percent through a Salesforce migration. They had 50-plus employees across multiple regional offices, 25 years of project history, and a clear sense that even when the migration finished, it was not going to solve their actual problem.
Their actual problem was knowledge retrieval. An engineer working a hillside assessment in Pasadena needed to know what the firm had done on similar projects in Glendale, Tarzana, Encino, or any other hillside community over the past quarter century. Salesforce was going to give them a contact record. What they needed was a search across plan sets, photos, permit applications, budget spreadsheets, and project notes spanning 25 years.
We did a $30,000 Phase 1 POC against their live Salesforce, SharePoint, and QuickBooks Time. The POC ingested a representative slice of their project history and built the cross-system search layer they actually needed. We demoed twice. The second demo closed the deal.
For the full architecture, security model, and rollout timeline, see the structural engineering case study.
Migration Assurance and Data Ownership
Walking away from Salesforce raises legitimate concerns. Two come up most often.
What happens to the data already in Salesforce? We extract it. Salesforce supports full data export, and the data ends up in your databases on your hosting. The custom platform reads from your databases, not from Salesforce. You can keep Salesforce running in parallel during cutover, sunset it once the new system is stable, and retain a read-only archive if you need historical access.
What if something goes wrong with the custom build? The architecture is your code, your data, your hosting. If you outgrow us, you can hand it to another developer or take it in-house. There is no proprietary platform you are locked into. We deliver source code, infrastructure-as-code definitions, runbooks, and documentation as part of every build. The "what if" of vendor failure is structurally lower with a custom build than with a platform vendor, because there is no platform.
When NOT to Walk Away
The walkaway is not always right. Here are three cases where finishing the Salesforce migration is the better answer.
You need the AppExchange ecosystem. If your business depends on a specific AppExchange integration that does not exist outside Salesforce, walking away means rebuilding that integration. Sometimes that is fine. Sometimes it is prohibitive.
You have a compliance regime that requires Salesforce specifically. Some regulated industries have audit standards that name Salesforce as an approved system of record. Custom builds can absolutely meet those standards, but the audit lift is heavier.
You are 95 percent done. If the migration is essentially complete and the remaining work is configuration polish, finishing is usually cheaper than starting over. The walkaway math gets thin once you are past the 90 percent mark.
Where to Start
If you are mid-migration and the walkaway question is in your head, run two numbers. First, what is the total cost to finish (remaining build plus five years of licensing)? Second, what is the total cost to walk away (custom build plus five years of hosting)? If the second number is less than the first by a factor of two or more, the walkaway is worth a serious conversation.
We will run those numbers with you on a discovery call, with no obligation. If the math says finish, we will tell you that. If the math says walk away, we will tell you that too, and we will scope the replacement.