Everybody has a cloud migration plan. Almost nobody has a plan for leaving.
From 12 January 2027 EU providers will not be able to charge for the operations necessary to facilitate switching or for data egress. That changes the economics. It does not change whether your organisation could actually execute an exit.
- 12 Jan 2027Switching and egress charges removed in the EU
- 12 Sep 2025The Data Act has applied since
- Open interfacesRequired of PaaS and SaaS providers
- Transition periodMandatory in DORA critical function contracts
An exit plan that has never been rehearsed is a document, not a capability.
Exit plans are written to satisfy an auditor and filed. The first time they are read seriously is usually the worst possible moment.
- The plan says data will be exported and restored elsewhere. Nobody has ever exported the full data set, so nobody knows how long it takes, whether the export completes, what it costs, or whether the resulting format can be loaded into anything.
- The plan assumes the application runs elsewhere. Nobody has enumerated the managed services it depends on, so the identity integration, the message queue, the managed database features and the platform specific networking are all discovered during the migration.
- The plan assumes people are available. In a real exit, typically triggered by a commercial dispute, an acquisition or a provider failure, the same small group of people are handling the trigger event and the migration simultaneously.
- The fix is not a longer document. It is a partial rehearsal: export a representative data set, restore it somewhere else, and record what actually happened. That one exercise usually changes the plan more than a year of reviewing it would.
Eight things that decide whether you could actually leave.
The regulatory economics are changing
Under the EU Data Act, from 12 January 2027 providers will not be able to charge customers for the operations necessary to facilitate switching or for data egress. For organisations with EU operations that removes one of the more effective lock-in mechanisms.
Open interfaces and portable formats are required
Providers of platform and software as a service must make open interfaces available and export data in commonly used machine-readable formats. Portability moves from something you negotiate for to something the regulation expects to exist.
Financial services already require exit strategies
DORA requires financial entities to put exit strategies in place for ICT services supporting critical or important functions, allowing them to exit contractual arrangements without disruption to their business activities. That obligation flows to their suppliers.
A transition period is a contractual commitment
For critical or important functions, contracts must include a mandatory adequate transition period during which the provider continues the service while the customer migrates to another provider or moves to in-house solutions. That has an operational cost attached.
Data return is not the same as data usability
Contracts require access, recovery and return in an easily accessible format of personal and non-personal data, including on provider insolvency. An export you cannot load into anything else satisfies the letter and fails the purpose entirely.
Concentration risk has to be assessed deliberately
DORA requires identifying and assessing all relevant risks in a contractual arrangement, including the possibility that it may contribute to reinforcing ICT concentration risk. Most estates have more concentration than an inventory would suggest at first glance.
The dependencies are rarely where you expect
Identity, secrets management, logging, networking and managed services accumulate quietly. An application that looks portable often turns out to depend on half a dozen platform services that have no direct equivalent elsewhere.
Provider obligations extend to protecting the data
Providers of data processing services are expected to take all reasonable measures, including encryption, audits and adherence to certification schemes, to prevent access to the systems in which they store non-personal data. That belongs in the exit conversation too.
Two EU instruments, two different reasons to plan an exit.
| Requirement | EU Data Act | DORA | |
|---|---|---|---|
| Applies since | 12 September 2025 | 17 January 2025 | |
| Who it targets | Data processing service providers | Financial entities and their ICT providers | |
| Switching charges | Removed from 12 January 2027 | Not addressed directly | |
| Open interfaces | Required of PaaS and SaaS | Not addressed directly | |
| Machine-readable export | Commonly used formats | Easily accessible format | |
| Exit strategy obligation | Switching rights | Required for critical or important functions | |
| Transition period | Not addressed directly | Mandatory and adequate, in contract | |
| Concentration risk | Market level concern | Assessed per contractual arrangement | |
| Insolvency scenario | Not addressed directly | Data return guaranteed contractually | |
| How a UAE company is reached | EU operations or customers | Supplying an EU financial entity |
Four things that turn an exit plan into an exit capability.
We measure the data export rather than estimating it
Volume, duration, cost and above all whether the exported format can be loaded into an alternative platform. Export in a commonly used machine-readable format is the standard the regulation expects, and it is worth testing against rather than assuming.
We map the dependencies people forget
Identity, secrets, logging, networking, message queues and managed database features. Applications that appear portable frequently depend on a handful of platform services with no direct equivalent, and that discovery belongs in a rehearsal rather than a migration.
We check the contract supports the plan
Data return in an easily accessible format including on insolvency, a transition period long enough to actually migrate, and notice terms that do not create a gap. Financial services contracts require several of these already.
We rehearse a representative slice
Not the whole estate, which would be disproportionate, but enough of it to test the assumptions that matter. A partial rehearsal that finds three broken assumptions is worth more than a complete plan that has never been read.
Four phases across roughly eight to fourteen weeks.
- 01Weeks 1 to 3
Map the real dependencies
Every managed service, platform feature and integration each workload depends on, not just the compute and the database. This is where the difference between a portable application and one that merely runs in a container becomes visible.
- Workload inventory with platform dependencies
- Identity and secrets dependencies mapped
- Data stores catalogued with volumes and formats
- Concentration risk assessed across providers
- 02Weeks 4 to 6
Establish the data position
What can be exported, in what format, how long it takes, what it costs today, and whether the result is usable elsewhere. Export in a commonly used machine-readable format is the standard to test against rather than whatever the console offers by default.
- Export capability confirmed per data store
- Format usability tested rather than assumed
- Volume and duration measured on real data
- Current egress cost quantified
- 03Weeks 7 to 10
Rehearse a representative exit
A partial but genuine test: export a representative data set, stand it up on an alternative platform, and record what broke. The purpose is to find the assumptions that do not hold, and there are always several.
- Representative workload migrated in a test
- Time, cost and effort recorded honestly
- Failed assumptions documented
- Plan corrected against what actually happened
- 04Weeks 11 to 14
Contract and governance
Contract terms reviewed against what the plan needs, including data return, transition periods and notice. Then a review cadence, because an exit plan drifts out of date at the same speed the estate changes.
- Contract gaps identified against exit requirements
- Transition period and data return terms negotiated
- Exit plan documented with real figures
- Review cadence and owner assigned
Six situations that make exit planning urgent.
A financial entity, or a supplier to one
DORA requires exit strategies for ICT services supporting critical or important functions, and contracts to include a mandatory adequate transition period. Suppliers see that obligation arrive as a contract amendment rather than as a regulatory notice.
A business heading into a renewal negotiation
The strength of your position depends on whether leaving is genuinely possible. A provider that knows you cannot move has no reason to move on price, and a tested exit capability changes that conversation materially.
An organisation with EU operations
The Data Act has applied since 12 September 2025, requires platform and software as a service providers to offer open interfaces and machine-readable export, and removes switching and egress charges from 12 January 2027.
A company that has concentrated on one provider
Assessing whether an arrangement contributes to reinforcing concentration risk is an explicit requirement in financial services and a sensible discipline everywhere. Most estates are more concentrated than a first inventory suggests.
A group being acquired or divested
Separation work exposes every assumption about portability at once, usually on a transaction timetable. Organisations that mapped dependencies in advance move considerably faster and argue with the counterparty considerably less.
A team whose provider changed terms or direction
Price changes, product retirements, licensing shifts and ownership changes all raise the same question at short notice. The answer depends entirely on work done before the announcement rather than after it.
How UAE organisations stand on cloud exit.
| Feature | Tested exit capability | Documented exit plan | No plan |
|---|---|---|---|
Data export proven | Measured | Assumed | Unknown |
Export format usable elsewhere | Verified | Assumed | Unknown |
Platform dependencies mapped | Fully | Partially | No |
Migration rehearsed | Yes, partially | No | No |
Real time and cost figures | Recorded | Estimated | None |
Contract supports the plan | Checked | Assumed | Unread |
Concentration risk understood | Assessed | Mentioned | Not considered |
Negotiating position at renewal | Strong | Weak | None |
Behaviour if the provider fails | Planned | Improvised | Crisis |
Effort to reach | Weeks | Days | None |
Four platform services that quietly make an application non portable.
Compute and storage are the easy part. These four are where a migration that looked like a fortnight becomes a quarter.
- Identity. Where the application relies on the platform identity service for authentication, authorisation, service to service tokens and managed identities, moving it means rebuilding that layer rather than reconfiguring it, and it touches every component at once.
- Secrets and key management. Keys held in a platform key service, particularly where they protect data at rest, create a migration dependency with a cryptographic dimension. Re-encrypting a large data set under new keys is a project in its own right.
- Managed database features. Serverless scaling, proprietary query extensions, change streams, built in replication and platform specific backup behaviour are all easy to adopt and each one narrows the set of destinations the workload can move to.
- Networking and eventing. Platform specific load balancing behaviour, private connectivity, message queues and event routing rarely have exact equivalents elsewhere, and they are usually discovered during migration because nobody lists them as dependencies.
Five steps, and the third is the one that matters.
- 1
Map workloads and their real dependencies
Beyond compute and storage into identity, secrets, logging, networking, managed database features and integrations. Concentration risk is assessed here too, since the exit question and the concentration question share the same underlying inventory.
- 2
Establish the data position with measurements
What exports exist, in what format, how long a full export takes, what it costs today, and whether the output can be loaded elsewhere. Commonly used machine-readable formats are the benchmark rather than whatever the platform emits by default.
- 3
Rehearse a representative migration
Export a meaningful data set and stand it up on an alternative platform. Record what took longer than expected, what did not work and what was missing. The corrected plan that comes out of this is the actual deliverable.
- 4
Align contracts with the plan
Data return in an easily accessible format including on insolvency, an adequate transition period, notice terms and any commitments a customer has required of you. Financial services contracts already mandate several of these provisions.
- 5
Assign an owner and a review cadence
Exit plans decay at the speed the estate changes, which is fast. A named owner, a review each time a significant platform dependency is added, and a partial re-test on a sensible interval keep the capability real rather than historical.
What organisations ask about cloud exit.
Fifteen questions that reveal whether you could leave.
Data
- Have we ever exported the full data set?Not a sample.
- How long did it take?Measured, not estimated.
- What did the egress cost?Changing in the EU from 2027.
- Can the export be loaded elsewhere?Format usability matters.
- What about data in managed services?Often the hardest part.
Dependencies
- Which platform services do we rely on?Beyond compute and storage.
- Where does identity come from?A common hidden dependency.
- Where do secrets live?Another one.
- What about logging and monitoring?Rarely in the plan.
- Do we know our concentration risk?Assess it deliberately.
Contract and people
- Is there a transition period in the contract?Mandatory under DORA for critical functions.
- What happens on provider insolvency?Data return should be guaranteed.
- What notice must we give?Check before you need it.
- Who would run the exit?Probably already busy.
- When was the plan last tested?Not last reviewed, tested.
Ask whether anybody has ever exported your largest data set in full.
And how long it took, what it cost, and whether the result could be loaded anywhere else. If nobody knows, your exit plan describes an intention rather than a capability.
Related Services
Explore more solutions that work great with this service
DORA compliance
What EU financial customers now require from UAE ICT suppliers.
Third Party Risk Audit
Who can actually reach your systems, and what to do about it
Disaster Recovery Audit
Measured recovery time, not the stated objective
Backup and Restore Audit
We test whether your backups actually restore
Cloud Security Posture Audit
The real inventory, then configuration and identity
IT Risk Assessment
A short register with an owner against every risk
Business Continuity Planning
BCP, RPO/RTO design, and DR runbook authoring
Compliance as a Service
Keeping the position true between assessments