Press Release |  30th June 2026

There is a question that every CPO should ask before entering a cloud renewal negotiation: not “what is our target price?” but “do we actually have the ability to credibly walk away?” The answer, in most large enterprises, is no. The reasons why reveal something far more structural than a bad sourcing decision.

Over the past decade, the major cloud and enterprise software vendors such as AWS, Microsoft Azure, Oracle, SAP, and Salesforce have achieved something historically rare: they have made their customers genuinely dependent, not through coercion, but through utility. The trap doesn’t look like a trap. It looks like a solution. Understanding this dependency, its architecture, its logic, and its leverage points is the foundation of any credible cloud procurement strategy. And, curiously, history offers the clearest analytical framework available.

The Empire Analogy Is More Than a Metaphor. It Is a Model.

Each major cloud vendor has built its market position through a distinct structural mechanic that mirrors, with remarkable precision, the strategies of historical powers.

AWS, The British East India Company

The East India Company didn’t conquer India through armies alone. It captured it through economic dependency: trade routes, trading posts, and maritime security infrastructure that local economies could not replicate. By the time dependency was apparent, it was already structural.

AWS operates through a remarkably similar logic. EC2 connects to EBS, which connects to ELB, which connects to CloudWatch, which connects to IAM, which connects to Lambda. No single service creates the lock-in. The architecture does. Every managed service consumed is another thread in a web that becomes progressively more difficult to unwind. Egress fees, proprietary SDKs, and data gravity are not isolated commercial decisions; they are the expression of a coherent dependency model.

Microsoft Azure, as the Medieval Catholic Church

The Church governed not through territory alone, but through language. Latin was the exclusive medium of theology, diplomacy, and administration. To leave the Church was not merely a spiritual act; it meant losing access to legal records, diplomatic networks, and the educated class that ran institutions.

Microsoft’s ecosystem functions through the same mechanism. Active Directory, Exchange, Teams, SharePoint, and Office 365 are not products. They are an organisational dialect. After two decades of deployment, Microsoft’s language has become the enterprise’s language. Migration is not primarily a technical project; it is a cultural one.

Oracle, The Roman Publicans

In the Roman system, tax collection was outsourced to private contractors, “the publicans”, whose structural incentive was to maximise yield. The provincials were never entirely certain what they owed. Rules were complex, changed frequently, and the right to interpret them belonged to the collector.

Oracle’s compliance and licensing model reproduces this structure with technical precision. “We believe you may be out of compliance” is Oracle’s equivalent of the publican’s ledger. The customer is placed in a position of proving innocence under rules of considerable complexity, which change frequently, against a counterparty whose commercial interest is explicitly misaligned with theirs. This is not accidental. It is by design. Revenue is generated either through sales or through compliance.

SAP, The Teutonic Order

The Teutonic Order’s power derived not from arms but from administrative mastery. Local lords became dependent because it managed the archives, the accounting, and all administrative tasks. After five years of deployment, the distinction between “how our company works” and “how SAP makes us work” has typically disappeared. Teams cannot reliably answer which processes are genuinely proprietary and which are SAP defaults. That indistinguishability is the lock-in.

Three Layers of Dependency That Procurement Must Map

The historical analogy is not merely illustrative. It identifies three distinct layers of dependency that compound each other and which procurement must assess separately before any major renewal or sourcing event.

1. Technical Dependency

The most visible layer: proprietary data formats, API architectures that call other proprietary services, egress fees that make data portability commercially prohibitive, and certification programmes that deepen integration. This layer is measurable, and enterprise architecture teams can typically estimate migration costs and quantify data volumes.

2. Contractual Dependency

Operating at the commercial and legal level: auto-renewal clauses triggered on dates that procurement teams frequently miss, enterprise licence agreements structured to make scope reduction disproportionately penalising, compliance audit rights that convert uncertainty into negotiated settlements, and indexation mechanisms that quietly erode commercial gains achieved at signature. Most vendors have already disconnected cost from usage and volumes.

3. Human and Cognitive Dependency

The most structurally powerful layer, and the least discussed. In most large organisations, significant portions of technical and operational teams are single-vendor certified. Their professional identity, market value, and daily workflow are anchored in a specific vendor’s ecosystem. They are not adversarial to the vendor; they often become its internal advocates.

Salesforce’s certification programmes, AWS’s training infrastructure, and SAP’s vast partner network are all mechanisms for building human dependency inside the customer’s own organisation. Leadership backgrounds frequently reinforce these ecosystem preferences. When the renewal conversation begins, these individuals are structurally unlikely to champion migration.

What Can Procurement Do?

Spend Intelligence Is the Prerequisite, Not the Outcome

Before any negotiation, procurement must know, with precision, which portions of cloud spend are genuinely portable, which are technically locked in, and which depend on internal human capital that cannot be redeployed without further investment. A spend analysis that does not answer this question is insufficient.

The relevant question is not “how much do we spend?” but “how much of this spend could we credibly move in twelve months?” A standard ERP spend report is merely the raw material; procurement expertise creates the value.

Alternatives Must Be Built, Not Discussed

The single most consistent finding in cloud renegotiation engagements is that vendors respond to actions, not declared intentions. A written statement of intent to migrate carries no commercial weight unless the counterparty assesses the operational cost of that migration as executable.

In practice, this means procurement must invest in architecture assessments and, where material spend is at stake, in proof-of-concept workloads on alternative platforms—not to migrate, but to demonstrate capability. This is how leverage is created in cloud negotiations.

Recently, Tesco made public its intention to remove 40,000 servers from VMware infrastructure, demonstrating that credible alternatives influence vendor behaviour far more than declarations of intent.

Contractual Value Leakage

Across enterprise cloud portfolios, a significant proportion of contracted value is never realised: rebates not claimed because consumption thresholds were not met, discount structures triggered only at volumes that the vendor knew would not be reached, and index-linked adjustments applied asymmetrically.

AI-enabled contract intelligence systems now make it operationally feasible to map contract commitments against transactional data at scale, identifying leakage categories and quantifying recovery potential before the negotiation table is reached.

Too Late?

Cloud contract negotiations of material value require, at minimum, eighteen to twenty-four months of preparation: dependency mapping, alternative assessment, internal capability building, and leverage creation. Organisations that begin the process at the 180-day notice window prescribed in their current contract are not negotiating.

Strategic and Tactical Implications

The broader insight from the historical frame is structural. Cloud vendors have not simply grown large; they have built dependency architectures that operate largely below the threshold of procurement visibility. The mechanisms are legal, technical, human, and cognitive simultaneously. Countering them requires the same multidimensional approach.

The organisations that excel at cloud cost management share a common characteristic: they have built internal capability to continuously map vendor dependency across all three layers, maintain genuine optionality through architectural discipline and portfolio diversification, and engage renewal cycles as strategic events rather than administrative processes.

This is not primarily a technology capability. It is a procurement and governance capability: the ability to understand the structural logic of each vendor relationship, to identify where real leverage exists and where it is illusory, and to deploy that leverage at the right moment in a negotiation cycle that the vendor has, in most cases, already started.

The combination determines whether you walk into the next renewal negotiation as a customer, or as a subject.

Whether you decide—or whether the vendor decides for you.

Note: This article draws on frameworks developed by Arnaud Moisan (cloud negotiation expert and practitioner in enterprise procurement strategy) in his upcoming book “Negocier dans le cloud”—essential reading for anyone operating in high-stakes cloud negotiations.

______________________

Procurement Evolution, a Six3nine series, delivers continuous, hard-hitting insights on AI and procurement.  

👉 [Follow us on LinkedIn] to ensure you never miss an update and maintain your competitive edge.