Multi-Cloud and Avoiding Lock-In

Multi-cloud means using more than one cloud provider, and avoiding lock-in means being able to move a workload, its data, and its operations without a rebuild. Those two ideas are related but not identical. A firm can use several providers while still being locked in to each of them for the services placed there, if every workload depends on provider-specific features that cannot be moved. Conversely, a firm can be portable on a single provider, if it has kept its workloads in standard forms, its data exportable, and its operations documented in its own records. Under DORA, the question is therefore not how many providers a firm uses. It is whether dependence on any one provider can be reduced or exited without losing a service, and whether that ability has been shown rather than assumed.

Multi-cloud arrangements take several shapes, and each shape offers a different kind of protection. One shape spreads different services across different providers, so that a failure at one provider affects only the services placed there. Another shape runs the same service actively on more than one provider, so that traffic can move if one provider fails. A third shape keeps a service on one provider with a standby elsewhere, ready to be activated. The first shape limits blast radius but does not help a single service survive its own provider's failure. The second offers the strongest protection but demands the most work on data synchronisation, consistency, and operational skill across providers. The third is cheaper but depends on activation steps that must be rehearsed. Naming the shape in use, service by service, prevents a general multi-cloud claim from hiding a specific weakness.

Lock-in grows through small, reasonable choices that accumulate. A team adopts a provider workflow tool because it speeds delivery, then builds business rules into that tool. Another team adopts a provider identity service, then ties access for several services to it. A third team stores configuration in provider consoles rather than in versioned firm records. Individually, each choice is defensible. Together, they create a service that cannot move without rework across identity, workflow, configuration, and data. Avoiding lock-in therefore involves discipline at adoption: preferring standard interfaces where they exist, keeping business rules and configuration in firm-owned records, and recording provider-specific features as a deliberate dependency with a known cost of replacement. That discipline is a design habit, not a clause added at renewal.

A trading support service illustrates the trade-off. Suppose order handling runs on one provider, market data enrichment on another, and settlement messaging through a third. Spreading the work limits the effect of a single provider failure on the whole chain, yet a failure in any one link can still halt the chain, because the service needs all three links to complete an order. Genuine resilience in that picture requires more than provider diversity. It requires understanding the chain, the recovery order, and the points where data must reconcile after a partial failure. Multi-cloud can help by removing a single point of failure at provider level, but it cannot remove dependence on the chain itself. Complexity added without that understanding can make recovery harder, not easier, because more providers must be coordinated during a disruption.

Portability testing is the check that separates a multi-cloud design from a multi-cloud label. A firm can test portability by rebuilding a component elsewhere from its own records, by exporting data and loading it into a different environment, or by running a service in a second provider for a limited purpose and comparing outcomes. Such tests reveal provider-specific assumptions, missing configuration, and data format problems while they are still fixable. They also reveal skill gaps, since operating a second provider well requires staff who understand its controls, monitoring, and incident processes. A firm that cannot operate its second provider confidently has not diversified its resilience. It has diversified its vendor list.

The judgement to make is proportionate and service-specific. For a service whose loss causes serious harm, the cost of genuine portability or active multi-provider operation may be justified, because the alternative is dependence on a single provider for a service that cannot afford to stop. For a less critical service, spreading services across providers or keeping a credible exit approach may be enough, provided the limit is understood and recorded. DORA does not prescribe a single multi-cloud pattern. It expects the firm to understand its concentration, to justify its arrangement for each important service, and to show that the arrangement supports recovery. A multi-cloud strategy that cannot be explained in those terms is a procurement pattern, not a resilience strategy.