A practical guide to migrate off of Salesforce to a custom CRM system.

The question underneath the question

Our last article walked through what it costs to rebuild Salesforce from scratch on AWS and Postgres: the database, the UI, process automation, integrations, security, and analytics. The honest number came out to hundreds of thousands of dollars in build cost plus a permanent maintenance bill, and that's before anyone touched compliance.

Most companies don't need that project. They need a smaller Salesforce bill, less admin overhead, and fewer things breaking on Sunday night before a Monday demo. That is a different, much more achievable goal, and it starts from a fact almost nobody wants to say out loud: most of what you're paying for isn't being used.

Across the industry, fewer than 37% of sales reps use their CRM daily, and an estimated 79% of the opportunity data reps actually gather never makes it into the system at all (VantagePoint). Reps spend about 17% of a 40-hour week on CRM and data entry, versus 28% actually selling, with top performers pushing data entry down to 8 to 10% (Salesmotion). Meanwhile, 20% to 55% of CRM implementations fail to meet their strategic objectives, mostly from poor adoption, not bad software (VantagePoint).

That's the real starting point for a shrink project. You are not fighting Salesforce. You are fighting years of unused licenses, dead automations, and features nobody asked for that got turned on anyway.

What this guide covers

This is a practical audit-and-cut checklist, organized the same six ways as the rebuild article: database, UI, process automation, integrations, security, analytics. For each one, you'll get what to look at, what typically gets cut, and what typically has to stay.

Then, because you asked the bigger question directly, the guide closes with a spectrum: how far past "shrink Salesforce" you could reasonably go, up to and including a chat-plus-database-plus-agents system of record, and what the evidence says is proven right now versus still a bet.

Before you touch anything: run the audit

You cannot cut what you haven't measured. Before any of the six sections below, pull three reports out of Salesforce itself:

• License utilization: last-login date per user, grouped by profile. Anyone without a login in 60 days is a candidate for downgrade or removal.
• Object and field usage: field history and page-layout usage where available, or a manual sample of 20 records per object asking "does anyone actually fill this in."
• Automation inventory: every active Flow, Process Builder process, Workflow Rule, approval process, and assignment or escalation rule. Most orgs have far more live automation than anyone remembers building, and a chunk of it is quietly firing on records nobody looks at anymore.

This audit alone, done honestly, usually finds the first 15 to 20% of savings before you change a single line of configuration.

Database: stop paying to store what nobody reads

What to look at

Object count, field count per object, and how many of those fields have a non-null value on more than half of records. Salesforce makes it easy to keep adding custom fields and easy to never remove them. Every unused field is schema debt: it still shows up in page layouts, still gets migrated, still confuses new hires, and still has to be accounted for in every future integration.

What typically gets cut

• Custom fields with under 20% fill rate that aren't required by a downstream integration or report
• Duplicate or near-duplicate objects created by different teams solving the same problem twice
• Legacy fields from a sunset product line, acquired company, or abandoned initiative
• Unused record types and page layouts, which multiply admin time every time a process changes

What has to stay

Anything feeding an active integration, anything referenced in a compliance report, and anything with real historical value even if current fill rate is low (annual contract data, for example, fills in bursts, not steadily).

The move that pays for the rest of the project

Downgrade or remove licenses for users who haven't logged in. At Salesforce Enterprise list pricing of $175 per user per month, every ten inactive seats removed is $21,000 a year back, before you've simplified anything else (Salesforce).

UI: cut the screens nobody opens, before you build anything new

What to look at

Page views and report-run counts, if your edition surfaces them, or a two-week informal survey of "what tabs do you actually have open." Salesforce's real UI cost isn't the screen, it's everything behind it: list views, saved filters, Omni-Channel routing rules, and dashboard subscriptions that accumulate for years and get carried forward by default (Salesforce Help).

What typically gets cut

• Dashboards and reports with no run in 90 days. Kill them before migrating anyone to a new layout, not after.
• Custom Lightning pages built for a workflow the team no longer follows
• Extra list views. Most teams settle on 3 to 5 views per object that actually get used; audits routinely find 15 to 30 configured.
• Mobile-specific customizations for a feature the team accesses from desktop 95% of the time

What has to stay

Anything a support agent relies on during a live customer interaction (queue views, SLA countdowns), and the core pipeline kanban view for sales, since that's consistently the highest-friction thing to lose in any UI change.

The realistic goal here isn't zero UI work. It's fewer screens, each one earning its place. A UI simplification pass on an existing Salesforce org, done by an admin, typically takes days, not the weeks a from-scratch rebuild UI takes to design and ship.

Process automation: kill duplicate and dead automations, and deal with the deadline you already have

What to look at

Every Flow, Process Builder process, Workflow Rule, approval process, and assignment or escalation rule, with last-modified date and a rough guess at last-fired date.

What typically gets cut

• Automations built for a process the company no longer runs (an old lead-scoring model, a discontinued approval chain)
• Duplicate logic where two Flows do almost the same thing because they were built by different people at different times
• Automations that fire on every record update but only need to fire on a specific field change, which is a quiet source of hidden org-wide slowdowns

What you don't get to choose to keep

Workflow Rules and Process Builder both lose Salesforce support on December 31, 2025 (Salesforce Help). If your org still runs on either one, you have a mandatory rebuild onto Flow already coming, whether or not you do anything else in this guide. That's not optional cleanup, it's a deadline. The efficient move is to combine it with this audit: rebuild only the automations that survived the cut, on Flow, once, instead of migrating dead automation you were about to delete anyway.

What has to stay

SLA and escalation logic for support. This is usually the single most business-critical piece of automation in the org and the easiest to underestimate, in a rebuild or a shrink.

Integrations and API: consolidate before you connect anything new

What to look at

Every connected app, AppExchange package, and API consumer currently touching Salesforce. This is usually the most surprising audit result, because most orgs have several integrations nobody remembers approving.

What typically gets cut

• Managed packages installed for a single feature that a native Salesforce capability now covers
• Point-to-point integrations that duplicate what a single consolidated sync (a CDP, an iPaaS tool, or a direct connector) could handle for less
• API consumers built for a system the company no longer uses

Where the real leverage is

The Model Context Protocol (MCP) has become a real, governed integration standard rather than a proprietary bet. It reached a stable specification for interactive apps in January 2026, is now overseen by the Linux Foundation's Agentic AI Foundation, and has more than 97 million monthly SDK downloads and thousands of active public servers (MCP Apps spec; Practical DevSecOps; Digital Applied). If you're consolidating integrations anyway, building the replacement against an MCP-compatible tool rather than a bespoke API saves you from re-doing the same integration work again in two years when the next tool changes.

The honest caveat

MCP servers are new enough that security scans of the ecosystem have found real problems. Independent scans found path traversal issues in 82% of over 2,600 implementations checked and command injection in 43% of servers scanned (Practical DevSecOps). If you consolidate onto MCP-based tooling, treat it like any other new vendor: check what's actually been security-reviewed before connecting it to customer data, not after.

Security: don't let a shrink project quietly shrink your compliance posture

What to look at

Which certifications your Salesforce contract currently satisfies for your customers or regulators (SOC 2, HIPAA, PCI DSS), and which of your simplification candidates from the sections above touch any data covered by those certifications.

What typically gets cut

Shield add-ons for field-level encryption or event monitoring on objects that don't hold sensitive data. Shield runs roughly 10 to 30% of net license spend, so verifying it's actually protecting something is a real line-item check, not a formality (Redress Compliance).

What absolutely does not get cut

Access controls tied to a contractual compliance obligation, or role-hierarchy logic that determines who can see what. If you're moving any workflow to a lighter external tool as part of the shrink, check its compliance tier before you move data into it. Several of the lightweight alternatives put audit logging and SSO behind their higher-priced tiers rather than including it by default (Twenty CRM's audit logs are on its $19/user/month Organization tier, not its $9 tier; Baserow's are on its $18/user/month Advanced tier, not its $10 tier) (Twenty; Baserow).

A regulatory date worth having on the calendar regardless of what you cut

The EU AI Act's transparency rules under Article 50 start applying on August 2, 2026, which is squarely relevant if any customer-facing support tool in your stack, present or planned, uses AI (EU AI Act timeline).

Analytics: keep the five reports people actually run, cut the four hundred they don't

What to look at

Report and dashboard run counts sorted by last-run date, and every scheduled report subscription. Subscriptions are the easiest thing to miss in an audit because they run silently in the background and nobody notices when they stop mattering.

What typically gets cut

The long tail of one-off reports built for a single meeting years ago and never touched again. Every mature Salesforce org accumulates hundreds of these. There's no benchmark for exactly how many are dead weight, and that itself is the tell: if nobody can say off the top of their head which reports matter, most of them don't.

What has to stay

The handful of dashboards that actually drive a recurring decision, pipeline forecasting and support SLA or case-volume tracking chief among them for a sales-and-support org. Rebuild or re-point those first if you're moving analytics to a lighter tool; treat everything else as backlog, not a blocker.

Putting it together: what a shrink actually saves

None of this requires leaving Salesforce, and it's worth doing even if you never do. A rough example for a 400-person company running 120 CRM seats: removing licenses for genuinely inactive users, killing dead automations and reports, and dropping unused add-ons commonly recovers somewhere in the range of 15 to 30% of total license and admin overhead, without touching core functionality anyone actually relies on. On a $252,000-a-year Enterprise-edition bill for 120 seats, that's meaningfully real money recovered in weeks, not years, and none of it requires a single line of new infrastructure (Salesforce).

That's stage one, and for a lot of companies, it's also the last stage they need.

How far past that do you want to go?

Here's the harder question: if the future really is a chat interface plus a database plus agents running the company, how much of that do you build now versus later, and what does the evidence actually support today?

Think of it as a spectrum, not a decision. Each step past "shrink Salesforce" asks you to trade a proven, bounded cost for a larger, less certain one.

Step one: shrink in place. Everything above. Low risk, real savings, no new technology to operate. This is the only step with a well-established success rate, because it doesn't depend on unproven pieces.

Step two: move low-complexity workflows off Salesforce onto a lightweight, purpose-built tool. Not a rebuild, a swap. Tools like Twenty CRM ($9 to $19 per user per month), Attio (free tier up to 3 seats, then roughly $35 to $99 per user per month), or Baserow ($10 to $18 per user per month) already include the database, a usable UI, row-level permissions, and in most cases a built-in MCP server or API, for a fraction of Salesforce's list price (Twenty; Attio; Baserow). This works well for a genuinely narrow process: a single pipeline, a single support queue, a team that doesn't need territory management or CPQ. It works badly if you try to force a complex sales motion into a tool built for a simple one.

Step three: add agents for the high-volume, well-defined work, on top of whatever database you land on. This is where AI customer support already has real, if vendor-reported, traction, and it's genuinely decoupled from which CRM sits underneath. Intercom's Fin prices resolutions at $0.99 each; Salesforce's own Agentforce prices conversations at $2 each (Intercom; Salesforce Agentforce pricing). Support deflection is not a reason to keep or leave Salesforce specifically. It's a reason to add an agent layer regardless of what your system of record is.

Step four: let chat and generative UI become a real entry point to the database, not just a search box. This is newer and more genuinely promising than most coverage suggests, but it's specific about where it works. The technical standard for rendering interactive interfaces inside a chat conversation, MCP Apps, reached a stable specification in January 2026 and is described by its maintainers as production-ready, with Claude and ChatGPT both adding host support (MCP blog). Text-to-SQL, the other half of this step, is strong on small, clean, well-documented schemas: top systems now score above 81% on the BIRD benchmark (BIRD leaderboard). That's a real, working combination for the routine 80% of CRM interactions: "what's the status on the Acme account," "log this call," "show me tickets breaching SLA today."

Step five: make chat and agents the primary system of record for everything, including the hard 20%. This is the step the evidence actively argues against right now, and it's worth being specific about why, because the reasons are concrete rather than merely cautious.

• The most-cited proof point for this exact move doesn't hold up. Klarna's CEO, after widely reported claims that the company had shut down Salesforce with an LLM, corrected the record directly: "we did not replace SaaS with an LLM... we developed an internal tech stack, using Neo4j and other things," and Klarna later rehired human support agents after AI-only support produced lower quality outcomes (TechCrunch; Fortune).
• Internally built AI systems succeed far less often than purchased ones. MIT's widely cited 2025 study found 95% of organizations saw no measurable return from generative AI pilots, and that internally built tools succeeded at roughly one-third the rate of purchased vendor tools (Fortune). Gartner separately forecasts that over 40% of agentic AI projects will be canceled by the end of 2027 (Gartner).
• Agent reliability isn't consistent enough for a system of record. On a standard agent benchmark for realistic customer service and retail tasks, GPT-4o's success rate drops from under 50% on a single attempt to below 25% when the same task is repeated eight times (Benchmarking Agents). A system of record that gives a different answer to the same question on different days is a liability, not a feature.
• Text-to-SQL collapses on real, complex schemas, which is exactly what a mature CRM database looks like. The same model and code that scores 91.2% on a simple benchmark schema drops to 73.0% on a moderately complex one and 21.3% on enterprise-scale schemas with the kind of column counts and query complexity a real company accumulates over years (Colrows).
• Chat doesn't actually help on the tasks that matter most. A controlled 2026 study of 134 industrial decision-makers found that a conversational interface felt easier than a dashboard, but was not faster and was not more accurate, and its comfort advantage disappeared almost entirely as task complexity increased, precisely on the pipeline reviews, forecasts, and bulk operations that a sales and support org runs constantly (arXiv:2605.31287).
• The savings relocate rather than disappear, and a new attack surface opens up. Curative, the clearest real example of a company that actually did this, saw its AI model spend increase sixfold month over month after leaving Salesforce, and its CEO called ongoing maintenance "definitely one of the most challenging pieces" (Business Insider). Separately, independent security scans found prompt-injection attacks succeeded against MCP-connected tools up to 72.8% of the time, with refusal rates under 3% in the worst-performing client tested (arXiv:2603.22489v1).

The line worth drawing today

Put together, the evidence supports a narrower and more useful version of your thesis than "replace Salesforce with a chat box." It supports this: a mid-market sales and support org can run on a small, deliberately simple Postgres schema, with agents handling the high-volume repetitive work, chat as a genuine and growing entry point for the routine 80% of requests, and a conventional graphical interface still doing the job for pipeline review, forecasting, and anything involving bulk comparison across many records at once.

The one real case study that got closest to this full thesis, Curative, is genuinely instructive, and it also quietly proves the limit: they still run Slack (Business Insider). Even the company furthest out on this curve didn't try to make chat the only interface. They made it the primary interface for the workflow they'd deliberately simplified enough for it to work.

That's the practical takeaway for stage sequencing. Shrink first, because it's low-risk and pays for everything after it. Simplify the schema aggressively before you point any agent at it, because a small clean database is the one precondition every failure mode in this research agrees on. Add agents where the task is high-volume and well-defined, because that's where the pricing and the benchmarks both actually work today. Let chat earn its way into being the primary interface for the routine work, one workflow at a time, rather than betting the system of record on it from day one. How far you take that last step is a real choice, and right now it's a choice with a genuine, well-documented downside if you move faster than your data model and your agent evals are ready for.