The premise
A Salesforce replacement does not have to be a multi-year programme. The modules where ownership pays back fastest are workflows that look bounded from the outside and are bounded on the inside too. The cost is per user. The integration surface is well-defined. The data shape is stable. The user community is small enough that a parallel-run period is manageable.
We have run versions of each of the five sprints below for real clients. The order here reflects how often the engagement is the right entry point for a Middle East enterprise looking to start trimming Salesforce spend without disturbing the customer-record system that other workflows depend on.
This is the working list. Pick the one that hurts most.
Module one — CPQ (Configure, Price, Quote)
Why this is the strongest first move. Salesforce CPQ is one of the highest per-user cost modules in the catalogue. The pricing scales with the sales-rep population, not with the volume of quotes the system generates. The integration surface is narrow: pull product master and pricing rules, push approved quotes back to the opportunity. The data contract to Salesforce is one of the cleanest in the estate.
Sprint shape. One two-week sprint. Pricing rules ported. Quote-approval workflow rebuilt against the real approval chain. PDF generation matched to existing template. Parallel run for one sales cycle against representative deals. The team that operates the new CPQ is the same team that operated the old one — typically two pricing analysts and a deal-desk manager.
What it retires. Salesforce CPQ per-user licences, the typical CPQ-extension app marketplace fees, the integrator's annual CPQ configuration retainer.
Module two — Service Cloud routing and knowledge
Why this is a clean sprint. Service Cloud's case routing and knowledge surface are workflows the service organisation owns, not workflows the customer touches directly. The case object can stay in Salesforce while the routing rules, knowledge base, and macro-action library move to owned software. The customer experience does not change. The cost structure does.
Sprint shape. One two-week sprint. Routing rules re-expressed in a transparent, editable form your service operations lead can update without a release. Knowledge migrated to a search surface that handles semantic queries the Salesforce-vended search does not. Agent macros replaced with an agentic assistant that drafts case responses against the knowledge base. The case routing decisions are now visible and auditable in a way they were not before.
What it retires. Service Cloud Einstein licences (the per-conversation surface) plus a portion of the Service Cloud licence allocation that was justified by the routing engine.
Module three — Marketing Cloud Personalisation
Why this is the right replacement candidate. Marketing Cloud Personalisation is per-active-profile pricing on a surface most marketing teams use for one or two specific recommendation slots in the customer journey. The per-profile cost is large enough to matter. The actual functionality used is small enough to be a sprint.
Sprint shape. One two-week sprint. The recommendation slots — typically a homepage hero, an email block, and a post-purchase recommendation — are replaced with a recommendation engine that reads from the customer-360 surface your team already owns. The model is your model. The A/B testing harness is your harness. The lift measurement is reproducible.
What it retires. Marketing Cloud Personalisation per-profile fees, the integration cost back to your event stream, and the implementation partner's quarterly retainer for tuning the vendor's model.
Module four — Pardot / Account Engagement
Why this is a sprint, not a programme. Pardot — now Account Engagement — is a marketing automation tool used by B2B marketing teams for nurture sequences, scoring, and form handling. The features actually used by most teams are a small subset of the product surface. The data the tool sits on top of is data your team already owns. The replacement is a workflow rebuild, not a platform build.
Sprint shape. One two-week sprint. The nurture sequences are re-authored on an owned email infrastructure that integrates with the same CRM the Pardot version did. The form-handling surface is replaced. The lead-scoring rules are re-expressed as a transparent function your demand-gen lead can edit without a vendor support ticket. The output back to Sales Cloud — qualified leads with scoring metadata — matches the existing contract.
What it retires. Pardot per-contact fees and the B2B Marketing Engagement upsell that bundles with it.
Module five — Loyalty Management
Why this is a high-leverage sprint for Middle East retail. Salesforce Loyalty Management is per-active-member pricing on a surface that, for a Middle East retailer with a mature loyalty programme, can run into a meaningful annual number. The features actually used are tier rules, redemption mechanics, and lifecycle communication. Each is a workflow your team can own.
Sprint shape. One two-week sprint. Tier rules and redemption mechanics ported. Lifecycle communication moved to owned email/SMS infrastructure. Member-facing surfaces in the app and the loyalty website moved to APIs your team owns. The customer experience is identical; the cost structure flips.
What it retires. Loyalty Management per-active-member fees, the implementation partner's ongoing tier-rule configuration retainer, and the indirect-access exposure created by every system that reads loyalty data from Salesforce.
The saasinator perspective
The argument for replacing Sales Cloud — the pipeline and opportunity surface — is rarely the right first argument. The argument for replacing the modules layered on top of Sales Cloud is much stronger. The five above share a shape: per-user or per-record pricing on a workflow with a narrow integration surface, a small operating team, and a clear data contract back to Salesforce.
We are not arguing for ripping out Salesforce. We are arguing for shrinking the surface. Each module retired reduces the renewal floor on the next contract. The Salesforce relationship continues; the dependency on the modules that hurt most ends.
How to pick which sprint goes first
Three questions:
- Which module has the highest per-user or per-record cost on your estate? Pull the licence schedule. Sort by cost-per-active-unit.
- Which module has the smallest operating team? A small team is easier to bring through a two-week parallel run. CPQ, Marketing Cloud Personalisation, and Loyalty all tend to score high on this.
- Which module's data contract back to Salesforce is the cleanest? A clean contract means a fast sprint. A messy contract means a programme. Read the integration logs.
The sprint that scores highest on all three is the sprint to run first.
Book a diagnostic. Bring your Salesforce licence schedule and a list of the modules currently active. Ten working days. We tell you which sprint flips first and what the next two look like behind it.