Salesforce sunset: when to renegotiate vs rebuild

Salesforce renewal conversations have a particular emotional shape. The customer success rep introduces “exciting new features.” The account executive introduces “value-aligned pricing.” The legal team introduces a 4% uplift framed as below-inflation. The customer’s procurement team negotiates the uplift down to 2%. Everyone signs the renewal.

Six months later, the CFO looks at the cumulative annualised Salesforce bill — including Marketing Cloud, Service Cloud, Pardot, Tableau, MuleSoft, and the eight Sales Cloud add-ons — and asks the question that should have been asked at renewal: is this still the right system?

This post is a decision framework for when the right answer is renegotiate vs rebuild.

Renegotiate when

Three patterns where renegotiation is the correct posture:

1. Salesforce is still the right architectural choice. The standard objects fit your data model, the integrations work, the customisation footprint is small. The bill is the only complaint.
2. The org is heavily invested in admin / developer talent. Replacing Salesforce strands that talent. The friction cost is real and underestimated.
3. Your sales process is genuinely standard. Salesforce was built around a standard sales process. If yours is standard, the platform fit is good. If yours is unusual, the customisation surface is where the cost compounds.

If 2 of 3 apply, renegotiate. Use procurement leverage (multi-year deal, payment terms, scope reduction) to compress the bill, but stay on the platform.

Rebuild when

Three patterns where rebuild becomes the right answer:

1. The customisation surface is large. If your Salesforce org has 50+ custom objects, hundreds of triggers, workflow rules, validation rules, Process Builder flows, and Apex classes, you are running a custom CRM that happens to be hosted by Salesforce. The platform’s value-add has become small relative to the complexity tax.
2. The integrated bill exceeds the cost-equivalent custom team. When Sales Cloud + Service Cloud + Marketing Cloud + Pardot + Tableau + MuleSoft + the add-on stack costs $1.5M+/yr, the math starts to favour a custom CRM operated by a small dedicated team.
3. The platform is constraining sales process evolution. When sales operations cannot ship the workflow improvements they need because the platform’s customisation surface is brittle, the platform has become a constraint, not an enabler. This is often the trigger for the rebuild conversation.

If 2 of 3 apply, the rebuild conversation should be on the table. The renewal cycle is the natural inflection point.

The rebuild architecture

Custom CRM doesn’t mean reinventing the entire concept. The reference architecture we ship:

A typical Sales Cloud + Pardot + Tableau replacement runs 16–22 weeks fixed-price, $180K–$320K. Annual run cost: $30K–$60K (infra + email/SMS providers + maintenance). Compared to a $1.2M Salesforce bill, payback is under 12 months.

What the rebuild gets you

Beyond the cost reduction, three structural advantages:

1. Customisation as code, not configuration. Sales process changes ship as PRs, reviewed by engineers, tested in CI, deployed via standard release management. Salesforce customisation lives in click-paths that no one can review or test.
2. Data ownership. Your customer data lives in your database, in your cloud, queryable by any tool. Exit cost from a custom CRM is structurally lower than exit cost from Salesforce.
3. Workflow simplicity. The custom CRM does what your sales team does. It does not have ten years of accumulated features for use cases you’ll never have. The workflow is shorter, the screens are tuned, the operational training is simpler.

The trade-off: you carry the operational ownership. The rebuild requires an engineering team that can operate it.

The migration path

The migration is the hardest part, not the build. Three patterns:

1. Read replica during parallel-run. Salesforce stays the source of truth for 4–8 weeks while the new system mirrors. Sales team uses the new UI for everything but Salesforce data flows continue. Catches functional gaps before cutover.
2. Data migration with validation. All accounts, contacts, opportunities, activities migrated. Hash-based validation that the data round-trips identically. Discrepancies investigated before cutover.
3. Hard cutover with rollback option. On cutover date, Salesforce becomes read-only. The new system becomes source of truth. Salesforce remains accessible for historical lookup for 6 months, then archived.

This pattern minimises risk. It also requires discipline: parallel-run is operationally expensive; the temptation to rush the cutover is real.

What the rebuild isn’t

It isn’t a Salesforce replacement product. We don’t ship a SaaS that other companies can buy. Each engagement is a custom build for the specific client’s sales process. The reusability is in the architecture and the methodology, not in shippable code.

It also isn’t appropriate for every organisation. Below ~$300K/yr Salesforce spend, the rebuild math rarely works. Above $1M/yr, it often does. The middle is where the situational analysis matters most.

Read more: /upstream/salesforce-sales-cloud-alternative · /upstream/ · /case-studies/crm-migration-hubspot-to-d365