The Exit Map: From Provider Dependence to a Testable Migration

The exit map is where the Data Act's definitions, portable-surface rules, and contract clock become one practical judgment. It asks whether a proposed move can be described as a sequence with named actors, portable material, deadlines, and pass-or-fail evidence. If any of those pieces is missing, the customer may have a right-shaped document but not yet an operational exit.

Draw the exit map around the workload

Start with the service the customer actually uses, not with the provider's brand. The map should name the customer, the source provider, the destination provider or on-premises environment, and the service being moved. It should also state whether the customer is ending the source relationship, moving to on-premises infrastructure, unbundling one service, or operating two providers in parallel. These are different operating states even when the same data crosses the same network.

The destination matters because “leave” is not a destination by itself. A customer may move to another service of the same type, choose an on-premises environment, or decide to use a second provider without yet terminating the first. Each choice changes the question that the customer must answer. A switch asks whether the workload can be extracted, transformed, uploaded, and validated in the new environment. On-premises migration asks the same question against infrastructure the customer or a third party operates. Parallel use asks whether two services can exchange data continuously and maintain their respective functions.

flowchart LR A["Customer names service and destination"] --> B["Customer authorises switch"] B --> C["Source provider: procedures, formats, risks, assistance"] C --> D["Portable data and right-of-use digital assets"] D --> E["Protected or excluded material recorded"] E --> F["Customer and destination transform and upload"] B --> G["Destination provider or on-premises infrastructure"] G --> F F --> H["Destination validates function and continuity"] C --> I["Source maintains service and security"] I --> H H --> J["Successful switch, retrieval, and erasure"]

The first node is a scope decision. A data-processing service is defined by the way it provides on-demand access to a shared, configurable, scalable, elastic pool of computing resources, not by a logo or a sales category. The map should record enough of that operating model to explain why the selected destination is comparable—or why the customer is intentionally choosing a different operating model. “Both are cloud services” is not enough to predict what will survive the move.

The second node is the portable surface. Exportable data include the customer's inputs and outputs and metadata directly or indirectly generated or co-generated by the customer's use. Digital assets are separate: they include elements such as applications where the customer has an independent right of use. Configuration, access and control information, or virtualization artifacts may be essential to the destination, but their portability depends on the customer's rights. The map should not use “data” as a substitute for all of these categories.

A disciplined map records three dispositions for each important item: it moves, it is excluded for a stated reason, or the team has not yet established its status. The third disposition is not a legal conclusion; it is a readiness failure that needs resolution. If an application licence cannot be used at the destination, the customer may need a replacement or a new agreement. If metadata is generated by the customer's use but the team has not identified its structure, the export procedure is incomplete.