Concentration risk in cloud is widely acknowledged in principle, yet it rarely reaches a board agenda until an event forces it there. An enterprise selects a provider, builds at pace, and applications become progressively coupled to provider-native services — each adopted for sound reasons at the time — and the question of how the enterprise would exit is deferred to a future workstream that is seldom scheduled. Deferral does not reduce that cost; it transfers it to a point at which the enterprise has fewer options and less time. At L&T Vyoma, we treat public and hybrid cloud management as a discipline that includes the exit from day one, because our considered view is straightforward: portability is not something a cloud provider hands you. It is something you design before you need it or find unavailable at the moment it matters most.
Why Exit Design Is Routinely Deferred
In most estates we review, an exit path exists in principle but not in a documented, costed and tested form. This is rarely an oversight — the question simply had no forcing function at the point of design. Two structural dynamics compound quietly over the life of an estate. The first is proprietary dependency: the more an estate relies on a cloud’s own databases, queues and managed services, the greater the share of the application that cannot be relocated without redesign. The second is data gravity, which is an inherent property of the commercial model rather than an accident of it. Egress fees — the charge to move your own data out — can run to 6 to 12% of a total migration budget (industry analyses), and the practical effect is an economic bias toward continuity, irrespective of intent. When 37signals moved its workloads off AWS, it negotiated a USD 250,000 egress waiver, which illustrates a useful principle: exit economics are negotiable, but generally only for customers who have prepared a credible alternative.
Our view. An exit design is a normal artefact of good architecture, not a statement of distrust in a provider. Risk of deferral: re-platforming effort scales with the proportion of provider-native services in the estate and is incurred precisely when time is shortest. Mitigation: treat portable foundations as the default platform layer, and adopt provider-native services against a documented, time-bound exception.
Three Forces That Typically Trigger a Move
The timing of an exit decision is usually set by external factors rather than internal planning cycles. Three forces tend to set it. The first is cost: for steady-state, predictable workloads, consumption pricing has increasingly diverged from the underlying hardware cost curve, and the repatriation shift is real — IDC reports that around 80% of enterprises expect to move compute or storage workloads back from public cloud within twelve months, with cost, performance and data sovereignty the leading reasons (IDC). The second is performance: certain workloads demonstrate materially better price-performance on a different platform, and the value lies in being able to act on that evidence when it emerges. The third, unique to India, is law: under the DPDP Act’s negative-list model, a destination that is lawful for your data today can be restricted by government notification tomorrow. If that happens and the architecture is tightly bound to a single foreign region, the enterprise is then executing an unplanned migration against a statutory deadline — the least favourable conditions for both cost and quality. None of these three can be scheduled, which is precisely why the response to them should be.
Our view. Exit readiness should be measured, not assumed. Risk of deferral: where egress is unmodelled, a cost of 6–12% of migration budget surfaces as an unbudgeted capital request mid-event. Mitigation: maintain a standing exit-cost estimate, refreshed at each renewal and reviewed alongside the run-rate, so the number is known before it is needed.
Portability Is Architecture, not a Vendor Promise
This is the point on which we hold a firm view: no commercial model naturally optimises for its own substitution — which is unremarkable, and simply means portability has to be owned by the customer. Egress economics are the clearest illustration of this. Portability, therefore, is not a commitment to be secured from a vendor; it has to be a property you build into the architecture. In practice that means a few disciplined choices. Run on portable foundations — Kubernetes, infrastructure-as-code, open data formats — so the platform layer travels with you. Reserve the proprietary, hard-to-port services for where they genuinely earn their place, rather than adopting them as the default option. Used deliberately, provider-native services are a genuine accelerator; used by default, they become the single largest determinant of exit cost. Cost the exit up front, so egress is a budgeted line item rather than an unbudgeted cost discovered at the point of exit. And keep a credible landing zone ready, because a demonstrable alternative is what turns a renewal conversation into a commercial negotiation — and, in our experience, strengthens rather than strains the relationship with the provider you ultimately choose to stay with.
Our view. Portability is a governance outcome as much as an engineering one. Risk of deferral: portability erodes silently between architecture reviews, one reasonable exception at a time. Mitigation: place a portability gate in the architecture review board, and rehearse a representative workload move annually, in the same way a disaster-recovery test is scheduled and evidenced.
The India Case: Portability Is Sovereignty Insurance
For an Indian enterprise, portability is more than a cost lever; it is a proportionate control against regulatory change. If your workloads are built to move and you already keep a sovereign landing zone on Indian soil, then a DPDP restriction, a cost spike or a performance problem becomes a scheduled migration executed under normal change governance, rather than an unplanned event executed under escalation. This is the position we are structured to support, and we would rather be judged on the exit we design than the migration we win. Our public cloud runs on standards-based, portable foundations rather than a provider-specific, closed ecosystem; our managed services team helps design workloads for portability and executes the moves when they are required; and our L&T-operated data centers give you an Indian-soil destination to repatriate the regulated core into. You design the exit with us before you need it, so that when one of those three forces arrives, moving is a decision you make calmly, rather than one dictated by circumstance.
Our view. A warm Indian-soil landing zone for the regulated data core is, in our assessment, proportionate insurance rather than duplicated cost. Risk of deferral: a notification under the DPDP negative-list model converts a design task into a compliance deadline, with the associated audit and reputational exposure. Mitigation: keep the regulated core on portable foundations with a tested destination in country and record the decision and its evidence in the compliance register.
Provider-Anchored vs Portable by Design
|
Dimension |
Provider-Anchored (common default) |
Portable by Design |
|
Tooling |
Extensive reliance on provider-native services |
Kubernetes, IaC, open formats |
|
Your data |
Anchored by egress economics |
Movable; exit costed up front |
|
Exit timing |
Event-driven, under time pressure |
Your choice, planned in advance |
|
Negotiating leverage |
Limited — no demonstrable alternative |
Meaningful — a credible alternative exists |
|
DPDP exposure |
Unplanned migration against a statutory deadline |
A planned move to a tested Indian landing zone |
Where Deferral Carries Risk, and How to Mitigate It
|
Dimension |
Risk if deferred |
Recommended mitigation |
|
Tooling |
Redesign effort at exit scales with native-service adoption |
Portable platform layer by default; native services by documented exception |
|
Your data |
Egress surfaces as an unbudgeted cost mid-event |
Standing exit-cost estimate, refreshed at each renewal |
|
Exit timing |
Migration executed under escalation, with quality trade-offs |
Annual exit rehearsal on a representative workload |
|
Commercial position |
Renewal discussions proceed without a comparable option |
Maintain a costed, tested alternative ahead of each renewal |
|
DPDP exposure |
A notification converts design work into a statutory deadline |
Warm Indian-soil landing zone for the regulated core, tested annually |
Design the Exit While the Options Are Open
The least costly time to design an exit is well before one is required, when it remains an architectural decision rather than a recovery exercise. The most expensive time is when regulation, cost pressure or workload performance brings the question forward and the available options are narrower, slower and materially more costly. Portability is not a feature you buy; it is a design principle adopted early and sustained through governance — portable tooling, a costed exit, and a sovereign landing zone ready on Indian soil. Talk to our team about designing portability into your estate, or explore our public cloud and managed services.
Sources: IDC (enterprise repatriation intent and drivers), as reported in 2026 cloud-repatriation analyses; egress-fee share of migration cost and the 37signals AWS egress waiver, from 2026 industry analyses; DPDP Act, 2023 (cross-border negative-list model).