Jornada Produtora on Unsplash

7 June 2026 · George St. Clair

Exiting a Hyperscaler Is an Engineering Programme

  • cloud-strategy
  • digital-transformation
  • public-sector
  • cloud-architecture

Parliament has called for a Palantir exit, but the delivery falls on engineering teams facing platform coupling, data gravity, and years of contract lock-in.

Parliament’s Science, Innovation and Technology Committee has recommended what many in the industry have argued for years: exit Palantir, cut US hyperscaler dependency, and restructure public sector IT procurement. The strategic direction is correct.

The organisations that need to act on it are not in Westminster. They are in IT departments, transformation programmes, and architecture functions across central government, the NHS, and local authorities. The hard part was never the policy decision.

The Gap Between Political Signal and Engineering Reality

The pattern across public sector and enterprise migrations is consistent: the decision to exit a strategic technology relationship is made in a boardroom in a day. The engineering programme that follows takes three to five years, and consistently costs more than the initial business case projected.

Here is what that programme actually involves.


1. Platform Coupling Inventory

Before you can exit a platform, you need to know what is coupled to it. This sounds obvious. In practice, organisations reliably find 40–60% more coupling than their architecture diagrams show: managed message queues, proprietary ML pipelines, Lambda functions encoding business logic nobody documented, serverless abstractions that have leaked the provider’s runtime model deep into application code. The inventory phase alone runs for months.

2. Data Gravity

Data does not move cheaply or quickly. Petabytes of operational and historic data sitting in a hyperscaler’s managed database carry egress fees, downtime risk during migration windows, and schema transformation work. For public sector organisations with citizen data retention obligations, the data gravity problem alone doubles the programme timeline.

3. Proprietary API Dependency

Teams that built on AWS Lambda, Azure Functions, or Google Pub/Sub prioritised speed over portability. Those APIs have no clean abstraction layer that translates to an alternative provider. Rewrites are expensive. Abstraction retrofits are fragile. You pay the cost of the original shortcut, compounded by years of subsequent changes layered on top.

4. Contract Lock-In and Committed Spend

Enterprise cloud contracts are structured around committed spend in exchange for discount tiers. Exit mid-contract and you pay financial penalties. Multi-year agreements with Palantir and the major hyperscalers were signed by procurement teams optimising for unit cost, not exit flexibility. Legal, finance, and procurement need to be in the room before the engineering team plans a single migration sprint.

5. Operational Continuity

The workloads being migrated are live: payroll, clinical records, benefits processing. None of these tolerate a big-bang cutover. The migration programme must run in parallel with the existing platform, which means double the infrastructure cost during transition. This is consistently underestimated by a factor of two in initial business cases.

6. Target Architecture Decision

The SIT Committee recommends reducing US hyperscaler dependency but leaves the target architecture undefined. UK sovereign cloud, on-premises, hybrid, or multi-cloud with European providers each carry different compliance profiles, performance ceilings, and operational overhead. This decision must precede the migration programme, not trail it. Start migrating before you have locked the target architecture and you will migrate twice.


What Success Actually Looks Like

The organisations that exit hyperscalers successfully are not the fastest ones. They are the most thorough, completing the coupling inventory before committing to a timeline, modelling the data gravity problem before signing the exit contract, and securing operational continuity funding before the first migration sprint begins.

The political signal from Westminster is clear. UK public sector technology cannot remain this concentrated in a narrow set of non-UK suppliers. The geopolitical exposure and procurement dependency are real risks that government is right to address.

CIOs and digital transformation leads should treat this recommendation as the start of a conversation. The engineering work that follows is measured in years, not parliamentary terms.


George St. Clair is Director of SCITAS Ltd, a UK enterprise technology consultancy specialising in cloud architecture, AI integration, and digital transformation for large organisations in financial services, public sector, and central government.

Leon Seibert on Unsplash

cloud-strategy

“Organisations reliably find 40 to 60% more platform coupling than their architecture diagrams show, and the inventory phase alone runs for months.”

About the Author

George St. Clair

Director, SCITAS Ltd — enterprise technology architecture for financial services, public sector, and central government.

Join the discussion on LinkedIn →

Ready to Move?

Bring us your toughest challenge.

Every engagement starts with a direct conversation about what’s blocking you.