The argument was never only about servers

Control looks different depending on which side of the contract you're on

When Marc Benioff launched Salesforce in 1999, the pitch was simple enough to fit on a protest sign: no software. The argument was that enterprise software had become too expensive to buy, too slow to deploy, and too painful to maintain. Renting access to an application running on someone else's servers was positioned as liberation from all three. What the pitch left in small print was the corresponding loss of control over where your data sat, who could access it under a legal order, and what the vendor's uptime guarantee actually meant when it failed.

On-premise software — the kind that runs on hardware inside a building you own or lease — is not without its own coercions. Licences expire, vendors withdraw support on their own schedules, and the cost of a major upgrade can rival the cost of the original implementation. But the data is physically yours. The audit trail lives on your storage. Your legal team can respond to a disclosure request without routing it through a vendor's trust and safety team in another jurisdiction.

The SaaS (Software as a Service) model inverts this. The application is the vendor's responsibility to run and update, which is genuinely valuable — a finance team does not want to manage database patches. But the corollary is that the vendor controls the release cycle. Features appear, interfaces change, and deprecated functionality disappears on a timetable set in San Francisco or Walldorf, not in the customer's IT governance committee. The customer trades operational burden for schedule sovereignty.

The exit problem is structural, not incidental

The deepest issue in any hosted arrangement is not the monthly fee. It is data migration. A customer who wants to leave a SaaS ERP faces the same problem as one leaving an on-premise system: the data must come out in a form that the next system can read. The difference is that with on-premise, the database is under your physical control and you can run extraction scripts directly. With SaaS, you are dependent on the vendor's export functionality, which has historically been designed with less urgency than the import tools that brought you in.

This asymmetry is not accidental. Vendor lock-in in SaaS systems is embedded in data gravity — the sheer volume of transactional history, customisations and integrations that accumulate over years and make switching prohibitive regardless of what the contract says about portability. SAP and Oracle have operated this dynamic in on-premise markets for decades; Workday and Salesforce reproduce it in the cloud. The mechanism is different; the effect is the same.

There is also a regulatory dimension that varies by industry and by territory. Banks and healthcare providers in most jurisdictions operate under data residency requirements that specify where records must be physically stored and processed. A cloud vendor's multi-tenant infrastructure, distributed across regions for resilience, can create genuine compliance problems when a regulator asks which country a particular ledger entry was processed in. The answer "whichever availability zone had capacity" is not always acceptable. Edgar F. Codd's relational model, published in 1970, assumed nothing about where a relation would be stored; fifty years of regulatory overlay have since made the geography of storage a legal question, not merely an architectural one.

The practical response has been the hybrid deployment: core data kept on-premise under local governance, specific workloads moved to hosted infrastructure where the compliance picture is clear. This satisfies nobody cleanly. It inherits the operational complexity of on-premise and adds the integration overhead of SaaS, while the vendor's account team argues for full cloud migration on every renewal call.

None of this makes on-premise categorically correct or SaaS categorically wrong. Both models transfer risk: on-premise concentrates operational and upgrade risk inside the customer organisation; SaaS transfers it to a vendor whose interests are not identical to the customer's. The Post Office's Horizon system, which ran on-premise, is the limiting case of what happens when a customer cannot audit a vendor's system adequately regardless of who owns the hardware. Where the machines sit turned out to be irrelevant. Who could read the logs, and what they were permitted to say about them, was everything.