Leaving a software supplier without losing the system

Two EU laws set exit rules. DORA requires financial entities to plan and test an exit from ICT suppliers that support critical or important functions, and the Data Act sets a switching process for cloud and SaaS services. A bespoke software contract that falls under neither is left to what you wrote into it.

Which exit rules apply to you?

It depends on who you are and what you bought. DORA applies to financial entities, and its supplier rules cover "ICT services", which the text defines as digital and data services provided through ICT systems to users "on an ongoing basis". The DORA regulation was published on 27 December 2022, and Article 64 sets its application from 17 January 2025.

The Data Act's switching chapter applies to providers of "data processing services". The Data Act text defines such a service as a digital service that gives on-demand network access to a shared pool of configurable, scalable and elastic computing resources. Bundesnetzagentur, the German regulator, says the rules cover IaaS, PaaS and SaaS. The Commission's Data Act explainer says Chapter VI applies to providers of data processing services and that Platform and Software as a Service providers must make open interfaces available.

A team that builds you a system and hands it over is not obviously either of these. Our reading is that a one-off build delivered to you is not a "data processing service", and that a continuing development and support arrangement may or may not count as "ICT services" under DORA. The texts do not settle this, and we found no official guidance that does, so a lawyer should confirm it for a specific contract. If you buy hosted software from a supplier, the Data Act is likely to apply to that part.

What does DORA require when you exit?

This section covers financial entities only. The two articles that matter are Article 28(8) and Article 30(3)(f), and a Commission delegated regulation adds detail.

Article 28(8) applies to ICT services that support critical or important functions. For these, financial entities "shall put in place exit strategies". The strategies must take into account a possible failure of the provider, a deterioration in service quality, business disruption, and termination of the contract under the circumstances in Article 28(7). Those circumstances include a significant breach by the provider and evidenced weaknesses in its ICT risk management.

The article then sets the standard. A financial entity must be able to exit without disruption to its business, without limiting its regulatory compliance, and without harm to the continuity and quality of its services to clients. Exit plans must be comprehensive, documented, "sufficiently tested" and reviewed periodically. The entity must identify alternative solutions and prepare transition plans to remove the services and the data from the provider and "securely and integrally" move them to another provider or back in-house.

Article 30(3)(f) puts this into the contract. Contracts for critical or important functions must include exit strategies, "in particular the establishment of a mandatory adequate transition period". During it, the provider keeps delivering the functions, and it must also allow the entity to migrate to another provider or to in-house solutions, "consistent with the complexity of the service provided". The article gives no number of days, so the length is for the parties to set. Article 30(2) lists further terms that matter at exit for all ICT contracts: return of data "in an easily accessible format" on termination or insolvency, and termination rights with minimum notice periods.

Delegated Regulation 2024/1773, published on 25 June 2024, specifies what the supplier policy must contain. Article 10 requires a documented exit plan for each contractual arrangement, with periodic review and testing. The plan has to be "realistic, feasible" and have an implementation schedule compatible with the exit and termination terms in the contract.

What does the Data Act require when you switch?

Article 25 sets the minimum contract terms for a data processing service. The notice period for starting a switch may not exceed two months. After it, the maximum transitional period is 30 calendar days, during which the contract stays in force and the provider gives reasonable assistance, acts with due care to keep the service running, and keeps the data secure.

If 30 days is technically unfeasible, the provider must say so within 14 working days of the request, justify it, and offer an alternative period of up to seven months. The customer may extend the transitional period once, for as long as it considers appropriate. The contract must also give a data retrieval period of at least 30 calendar days after the transition, and guarantee full erasure of the customer's exportable data afterwards. It must list every category of data and digital asset that can be ported, and the provider must support the customer's exit strategy with all relevant information.

"Exportable data" has a defined limit: input and output data, including metadata, generated by your use of the service, excluding anything protected by intellectual property rights or constituting a trade secret of the provider or third parties. Article 30(6) adds that a provider need not develop new technologies or disclose protected assets.

On cost, Article 29 allows reduced switching charges, limited to costs directly linked to the switch, until 12 January 2027. From that date no switching charges may be imposed. The Bundesnetzagentur adds that the rules cover existing contracts and new ones concluded after 12 September 2025.

Services built mainly for one customer get a lighter regime. Article 31(1) lifts the functional equivalence duty and the rules on charges and parts of the technical aspects for services whose main features were custom-built for one customer and which are not offered at broad commercial scale. The Bundesnetzagentur notes that this does not make such services fully exempt, and providers must still, for example, offer open interfaces.

The Commission has also proposed changes in its digital package, described on a page updated 20 November 2025: an exemption from the switching rules for custom-made services and for small and medium enterprises and small mid-caps, for contracts signed before the Data Act applied. That is a proposal, and we could not confirm its current stage.

What should a handover contain?

This list is our addition. The legal texts speak of services, data and transition periods, and they do not require a handover of source code, build pipelines or credentials, so the code items below come from our own view of what a working handover needs. Each item links back to a clause where one exists, and the order follows the sequence in which a handover is usually worked through.

1. Start with a list of what the supplier runs for you, naming every service, environment and subcontractor involved, because DORA Article 30(2)(a) asks for a complete description of functions and any permitted subcontracting and this tells you what must move.

2. Write down the notice period, the transition period and what the supplier keeps delivering during it, since Article 30(3)(f) and, for hosted services, Data Act Article 25 point at the same thing.

3. Build a data inventory that lists each data category, where it is stored and the format of its export, noting that DORA Article 30(2)(d) asks for return in an easily accessible format and Data Act Article 30(5) asks for a structured, commonly used and machine-readable export where no common specification exists; ask for the supplier's export to be tried on real data before the notice is given.

4. Ask for all repositories with their history, the build and deployment scripts, infrastructure definitions and the list of third-party dependencies with versions, and remember that this is our addition, that no clause requires it, and that it must therefore be in your contract.

5. List every account, key and certificate the supplier holds, who owns each one and a date by which ownership moves to you, and rotate secrets once the supplier's access ends so that no old credential keeps working.

6. Collect the documentation, meaning architecture notes, run books, known defects and the reasons for past decisions, because the supplier's knowledge is the part least likely to be written down anywhere.

7. Plan a tested exit, since DORA requires exit plans to be tested and reviewed, and a useful test is to rebuild the system from the handover material alone, in an environment the supplier does not control, before the contract ends.

8. Check the cost of the exit in writing and, for hosted services, remember that Data Act Article 25(2)(h) requires a full erasure guarantee after the retrieval period, so ask for confirmation that the erasure has happened.

If the work of getting this material has been left too late, and the code has already left without documentation, our codebase recovery page describes the review, the risk register and the documentation we produce. How we work shows the same plan, thin slice and handover steps we use on every project.

What we could not confirm

We could not open EUR-Lex directly, because it blocked automated requests, so we read the regulation texts as published by the EU Publications Office and linked the EUR-Lex pages for readers. No official guidance says whether bespoke software development counts as "ICT services" under DORA or as a "data processing service" under the Data Act, so the reading above is ours. The current stage of the Commission's proposal on the Data Act switching rules is also unconfirmed, because the Commission's page of 20 November 2025 is the only source we read.

DORA sets no number of days for the transition period, and we did not find a supervisory figure. We did not review national rules or sector guidance, such as the supervisors' expectations for financial entities in a given country. Nothing here is legal advice, and a lawyer should check a specific contract.