Key takeaways<\/p>\n
- \n
- Lock-in is an operational risk.<\/strong> The costly tie sits in data flows, process logic and operations teams, and stays invisible while the service runs.<\/li>\n
- Exit costs belong before the purchase.<\/strong> Anyone who does not price the switch, parallel running and the rebuild underestimates the platform’s economic horizon.<\/li>\n
- The Data Act caps fees.<\/strong> It replaces neither architecture nor tested portability.<\/li>\n
- Speed may buy lock-in.<\/strong> Lock-in is acceptable if the lead stays measurable and a funded exit path is kept.<\/li>\n<\/ul>\n<\/div>\n
Related<\/span>EU Data Act: Switching obligations for cloud portfolios<\/a> \/<\/span> Managed services: The bill nobody opens<\/a><\/p>\n
What is an exit path?<\/strong> The contractually and technically prepared switch of a platform: data portability, parallel running, funded rebuild costs, and an architecture that keeps the same switch testable on a second provider before the purchase seals the lock-in.<\/p>\n
Inventory comes before termination<\/h2>\n
IT and business leads often treat vendor lock-in as a clause topic for legal. In daily work it is the operating model. Data paths, permissions, monitoring and the way business units close processes settle around the platform. While availability holds and the price stays within budget, there is no reason to review the arrangement. The reason comes when terms rise, when oversight demands another route, or when the product roadmap no longer carries your strategy.<\/p>\n
The costly phase rarely starts with formal notice. It starts with the inventory. You have to establish which data sets can be extracted in full and reused, which interfaces exist only in the provider’s control plane, and which automations, roles and AI artefacts nobody has documented outside the product. The longer operations rest on managed specialist services, the more a switch resembles a rebuild, including dual running and stability risk.<\/p>\n
Exit costs<\/strong> show up as overlapping terms, deferred projects, training, integrations that must be rebuilt, and uncertainty in reporting. Anyone who prices them only in an escalation negotiates with no alternative. The provider then knows the cost of standstill better than your own controlling function.<\/p>\n
Lock-in is therefore the result of decisions that ranked speed, feature density and operational calm above the ability to leave. That trade-off can be right. It has to stay deliberate and, before the next term, sit in euros, in the schedule and in the risk report.<\/p>\n
Cloud, ERP and AI lock in at three different points<\/h2>\n
In the cloud, lock-in gets expensive through the control plane. Identities, networks, key management, logs and managed specialised services form a mesh. Compute can be replaced relatively fast. The path on which applications authenticate, store data, distribute events and watch operations often sticks to the ecosystem. Exporting objects changes little if the application depends on the quirks of those services. Network and transfer costs can dull the economic case for a partial switch, and no generally valid euro figure exists for that.<\/p>\n
In ERP, lock-in sits in the operational truth of the firm. Master data, document flows, permissions and custom code built up over years make the system the authoritative order of business processes. A switch means restating that order and keeping the old one readable in parallel. The licence is usually the smaller item. The larger one is the span in which parallel worlds must assert the same economic reality, including alignment with audit, control and operations teams.<\/p>\n
AI platforms shift the tie into model access, embeddings, tool chains, evaluation data and operating knowledge of prompts, filters and quality limits. Anyone who keeps production and test data only in a provider’s closed stack buys fast analysis and gives up portability. The follow-on cost is rebuilding quality assurance, access control, business integration and traceability. That holds whatever the provider, because the artefacts stick to the operating path.<\/p>\n
These costs arise as parallel running, export, rebuild and delayed projects. Independent benchmark figures for a single case do not exist without your own inventory. Anyone who compares only list prices for the replacement leaves out the costlier part: people, dual running and the time in which management looks at parallel truths.<\/p>\n
The Data Act cuts fees and leaves the rebuild<\/h2>\n
Contracts describe scope, term and liability. They rarely describe an orderly exit in a form you can rely on. A notice period without a fixed data format, a test environment and help with extraction remains a mere deadline.<\/p>\n
Data portability<\/strong> needs formats, completeness, repeatability and export help concrete enough that an independent team can test the claim. Parallel running needs rights, prices and capacity already written into the term. Indexation, minimum commitments and the loss of discounts on a partial exit can make a switch economically impossible, even when it is technically sketched.<\/p>\n
The EU Data Act obliges providers of data processing services to enable a switch to another service or to the customer’s own infrastructure. Chapter VI has applied since 12 September 2025 to existing and new contracts. The notice period for a switch may be at most two months. The transition should then, as a rule, take 30 calendar days. Until 12 January 2027, switching fees may cover only the direct costs of the switch. From that date they are abolished. The GDPR (General Data Protection Regulation) also grants a right to portability of personal data.<\/p>\n
This framework does not replace architecture. Negotiation over operating support, interfaces, test windows and the end of special terms stays a matter for the contract. Relying solely on statutory rights underestimates the gap between a legal position and a production-ready replacement. That gap shapes daily work.<\/p>\n
Contractual strength shows in what you can prove. Anyone who may not periodically receive a full export, test it and run it against their own environment holds a right that exists only on paper. The same goes for configuration documentation, key handover and the provider’s help when historical data must be read in several passes. These duties cost concessions in negotiation. Those concessions are what count later.<\/p>\n
When lock-in works as a loan<\/h2>\n
Lock-in to a platform can be the right call. Some dependency is the price of a market window that must not close, or of a business unit that delivers in months while a decoupled build would take years. Leadership needs a measure for that. Gut feel is not enough, because the benefit shows at once and the lock-in later.<\/p>\n
Lock-in is acceptable when the commercial lead becomes measurable on a clear horizon, when the exit remains a funded scenario, and when the dependency sits in an area the organisation can later rebuild without losing the core of value creation. Replaceable functions may sit closer to the provider than the system that carries prices, inventory, risk or customer rights. The split must be written into the decision paper. Otherwise the next feature promise quietly erases the line.<\/p>\n
Lock-in turns dangerous where the core system exists only in one provider’s idiom and every further custom change widens the gap to a portable state. Then speed funds the next inability to act. That weighs hardest with AI functions that sink into ERP, the customer platform or the operating path while evaluation data and business rules do not sit outside the tool chain. The exit then hits decision quality across the whole firm.<\/p>\n
The question for the committee is the price of dependency in euros and in options forgone. If that price stands against a demonstrable lead and the exit path stays budgeted, lock-in may be chosen deliberately. If both are missing, the cheap entry is an expensive loan.<\/p>\n
What belongs in the same paper before you sign<\/h2>\n
Before a committee signs off term, discount and go-live, the exit belongs in the same paper. State what would still run the day after notice. Name the data objects, identities and model artefacts that exist only at the provider. Record a euro order of magnitude for parallel running, export, rebuild and risk, as a range, and with the limit that it is not reliable without an inventory of your own estate. Make clear who owns the exit as a task, including a budget and a date on which portability is rehearsed.<\/p>\n
In the first 90 days after the decision, a repeatable export belongs on the calendar, plus rebuilding the integration paths against another consumer and a drill on separating identity and keys. That work spends operations capacity. It stays smaller than an escalation in which availability, compliance and negotiation come under pressure at once.<\/p>\n
In management control, lock-in should be run like a concentration risk: in the risk report, against thresholds and with a named owner. The guiding question is whether the firm can still price its own next years. Anyone who leaves that question to technology alone has delegated it to the provider.<\/p>\n
Anyone who buys in the European legal space operates under a regime meant to ease switching that still does not make a switch ready to run. Global platform logic, group rules and local supervision pull on the same estate. The leadership task is to keep that tension visible in the contract, the architecture and the budget before discount and delivery date close the decision.<\/p>\n
Frequently asked questions<\/h2>\n
\nWhen is lock-in an acceptable price for speed?<\/summary>\n
Lock-in is acceptable when the commercial lead becomes measurable on a clear horizon, the exit remains a funded scenario, and the dependency can later be rebuilt without losing the core of value creation. Replaceable functions may sit closer to the provider than systems for prices, inventory, risk or customer rights. The line belongs in the decision paper.<\/p>\n<\/details>\n
\nWhat must the contract include so an exit stays affordable?<\/summary>\n
Portability needs formats, completeness, repeatability and export support concrete enough for an independent team to test them. Parallel running, prices during the transition, and the logic of indexation, minimum commitment and lost discounts on a partial exit belong in the term. The EU Data Act and the GDPR set a frame and replace neither architecture nor operating support.<\/p>\n<\/details>\n
\nWhat do exit costs consist of?<\/summary>\n
The costs arise mainly as parallel running, export, the rebuild of integrations and quality assurance, and as delayed projects. Reliable figures for a single case do not exist without an inventory of your own data, interfaces and AI artefacts.<\/p>\n<\/details>\n
- Exit costs belong before the purchase.<\/strong> Anyone who does not price the switch, parallel running and the rebuild underestimates the platform’s economic horizon.<\/li>\n
![\"AWS,](\"https:\/\/www.cloudmagazin.com\/wp-content\/uploads\/2026\/08\/cloud-egress-free-tiers-exit-waiver-stille-kosten-cover-hero-250x141.jpg\")
<\/p>\n![\"Out](\"https:\/\/mybusinessfuture.com\/wp-content\/uploads\/2026\/03\/pexels-325185-cloud-server-660x440.jpg\")
<\/p>\n![\"The](\"https:\/\/www.securitytoday.de\/wp-content\/uploads\/2026\/07\/konzentrationsrisiko-vierte-partei-lieferkette-cover-hero-250x143.jpg\")
<\/p>\n