Cloud Exit and Portability

Cloud exit and portability concern whether a firm can leave a provider, move a service elsewhere, or bring it back in house, without losing the service, its data, or its history. Portability is the technical and contractual ability to move workloads and data in a usable form. Exit is the wider operation: ending the arrangement, retrieving data, transferring knowledge, and restoring the service in its new home. Under DORA, the ICT third party risk provisions expect financial entities to plan for exit where dependence is significant, because a provider that cannot be left is a concentration risk as well as a commercial lock-in. An exit clause that promises cooperation in general terms, without saying what will be returned, in what form, and with what support, is not an exit plan.

Exit becomes difficult for reasons that are often invisible during normal operation. A service may use provider-specific data formats, identity arrangements, workflow definitions, or integration patterns that have no direct equivalent elsewhere. Configuration may live in provider consoles rather than in firm-owned records. Operational knowledge may sit with provider staff rather than with the firm. None of these points prevents exit on its own, but together they turn a move into a rebuild. The longer a service runs on provider-specific features without recording equivalents, the larger that rebuild becomes. Exit planning therefore begins during adoption, when choices about formats, interfaces, and documentation are still cheap to influence, rather than at termination, when they are expensive to undo.

A mortgage servicing illustration shows how exit touches more than computing. Servicing involves borrower records, payment histories, correspondence, and decision rules, held across a provider application and connected stores. Moving the application alone would leave the firm with a system that cannot explain past decisions or reconcile payments. Moving data alone, without the rules and history that give it meaning, would leave a similar gap. A workable exit approach therefore covers data, configuration, rules, interfaces, and the knowledge needed to operate the service, together with the order in which each element moves and is checked. Each element also needs an owner on the firm side, since a provider cannot be expected to judge whether the firm's service is whole after the move.

Data return deserves separate attention because it is where exit disputes most often arise. The firm needs to know what data it owns, what the provider holds on its behalf, what derived data the provider has created, and what will happen to each category at exit. Formats matter as much as ownership: data returned in a proprietary form that the firm cannot load elsewhere is returned in name only. So does timing: a return that arrives after the service has already been switched off leaves a gap in which the service cannot run. Contract terms on return, deletion, and retention need to be specific enough to be operated, and they need to be consistent with data protection and record keeping duties that apply independently of the provider relationship.

Testing exit is unpopular because it looks like work with no immediate benefit, yet an untested exit approach is an assumption, not a capability. Testing need not mean moving a live service. It can mean exporting data and loading it elsewhere, rebuilding a component from firm-owned records, or running a service in a new environment for a limited purpose and comparing results. Each exercise reveals a gap while it is still fixable: a missing field, an undocumented rule, a credential held only by the provider, or a step that depends on a person who has left. The value of the exercise lies in those findings, and in the corrections that follow, rather than in a report stating that exit was considered.

An exit approach also needs triggers and governance, not only technical steps. A firm should be able to say what circumstances would prompt a move, who decides, and what interim arrangements keep the service running while the move takes place. Provider failure, a change in provider strategy, a regulatory concern, or a loss of confidence in the arrangement can each prompt exit, and each calls for a different pace and sequence. Treating exit as a single emergency procedure flattens those differences. Treating it as a set of rehearsed options, matched to different triggers, gives the firm a realistic way to leave without creating a second disruption in the attempt to escape the first.