When to Walk Away from Salesforce: The Honest Strategic Assessment

Why This Tutorial Exists

Almost no content in the Salesforce ecosystem is written by people who are willing to say "don't use Salesforce." That is not surprising. The ecosystem — the partners, the consultants, the bloggers, the certification programmes, the user community — has a structural interest in Salesforce's continued use. Advising against it is professionally and economically counterintuitive. The result is a content landscape that is essentially one-directional: every problem has a Salesforce solution, every organisation would benefit from more Salesforce, and the only bad Salesforce implementation is one that wasn't done by the right partner.

This tutorial is the exception. Understanding when a platform is the wrong answer for your organisation is as strategically valuable as understanding when it's right. A CTO who can only advocate for Salesforce is not giving their board strategic counsel — they are managing a vendor relationship.

I should be clear about what this tutorial is not. It is not an anti-Salesforce polemic. It is not a competitor's marketing document. Salesforce is genuinely excellent for certain use cases, and this tutorial starts by establishing those clearly. The credibility of the cases for walking away depends on the integrity of the cases for staying. If I'm not honest about where Salesforce wins, nothing I say about where it loses should be trusted.

What this tutorial is: an honest assessment of the scenarios where the platform is structurally mismatched to an organisation's needs, a framework for calculating the true cost of the relationship, and a practical guide to having a board-level conversation about platform reconsideration that is analytical rather than political. If you're a CTO who suspects your Salesforce investment is not delivering the value the original business case promised, this tutorial will give you the vocabulary and the framework to investigate that honestly.

The Cases Where Salesforce Genuinely Wins

Credibility requires starting here. There are use cases where Salesforce is not just adequate — it is genuinely the best available option, and the case for staying or investing further is strong. Organisations in these scenarios should be increasing their Salesforce maturity, not questioning it.

Large Enterprise B2B Sales with Complex Process Requirements

For a large enterprise with a complex B2B sales process — long sales cycles, multi-stakeholder deals, significant pre-sales investment, formal pipeline management — Salesforce Sales Cloud remains the benchmark. No other platform has the depth of sales process functionality, the ecosystem of add-on products (CPQ, Revenue Cloud, Partner Community), or the maturity of reporting and forecasting capability that Salesforce offers at enterprise scale.

If your sales organisation has more than 500 salespeople, manages deal sizes above £100k, runs formal pipeline reviews at the executive level, and needs sales process automation that goes beyond basic CRM, the case for Salesforce is strong. The platform was designed for exactly this use case and has been refined for 25 years. Switching to a lighter-weight alternative would mean accepting meaningful capability loss.

Multi-Cloud Salesforce with Deep Integration Needs

Organisations that have built across multiple Salesforce clouds — Sales, Service, Marketing, Commerce — with genuine integration between them are in a different position from those using a single cloud in isolation. The value of the Salesforce platform is compounded when data flows between Sales Cloud opportunities and Service Cloud cases, when Marketing Cloud journeys are triggered by Sales Cloud signals, when Commerce Cloud purchase events update Service Cloud customer records.

This integration fabric takes years to build and is genuinely difficult to replicate with best-of-breed alternatives. The argument for staying is not inertia; it's that the multi-cloud integration you've built is a genuine competitive asset, and the replacement would take longer and cost more than the original investment.

Regulated Industries Requiring Shield-Level Compliance

Salesforce Shield — the combination of Platform Encryption, Event Monitoring, and Field Audit Trail — provides a compliance infrastructure that few alternatives match at scale. For organisations in financial services, healthcare, or other heavily regulated sectors where data residency, encryption at rest, and complete audit trails are regulatory requirements rather than preferences, Shield represents a significant portion of the platform's value.

The cost of replicating Shield-equivalent compliance capability on an alternative platform is typically underestimated. It's not just a feature check — it's the operational maturity of Salesforce's compliance documentation, the established relationship with regulators who have already evaluated Salesforce's controls, and the audit history you have accumulated. Walk away from that and you start a multi-year compliance rebuilding process.

Organisations with Deep Ecosystem Investment

If your organisation has spent five or more years building Salesforce capability — trained internal teams, established governance, a mature development pipeline, internal architects who know the platform deeply — you have an asset that is not visible on any balance sheet. The depth of institutional Salesforce knowledge in your organisation is a genuine strategic advantage. The people who know how to build on the platform well, who know where the limits are and how to design around them, who have made the mistakes and learned from them — that capability takes years to develop and cannot be replicated cheaply by switching platforms.

For these organisations, the "stay" case is not about the platform in isolation. It's about the total value of the ecosystem investment, including the human capital that has been built around it.

The Cases Where Salesforce Is the Wrong Answer

With those foundations established, here are the scenarios where Salesforce is structurally mismatched — where the platform's strengths are not relevant to the organisation's needs, and its costs are not justified by the value it delivers.

Small to Mid-Size Companies with Simple CRM Needs

Salesforce was built for enterprise complexity. If your organisation has 50 salespeople, a straightforward B2C or SMB sales motion, and CRM needs that amount to contact management, pipeline tracking, and basic reporting, you are paying enterprise platform prices for functionality that HubSpot CRM, Pipedrive, or even a well-configured Notion delivers at a fraction of the cost.

The decision criteria: if your CRM use case can be described in fewer than ten distinct process requirements, and none of those requirements involve multi-cloud integration, compliance-driven data handling, or more than two levels of relationship hierarchy, Salesforce is almost certainly over-engineered. The licence cost, implementation cost, and ongoing administration overhead are calibrated for enterprise complexity that you don't have.

The counter-argument is growth: "we'll need enterprise capability eventually." This argument is almost always made in advance of the growth that would actually require it, and it costs real money every year in anticipation of a need that may be years away or may never materialise. Buy for the complexity you have, not the complexity you aspire to.

High-Volume, Low-Complexity Transactional Sales

If your primary sales motion is high-velocity, low-complexity — inside sales with short cycles, high deal volume, and low deal values — Salesforce's overhead is a friction cost on every transaction. Your salespeople are spending time on data entry that a simpler CRM would automate, navigating a UI designed for enterprise account management, and running reports that require a Salesforce admin to configure.

HubSpot Sales Hub was designed specifically for this motion. Its pipeline management, email integration, and activity tracking are optimised for volume rather than complexity. For a team of 40 inside salespeople closing 50 deals per month at an average value of £5k, the productivity delta between a well-implemented HubSpot and a well-implemented Salesforce is meaningful and consistently favours HubSpot. The Salesforce features your team isn't using are not free — they impose a UI complexity tax on every interaction.

Microsoft-First Technology Organisations

This is the case that most Salesforce practitioners are unwilling to make honestly. If your organisation runs Azure, Microsoft 365, Teams, SharePoint, Power BI, and is considering or already using Copilot — Dynamics 365 with native M365 integration may genuinely be better for you than Salesforce, regardless of Salesforce's functional depth.

The argument is not that Dynamics 365 is functionally superior to Salesforce. In most CRM capability dimensions it isn't, and Salesforce's lead in sales process sophistication remains real. The argument is that integration has value, and native integration has more value than API-based integration. When your CRM lives in the same identity fabric as your productivity suite, when Teams conversations are contextualised against CRM records natively, when Power BI pulls CRM data without a middleware layer, when your Copilot deployment has access to both customer data and organisational knowledge in a unified model — that is a technology experience that matters to users and reduces total cost of ownership significantly.

The specific decision criteria: if more than 70% of your knowledge workers are daily Microsoft 365 users, if your IT strategy is Azure-first, and if your CRM use case does not require Salesforce-specific capabilities (CPQ, Revenue Cloud, AppExchange ecosystem), the M365-native Dynamics 365 case deserves serious analysis. Not advocacy — analysis. Have someone do it honestly, without a pre-determined conclusion.

Manufacturing and Distribution with ERP-Centric Workflows

For manufacturing and distribution businesses where the ERP (SAP, Oracle, Microsoft Dynamics AX) is the system of record and sales, service, and customer management are downstream of production and inventory planning, Salesforce's CRM-centric data model creates an integration architecture that is permanently fighting against the system of record.

Account data that is mastered in SAP gets synchronised to Salesforce and immediately diverges. Product data that lives in Oracle gets replicated into a Salesforce product catalogue and goes stale. Order management that belongs in the ERP gets partially duplicated in Salesforce because the sales team wants pipeline visibility. The integration complexity is structural, not a consequence of poor implementation. It exists because you've placed a CRM-centric system in front of an ERP-centric business.

SAP CX and Oracle CX are designed to run CRM as an extension of the ERP rather than as a parallel system. For a business where 80% of the CRM data has its master copy in the ERP, that architecture has meaningful operational advantages over a Salesforce integration, regardless of Salesforce's CRM functional depth.

Organisations Where Total Cost of Ownership Is Genuinely Unaffordable

This is the case most often obscured by the framing of the original business case. The original Salesforce business case was written against a specific licence count, a specific implementation scope, and an assumption about ongoing operational costs. Three years later, the licence count has grown by 40%, the customisation footprint has tripled, the partner relationship is ongoing rather than concluded, and the two internal Salesforce administrators who were going to manage the system have become six.

When the total Salesforce investment — licences, implementation debt, ongoing development, administration, partner fees — represents more than 8-10% of the total technology budget for an organisation of your size, and the business outcomes being delivered by Salesforce are not differentiated from what a simpler, cheaper platform would deliver, you have a TCO problem. That is not a Salesforce problem per se — it's a portfolio management problem. But the solution may involve Salesforce, and pretending otherwise is not strategic counsel.

The Hidden Costs That Change the Calculation

The most common reason platform exit assessments produce the wrong answer is that they compare the visible costs of Salesforce against the visible costs of the alternative. The calculation that determines whether an exit is genuinely rational includes several costs that are either invisible on the current P&L or are presented in ways that obscure their true trajectory.

Licence Creep: How a £500k Commitment Becomes £2M

Salesforce licence contracts have a characteristic trajectory. The initial commitment is based on a defined user population and a defined cloud scope. Over the subsequent three to five years, several things happen: additional user licences are added as the system proves useful and new teams want access; add-on products are purchased (Sales Engagement, Revenue Intelligence, Data Cloud) to address capability gaps; licence tiers are upgraded from Professional to Enterprise or Enterprise to Unlimited; and platform licences are added for communities, portals, or partner access.

None of these expansions is irrational in isolation. Each represents a decision that delivered value at the time. Collectively, they produce a licence commitment that is two to four times the original contract value, often without a corresponding re-evaluation of whether the original business case still holds at the new price point.

To understand your true licence trajectory, pull your Salesforce contract history and map actual spend by year. Then project forward using your average annual growth rate. The number that results — the three-year forward licence commitment at current trajectory — is the number your board should be seeing. In most organisations, it hasn't been presented in that form.

Customisation Debt: When Every Release Becomes Expensive

Every Apex class, every complex Flow, every custom object relationship, every managed package integration adds to your organisation's customisation footprint. In the early years of a Salesforce implementation, this footprint grows quickly and the cost of each addition is low. After five to seven years, the footprint has accumulated to the point where no change can be made in isolation — every development task requires regression testing of a large and increasingly complex system.

The symptom is familiar to any CTO who has managed a mature Salesforce org: the sprint velocity that started at ten story points is now at four. The development team that was three people is now six. The release cycle that was fortnightly is now quarterly because the testing overhead has become unmanageable. These symptoms are not a consequence of poor development practices — they are the predictable accumulation of customisation on a shared platform over time.

Measuring customisation debt requires a technical audit: how many active Apex classes, Flows, triggers, and custom objects does your org contain? What is the test coverage of the custom codebase? How many managed packages are installed, and when were they last updated? What is the Salesforce-assessed technical debt score for your org? Most organisations have never commissioned this audit. The result is that customisation debt is felt as "things take longer now" without being quantified as a specific cost — which means it is never incorporated into the platform reconsideration calculus.

Talent Dependency: The Hidden Hostage Situation

Salesforce talent is expensive and scarce. A senior Salesforce architect with genuine multi-cloud expertise earns between £90k and £140k in the UK market. A mid-level Salesforce developer with strong Apex skills earns £65k to £90k. These are premium rates compared to generic software development talent, and they reflect a labour market that has structurally more demand than supply.

The dependency risk is not the cost in isolation — it's the concentration. Most enterprise Salesforce organisations have between two and six internal Salesforce-specialist staff. The departure of the lead architect or the senior administrator creates an immediate operational crisis that takes six to twelve months to recover from. This concentration creates a leverage dynamic that benefits employees and partners at the expense of the organisation.

The question to ask honestly is: how many people in your organisation could leave tomorrow and make the continued operation of your Salesforce instance genuinely difficult? If the answer is fewer than three, you have a talent concentration risk that belongs on your risk register and in your platform reconsideration assessment.

Partner Dependency: The Engagement That Never Ends

Most Salesforce implementations are delivered by a systems integrator. The original engagement is scoped, contracted, and concluded. In practice, very few organisations reach a state of genuine Salesforce self-sufficiency. The partner relationship that was supposed to end at go-live transitions into a "run and optimise" retainer, which transitions into a "strategic roadmap" engagement, which transitions into a new programme for the next cloud or the next phase of functionality.

This is not inherently wrong — complex platforms require ongoing specialist support. What is wrong is when the partner dependency is structural rather than chosen: when the organisation lacks the internal capability to manage the platform without the partner, when the partner relationship is a cost that appears annually but has never been subjected to a make/buy analysis, and when the organisation has no credible alternative to the incumbent partner because the platform knowledge has been retained by the partner rather than transferred.

The partner dependency cost is often invisible because it appears as multiple line items — project costs, retainer fees, licence procurement assistance — rather than as a single "total partner cost" number. Aggregating those line items across a three-year period and comparing them against the internal capability that would replace them is a standard piece of analysis that most boards have never seen.

The Exit Assessment Framework

An exit assessment is not a decision to leave. It is a structured investigation that produces the information required to make the decision rationally. Organisations that resist conducting exit assessments are almost always doing so because they're afraid of what the assessment will find — which is, in itself, a data point worth noting.

Step 1: Map Your Current Salesforce Dependencies by Category

Before evaluating alternatives, you need an accurate picture of what you actually use Salesforce for — not what the original business case said you would use it for. This mapping should cover five categories: core business processes that are natively run in Salesforce (pipeline management, case management, campaign tracking); custom processes that have been built specifically on the platform (bespoke objects, custom Apex logic, specialist flows); integrations where Salesforce is the system of record or a critical integration hub; reporting and analytics capability that is Salesforce-native (dashboards, reports, Einstein analytics); and compliance and audit capability (Shield encryption, event monitoring, audit trails).

For each category, assess the business criticality (would the business stop if this capability disappeared tomorrow?) and the uniqueness (is this a capability that is specific to Salesforce or broadly available across platforms?). The result of this mapping is a dependency matrix — a clear picture of what you're actually using, how critical it is, and how replaceable it is. Most organisations have never done this systematically, and the result of doing it is usually a more nuanced picture than either the "Salesforce is critical to everything" or "we barely use it properly" narratives that tend to dominate internal conversations.

Step 2: Assess Replaceability

Replaceability is not binary. It exists on a spectrum from "easily replaced by multiple alternatives" to "genuinely irreplaceable within a reasonable timeframe." For each dependency identified in Step 1, assess replaceability honestly.

Core sales pipeline management: easily replaceable by HubSpot, Dynamics 365, Pipedrive, or a dozen other CRM platforms. The transition is complex but the functional replacement exists. Multi-cloud integration fabric built over five years: genuinely difficult to replace. The integration points, the data models, the process automations that span clouds — rebuilding this on an alternative platform is not a matter of licence substitution. It's a multi-year programme. Salesforce CPQ with complex pricing rules, approval workflows, and contract management: replaceable, but the replacement (SAP CPQ, Oracle CPQ, Conga) requires significant implementation effort and will not provide feature parity without customisation.

The replaceability assessment should be done with specific alternative platforms in mind, not in the abstract. "Is this replaceable?" is a less useful question than "Could HubSpot replace this? Could Dynamics 365? In what timeframe, at what cost?"

Step 3: Calculate True Exit Cost

Exit cost has four components, all of which must be calculated to produce a credible number. Migration cost: the cost of extracting data from Salesforce, transforming it for the target platform, loading it, and validating it. On a large enterprise org with complex data relationships, this is rarely below £500k and frequently exceeds £2M. Re-implementation cost: the cost of rebuilding your current processes on the alternative platform. This is not the same as the cost of a greenfield implementation — it includes replicating existing automation, integrations, and reporting capability. Transition cost: the cost of running parallel systems, retraining staff, and managing the organisational change of a platform switch. And productivity loss: the productivity cost of the organisation operating a new system in the months after switch, before the new platform reaches the operational maturity of the old one. This last cost is almost always omitted and almost always significant.

The exit cost calculation that most boards are presented with omits productivity loss entirely and underestimates migration and re-implementation cost by 40-60%. A credible exit cost analysis should be prepared by someone who has actually executed a CRM migration, not estimated by someone who hasn't.

Step 4: Evaluate Strategic Alternatives for Your Use Case

The alternative platform evaluation should be use-case specific, not platform-general. The question is not "is Dynamics 365 better than Salesforce?" — it is "is Dynamics 365 better than Salesforce for our specific combination of use cases, our technology stack, our team composition, and our strategic direction?" Those are different questions with potentially different answers.

For each credible alternative, evaluate: functional fit against your top-ten process requirements; integration fit with your existing technology stack; TCO over five years (licensing plus implementation plus ongoing administration); talent market depth in your geography and industry; and strategic trajectory (is this platform investing in the capabilities you'll need in three to five years, or is it in maintenance mode?).

Step 5: Present the Decision as a Portfolio Choice, Not a Technology Choice

The framing that works with boards is portfolio management, not technology assessment. The question is not "should we use Salesforce or Dynamics?" — it's "given our current technology portfolio, our strategic direction, and our financial constraints, how should we allocate our technology investment to deliver the best business outcomes over the next five years?" Salesforce is one option in that portfolio conversation. Dynamics 365, rationalised Salesforce, or a lighter-weight CRM are others.

This framing matters because it removes the binary quality of the technology choice. A board that is presented with "stay with Salesforce or switch to Dynamics" will default to staying, because switching feels risky and the sunk cost of the current investment looms large. A board that is presented with "here are three investment scenarios for our CRM capability over the next five years, with different risk and return profiles" is in a much better position to make a strategic decision.

Having the Board Conversation

The technical assessment is the easier half of the challenge. The harder half is presenting a platform reconsideration to a board that has approved multiple rounds of Salesforce investment, is aware of the sunk costs involved, and may include board members who have personal or professional relationships with Salesforce as a company. This section is about how to have that conversation in a way that produces a rational decision rather than a defensive reaction.

The Data You Need Before the Conversation

Walking into a board conversation about platform reconsideration without comprehensive data is the single most common reason these conversations fail. The data you need falls into three categories.

Actual costs: Total Salesforce spend over the past three years, broken down by licence, implementation, development, administration, and partner fees. Not the budget lines — the actual expenditure, aggregated across all cost centres that touch Salesforce. Most CTOs are surprised by this number when they first calculate it properly. The number your board should see is "we have spent £X on Salesforce in the past three years, and our forward commitment at current trajectory is £Y over the next three years."

Actual usage: What percentage of the licensed functionality is being actively used? What is the active user rate against licensed users? What processes were supposed to be run in Salesforce that are actually being run outside it? This usage data is available in your org and in Salesforce's own usage analytics — most organisations have never pulled it systematically. A platform where 40% of licences are unused and 30% of intended processes are being run in spreadsheets alongside the system is not delivering its designed ROI.

Actual business outcomes: What outcomes were the business case for Salesforce built on — pipeline visibility, forecast accuracy, customer service response times, marketing lead quality? Have those outcomes been measured? Against what baseline? This is the hardest data to assemble because most organisations never established the baseline measurements required to assess Salesforce's contribution to business outcomes. The absence of this data is itself a finding: if you've spent £3M on a platform over three years and you can't tell whether it's made the business more effective, that's a governance problem worth naming.

The Three Scenarios to Present

Never present a binary choice to a board. Binary choices produce political dynamics — people choose sides rather than evaluating options. Present three scenarios that represent a range of strategic investment levels.

Scenario A: Stay and Invest. Continue with Salesforce, address the capability gaps through additional investment, resolve the customisation debt through a technical remediation programme, and commit to the platform for the next five years. Articulate the investment required, the outcomes it should deliver, and the metrics by which success will be measured. This is the "double down" option — it's only credible if it comes with a genuine commitment to the investment and the measurement.

Scenario B: Stay and Rationalise. Continue with Salesforce but reduce scope — consolidate to the clouds and user populations where the value is clearest, retire custom development that isn't being used, renegotiate the licence commitment, and invest the savings in capability that addresses the actual business gaps. This is frequently the most rational option for organisations where Salesforce is genuinely valuable for some use cases but over-deployed overall.

Scenario C: Plan an Exit. Over a defined timeline — realistically three to five years, not six months — migrate to an alternative platform that is better suited to the organisation's current needs and strategic direction. Present the exit cost, the transition risk, the alternative platform assessment, and the long-term TCO comparison. This option should only be recommended if the data genuinely supports it — not as a negotiating position with Salesforce.

Handling the Sunk Cost Response

"But we've already invested so much" is the most predictable response to a platform reconsideration, and it is one of the most economically illiterate arguments in corporate decision-making. The sunk cost fallacy — making future decisions based on past expenditure rather than future expected value — is well understood in theory and almost universally practiced in reality.

The response that works: "The £X we've invested is gone regardless of what we decide today. The decision in front of us is whether to invest £Y more in Salesforce or £Z in the alternative, and which investment produces better business outcomes over the next five years. The past investment is not an argument for either option." This reframing needs to be stated plainly and without apology. It will be uncomfortable. It is correct.

The sunk cost argument becomes even weaker when the past investment has not delivered the expected business outcomes. "We've invested £3M and we still can't produce a reliable sales forecast" is not an argument for investing another £1M — it's an argument for examining whether the additional £1M will solve the problem that the first £3M didn't.

What a Responsible Exit Timeline Looks Like

If the assessment supports a platform exit, the responsible timeline is three to five years, not six months or two years. The reasons are practical: data migration at enterprise scale takes twelve to eighteen months of careful planning and execution. Re-implementing complex business processes on a new platform while running the existing system takes another twelve to eighteen months. Staff retraining, partner transition, and operational stabilisation on the new platform takes a further twelve months. These phases overlap but cannot be compressed below a certain minimum.

Organisations that attempt Salesforce exits on two-year timelines almost always either fail to complete the exit or complete it with unacceptable operational disruption. The three to five year timeline is not timidity — it's the minimum responsible timeframe for an enterprise CRM migration. Any plan that promises a shorter timeline should be treated with scepticism proportional to how far below three years it goes.

The Decision

After the assessment, after the board conversation, after the scenarios — the decision still has to be made. This section provides the decision matrix and the signals that distinguish "stay and optimise" from "plan an exit."

The Decision Matrix

Four factors should drive the platform decision. Score each from 1 (strongly favours exit) to 5 (strongly favours staying).

Fit: How well does Salesforce's core functionality match your actual business requirements — not the requirements you once had or aspire to have, but the requirements you have today? A high-complexity enterprise B2B sales process with multi-cloud dependencies scores 5. A simple transactional sales process where the team uses three of fifteen available modules scores 1.

Cost: Is the total Salesforce investment — at current trajectory — proportionate to the business outcomes it delivers? If your Salesforce investment represents 8% of total IT spend and the business outcomes are clearly attributable and differentiated, score 4 or 5. If the investment has grown to 15% of IT spend with unclear business outcome attribution, score 1 or 2.

Dependency: How deeply embedded is Salesforce in your technology and organisational fabric? High multi-cloud integration, Shield compliance, and deep internal capability scores 5. Low platform adoption, simple use cases, and high partner dependency with low internal capability scores 1 or 2.

Strategic alignment: Does your technology strategy — cloud provider, productivity suite, AI direction — point toward or away from Salesforce? An Azure-first strategy with Microsoft 365 deep integration and a Copilot investment thesis points away (score 1-2). A best-of-breed strategy where Salesforce CRM is a deliberate choice for its specific capabilities points toward (score 4-5).

Total scores of 14-20 suggest staying and investing. Scores of 8-13 suggest staying and rationalising. Scores of 4-7 suggest a serious exit assessment is warranted. No model replaces judgement — but the model forces the conversation to be explicit about the factors rather than allowing one factor (sunk cost, political relationships, inertia) to dominate implicitly.

The Signals That Mean "Stay and Optimise" vs "Plan an Exit"

Stay and optimise signals: the business outcomes Salesforce was purchased to deliver are being delivered, but the implementation is underperforming — complexity, technical debt, under-adoption. The gap is between what Salesforce can do and what your implementation does. That gap is closeable with investment. The platform is right; the implementation needs work.

Plan an exit signals: the business outcomes Salesforce was purchased to deliver are not being delivered, and the analysis suggests the gap is structural — the platform is not well matched to the use case, or the total cost of the platform at the required capability level is not economically rational. The gap is between what Salesforce can do and what your business actually needs. That gap is not closeable by better implementation.

The One Question That Cuts Through All the Complexity

Every decision matrix, every scenario analysis, every TCO calculation is useful. But there is one question that cuts through all of it and typically produces an honest answer that the analysis supports:

"Would we choose Salesforce if we were starting today?"

Not "given what we've already invested, would we stay?" Not "given our existing team's skills, would we choose Salesforce?" Just: knowing what we know about our business, our team, our technology stack, our strategic direction, and the available alternatives — if we were making this decision fresh, would Salesforce be the answer?

If the honest answer is yes, you have a strong argument for staying. The sunk costs, the partner relationships, the institutional knowledge — all of these make the "stay" case even stronger than it would be for a new entrant. If the honest answer is no — if you would not choose Salesforce today for the organisation you are today — then the exit conversation is not optional. It's a question of when and how, not whether.

Most organisations already know their honest answer to this question. The work of this tutorial is to give you the analytical framework to defend that answer to a board — or to challenge your own assumptions if the analysis points somewhere different from where your instincts do.