Concentration Risk, Lock-In, and Exit: The Strategic Cost of Cloud Choice

Risk and procurement conversations get muddier than they need to be because four distinct ideas get collapsed into one word. They are worth separating.

Vendor lock-in is a situation where the technical, contractual, or economic cost of leaving a provider is high enough to constrain your ability to switch or to add a second provider [S06][S35]. Switching cost is the concrete bill for actually moving a workload: data egress, re-architecture, retraining, and lost integration [S06][S34]. A legal right to switch does not erase that bill, a distinction the EU's own analysts emphasise [S06]. Portability is the ability to move applications and data with limited rework, usually through open standards and containerization [S01][S18]. Interoperability is whether services across providers work together at all [S06].

Concentration risk is different again. It is the systemic exposure created when many organisations, or a whole sector, depend on a small number of providers. It is not the same as lock-in. Industry analysts at ECIPE note that concentration at the infrastructure layer can sit alongside more contestable upper layers, where switching between, say, SaaS tools is comparatively easy [S06]. So an organisation can face genuine concentration risk at the bottom of the stack while moving freely near the top.

An exit strategy ties these together: a defined, tested plan for leaving or replacing a service before you are forced to. As discussed below, some public-sector buyers now treat it as a procurement requirement [S05].

The shift from engineering concern to systemic concern is visible in law.

In the financial sector, the EU's Digital Operational Resilience Act (DORA), Regulation (EU) 2022/2554, applies from 17 January 2025. It establishes an EU oversight framework for ICT third-party providers precisely to address the systemic and concentration risk that arises when many regulated firms lean on the same handful of cloud and technology suppliers [W2]. The logic is straightforward: if a critical mass of banks and insurers depends on one provider, that provider's outage or failure is no longer one firm's problem. It is a sector-stability problem.

This is the heart of why concentration deserves a place on the risk register rather than the architecture review. Lock-in is about your freedom to move. Concentration is about what happens to everyone at once if the thing you all depend on stops [W2]. Both are real. They are not the same, and the controls for them differ.

If switching were cheap, lock-in would be a footnote. It is not, and it helps to be specific about why.

The recognised cost drivers are data egress charges, re-architecture, dependence on proprietary managed services, and provider-specific skills [S06][S34][S01]. National competition authorities have zeroed in on the commercial side of this. In January 2025 the UK Competition and Markets Authority provisionally found that egress fees, software licensing, and bundling restrict switching and multi-cloud use [S06]. ECIPE's analysis adds that restrictive licence terms can offset the gains of technical portability by making it economically unviable to switch, even when it is technically possible [S06].

The technical side compounds the commercial one. A documented migration case studied in a 2026 LUT University thesis found that as a system matured on one hyperscaler, it became more dependent on that provider's specific services and tooling, which reduced portability and raised the effort needed to replace or replicate functionality elsewhere, including retraining costs for provider-specific skills [S34]. The same case noted that provider development kits can bind application code tightly to platform features, making a later move genuinely hard [S34]. In the public sector, ECIPE points to long-term single-vendor contracts that created dependencies; moving away from a deeply integrated provider, it notes, can require significant re-engineering of applications and data handling [S05].

It is worth being honest about how much this varies. The same cost drivers that make a deeply integrated, stateful platform painful to move barely register for a stateless, containerized service. Switching cost is a property of a specific workload, not a fixed tax on cloud.

The instinctive answer to lock-in is "use open standards." That helps, but it is not a cure, and the evidence is careful on this point.

Research on trans-cloud applications shows that cross-provider migration via open standards such as TOSCA and CAMP is technically feasible, with automation reducing the manual effort [S01]. Strategic-migration frameworks recommend open standards, containerization, and Infrastructure-as-Code as the standard lock-in mitigations [S18]. But the LUT case is blunt about the limit: standard tooling delivers portability "at the basic level" only, and deep portability depends on equivalent services existing in the target environment [S34]. Containers move your code; they do not recreate a proprietary managed database, a bespoke AI pipeline, or a vendor's serverless runtime on the other side.

Multi-cloud is the other common answer, and it carries the same caveat. Combining providers, for instance AWS and Azure, is widely used to avoid single-vendor dependency [S35]. But multi-cloud is a trade-off, not a free win: it adds management overhead, interoperability work, and skills demands [S44]. It reduces one risk by taking on another kind of cost.

Resilience has a price tag too, and exit planning should account for it. A strategic-migration framework assessment estimates that active-active deployments, where workloads run concurrently across environments, cost roughly double to triple active-passive arrangements, with cold backup the cheapest recurring option [S18]. That figure comes from a single Tier-C framework and should be read as a directional assertion rather than a measured benchmark, but the direction is intuitive: the more switch-ready and resilient you want a workload to be, the more you pay to keep that option open. Exit readiness is not free, which is exactly why it belongs in a budget and a procurement conversation rather than in a panic after an incident.

Some buyers have already operationalised this. ECIPE notes that Portugal's public-administration cloud strategy requires a defined operational exit strategy for each cloud service [S05]. That is the practical posture: decide how you would leave before you commit, not after.

The regulatory layer is moving in the same direction as the risk one, on a clear timeline.

The EU Data Act, Regulation (EU) 2023/2854, entered into force on 11 January 2024, with most provisions applying from 12 September 2025. It adds switching and interoperability obligations on cloud and other data processing providers, including the gradual withdrawal of switching charges, so that customers can move to another provider of the same service type or to on-premises infrastructure [W1]. In short, the right to switch is becoming a legal default rather than a contractual privilege.

How much that right will be worth in practice is contested, and the most useful critique comes from the cloud-choice camp itself. ECIPE argues that applying uniform obligations across very different service layers risks formalising what it calls "notional" portability, a legal right to switch that is not matched by a practical ability to do so [S06]. The lesson for a risk leader is not to wait for regulation to deliver portability. The obligation reduces some commercial friction; it does not re-architect your workloads for you.

This is where a market analysis has to resist tidy conclusions. The magnitude of the lock-in and switching problem is genuinely disputed, and the dispute runs through the same sources.

On one side, ECIPE frames high switching costs and vendor lock-in as a major, under-recognised barrier to European cloud value [S06]. It is important to read that framing with its provenance in view: ECIPE is an industry-funded think-tank, and the paper making the strongest version of this argument was commissioned by the Open Cloud Coalition [S06]. Its large headline figures, such as up to EUR 1.2 trillion in private-sector GDP gains by around 2030, and separately up to EUR 450 billion a year in public-sector savings, are indicative, model-based estimates that measure different things; they should be cited as such and never added together into a single number [S06][S05].

On the other side, the providers most often named push back, and their objection is reasonable enough to state in full. In response to the CMA's provisional findings, AWS, Microsoft, and affiliated associations argued that the analysis overstates the risk of foreclosure and underestimates the genuine benefits of integration, scale, and pricing flexibility, warning that heavy-handed intervention could raise costs for end-users [S06]. They are not wrong that integration delivers value; deep platform features exist because customers want them. The honest position is that lock-in is a real cost and integration is a real benefit, and the balance depends on the workload. Anyone selling you certainty in either direction is selling something.

A few practical conclusions follow from the evidence, none of which require taking a side in the policy fight.

Treat concentration and lock-in as named entries on the risk register, not architecture footnotes, and keep them distinct: one is about your freedom to move, the other about shared exposure across a sector [W2][S06]. Make switching cost a property you assess per workload, since it varies enormously between a stateless service and a deeply integrated platform [S34]. Build exit readiness into procurement up front, the way Portugal's public sector does, rather than improvising it under pressure [S05]. And price the resilience you actually need: active-active keeps options open but costs more, and that trade-off should be a deliberate budget line, not a surprise [S18].

Most of this work is decision work before it is migration work. You cannot manage an exposure you have not measured, and concentration, switching cost, and exit readiness are exactly the kind of inputs that get noticed late.

This is the layer Atomity is built for. Atomity supports the evaluation of sovereignty, compliance, operational, and cost criteria and provides visibility across multiple cloud environments to support workload decisions. Portability and exit readiness sit naturally among those criteria: inputs you can weigh for a given workload before a contract is signed or a renewal lands, rather than questions you answer after an incident. Atomity does not remove lock-in, and it does not perform migrations. It helps you see the exposure clearly and decide with it in view.

This analysis leans on two industry-funded ECIPE papers for the lock-in and customer-choice argument; their positions are attributed throughout and their figures treated as indicative, not as verified fact [S06][S05]. The active-active cost ratio is a single Tier-C framework assertion, not an independent measurement [S18]. The clearest switching-cost evidence is a single documented migration case, which illustrates the mechanics but is not a generalisable euro figure [S34]. No source in this set provides a reliable, universal number for what switching costs; the responsible reading is qualitative. The regulatory facts are verified against EUR-Lex and dated, but how the Data Act's switching obligations work in practice will only become clear with enforcement [W1].

Estimate the switching cost of your most critical workload before you need to. Knowing what it would take to leave, and what staying actually locks in, is the difference between a deliberate cloud strategy and a default one.