Cloud Strategy and Salesforce: PaaS Tradeoffs in 2026

The SaaS-to-PaaS Spectrum

When IT leaders describe Salesforce as "SaaS," they typically mean: Salesforce manages the infrastructure, handles upgrades, and provides a subscription model. This is accurate. But the practical reality for most enterprise customers is that Salesforce also provides a platform for custom application development via Apex, Lightning Web Components, Flow, and a rich API surface. They have built substantial intellectual property on that platform.

The spectrum matters because it changes the risk and governance model. Pure SaaS has minimal lock-in — you subscribe, you use the standard product, you could theoretically switch with data migration effort. PaaS has significant lock-in — your team's skills, your custom code, your integration patterns, and your business processes are invested in the platform. Switching requires rewriting applications, not just migrating data.

A useful diagnostic: if your Salesforce team consists entirely of administrators using declarative configuration, you are closer to the SaaS end. If your team includes Apex developers, LWC engineers, and integration specialists with significant custom codebases, you are firmly in PaaS territory. The investment decision — and the governance model — should reflect this honestly.

Three Dimensions of Platform Lock-in

Lock-in with Salesforce is real and multi-dimensional. Understanding the three dimensions allows you to manage it rather than pretend it doesn't exist or be paralysed by it.

Data Lock-in. Your customer, sales pipeline, and service history data lives in Salesforce. Extracting it for migration is feasible — Salesforce provides bulk APIs and data export tools — but transforming it into the schema of another platform is significant work. The mitigation: maintain a data extraction capability (regular exports to your own data lake or analytical platform), and ensure your data architecture does not make Salesforce the only path to your customer data.

Process Lock-in. Your business processes — the way your sales team works, how your service agents handle cases, how your marketing campaigns are orchestrated — are encoded in Salesforce configuration, automations, and custom code. These processes can be replicated on another platform, but the replication cost grows with the complexity and age of the configuration. The mitigation: document your key processes independently of Salesforce configuration. Process documentation that exists only in the form of Salesforce flows and Apex code is brittle both for migration purposes and for organisational knowledge management.

Skills Lock-in. Your team's Salesforce-specific skills (Apex, LWC, admin certifications) are not directly transferable to other platforms. This creates dependency on a Salesforce talent market and reduces your negotiating position with Salesforce. The mitigation: ensure your architecture uses standard patterns — REST APIs, standard data models, well-documented integrations — that reduce the Salesforce-specific knowledge required and make your system more accessible to a broader developer population.

Hyperforce: What It Means for Cloud Strategy

Hyperforce is Salesforce's infrastructure architecture that allows Salesforce products to run on public cloud providers (AWS, Azure, Google Cloud) in specific regions. This has four significant implications for enterprise cloud strategy.

Data residency. Hyperforce enables Salesforce to offer data residency in regions where it previously could not — including EU, UK, Australia, India, and others. For organisations with data sovereignty requirements (GDPR, financial services regulation, government contracts), Hyperforce removes a previous barrier to Salesforce adoption. Verify your specific regulatory requirements against Salesforce's current Hyperforce region availability before making commitments.

Infrastructure alignment. If your enterprise is standardised on Azure, and Salesforce's Hyperforce deployment in your region runs on Azure, you have better alignment for compliance, networking, and support. This alignment reduces integration complexity for virtual private connectivity (ExpressRoute/Direct Connect) and can simplify security review processes.

Latency. Hyperforce deployments are region-specific. If your primary user base is in Europe and you migrate to a European Hyperforce region, performance typically improves compared to a US-based Salesforce instance. This is a concrete operational benefit worth quantifying for the business case.

What Hyperforce does NOT change. Salesforce still manages the application layer. You have no visibility into or control over the underlying infrastructure. Hyperforce is not "Salesforce on your AWS account" — it is Salesforce choosing to use a specific cloud provider in a specific region. The operational model for customers is the same as traditional Salesforce hosting.

Multi-Cloud Positioning

Most large enterprises run a multi-cloud strategy — some combination of AWS, Azure, and Google Cloud, plus SaaS applications like Salesforce, Workday, and ServiceNow. Salesforce's place in this landscape has two dimensions.

As a SaaS/PaaS application, Salesforce sits alongside your other enterprise applications. The integration architecture — how data flows between Salesforce, your ERP, your data platform, and your internal systems — is the cloud strategy question. Building this integration on a middleware layer that is cloud-agnostic (MuleSoft, which Salesforce owns, or a cloud-native iPaaS like Azure Integration Services) is preferable to building direct point-to-point integrations that create tight coupling.

As a data platform, Salesforce Data Cloud competes with and integrates with hyperscaler data services (AWS Redshift/Sagemaker, Azure Synapse/OpenAI, Google BigQuery/Vertex). The choice of where to run your data unification and AI workloads — in Salesforce Data Cloud or in a hyperscaler — depends on where your data science capability and data engineering infrastructure are strongest. Many large enterprises run Data Cloud for Salesforce-native AI (Agentforce, predictive models on CRM data) while keeping their primary analytical and ML infrastructure on hyperscaler platforms.

Framing Salesforce in Enterprise Cloud Governance

Enterprise cloud governance models typically define policies for cloud-native development (what to build on hyperscalers), SaaS procurement (what to buy), and data residency (where data can live). Salesforce straddles all three categories and often falls into governance gaps.

Include Salesforce explicitly in your cloud governance framework. Define which categories of data can be stored in Salesforce, what security baseline applies to custom development in Salesforce (equivalent to your internal application security standards), how Salesforce instances are provisioned and deprovisioned, and what cost management governance applies to Salesforce spending alongside hyperscaler spending.

Cloud FinOps practice increasingly extends to SaaS applications. Salesforce licence optimisation — ensuring you are only paying for licences you use, that edition levels are appropriate for each user's actual usage, and that add-on products are generating value — should be a standard part of your cloud cost management function. A 10% reduction in Salesforce licence spend is often achievable without any capability reduction, and typically represents more savings than equivalent infrastructure optimisation in smaller hyperscaler environments.