← All insights

What an exit strategy means in practice: four questions per system

Jacques Domenie · October 6, 2026 · 6 min read

If your organisation runs important systems in someone else's cloud or software, someone will soon ask you for an exit plan. For central government and its agencies, apart from Defence, that request became policy on 3 July. Every material use of cloud now needs a documented exit plan, assessed by the organisation itself, for two scenarios: a planned exit and a sudden disruption. Both are reviewed every year, and where the cloud is already in use, the plan is due in July 2027, twelve months after the policy was adopted. Other public bodies, municipalities and water boards among them, are advised to follow the policy. Banks, insurers, pension funds and asset managers have had a version of the question for longer, from the rules on outsourcing and IT risk their supervisors enforce.

Many organisations will answer the request with the exit strategy their procurement team wrote into the contract: the right to terminate, the data returned in a standard format, a transition period. The government's own letter to parliament on the new cloud policy notes that current exit strategies often deal mainly with the supplier handing back the data and deleting it. That is the part of an exit that works on paper.

What a contract clause does not cover

In August, ShapeBlue, a company that helps organisations move off VMware, reported that every public download page for a small piece of VMware software returned an error. The software is VDDK, the Virtual Disk Development Kit. Many migration and backup tools use this library to read a virtual machine's disks from outside VMware, and it is usually the fastest way to move them. Its licence does not allow general redistribution; only partners with a signed agreement may ship it.

In September Broadcom, which owns VMware, confirmed that it had withdrawn the public VDDK downloads and that the library is now available only through selected partners, for backup and recovery. Other routes still work, but some are slower, such as exporting each machine first, and others depend on how the storage is set up. No customer contract covered the library: Broadcom says it was never part of what customers bought.

There is a difference between an exit you are allowed to make and an exit you are able to make. A contract can give you the right to leave. It cannot tell you whether the systems around your data can move, how long the move takes, what it costs while you run two environments, or whose law can reach the system on the day you need to go. Those are architecture questions, and they have to be answered system by system, because every system resists moving for its own reason.

Four questions per system

For each system that matters, an exit strategy comes down to four questions, and a board needs the answers before it can decide on an exit plan. Written down, the answers form a map: one row per system, one column per question, with a name next to each answer.

Can we leave? Can the data come out complete and in a usable form, and can the work that runs on it be done somewhere else? A system that exports its data but keeps its logic in the supplier's own workflows can only be left by rebuilding that logic.

How long does it take? The realistic time to move, including the dependencies nobody listed: the login service, the integration platform, the migration tool that relies on a library from the vendor you are leaving. Write down what the number rests on: a test migration, the supplier's word, or a guess.

What does it cost? The migration itself, the months of running old and new side by side, and the price of the alternative. Here a planned exit and a forced one part ways. An exit you choose can be planned and tested in advance; an exit forced on you by a supplier that stops cannot.

Under which law? Who owns the provider, where the data and the operations sit, and which country's authorities can demand access. In July a judge in Rotterdam, in interim relief proceedings, refused to suspend the government's block on the sale of Solvinity to the Dutch arm of the American firm Kyndryl. Solvinity hosts DigiD, the government's login service. The block rests on the risk that, after the sale, American law could give the American government access to the sensitive data Solvinity handles, through the Dutch arm's parent company in the United States. The judge found that the government could reasonably see that as a threat to the public interest. In August Kyndryl said the acquisition would not go ahead because of the ban and that it would not contest the decision; Solvinity is pursuing its objection.

The Rotterdam judge also gave the government guidance for its decision on Solvinity's objection: look more closely at encrypting the data so that Solvinity cannot read it. The key would then sit with the government or with a third party. The case shows that the question is about ownership as well as about where the servers stand, and that part of the answer may lie in the architecture. It is a provisional ruling: by early October no decision on the objection had been made public, and a court can review that decision when it comes.

Two scenarios, reviewed every year

The two scenarios produce different maps: a system that is easy to leave in a planned exit can be the weakest point in a disruptive one. For a planned exit, the question is cost and sequence: which system first, which contract ends when, what can move in the same year. For a disruptive exit, the supplier is gone tomorrow, bankrupt, sold or cut off, and the question is which services you can keep running and for how long.

Both maps change every year as systems are replaced and providers change hands. That is why the policy asks for a yearly review, and why a plan written once is out of date by the next budget round. The review is cheap if the first map recorded who answered each question and on what basis; it is a new project if it did not.

What it costs, and what it does not settle

Mapping your most critical systems this way takes the people who know them: the application owners, an architect, and someone who reads the contracts. The policy comes without extra budget, so their time competes with everything else. The cost of not doing it shows up later and at a bad moment, when a supplier changes its prices or its terms and you negotiate from a position you cannot measure.

The map gives a board the facts per system to decide on. It does not settle everything. The legal column is the least stable: the Rotterdam ruling is provisional, and the first annual reviews under the new policy have yet to show what the government will accept.

Where to start

Take the three systems your organisation could least afford to lose. For each, write down whether you could leave it, how long that would take, what it would cost and under which law it runs, with the name of the person who gave each answer. Where nobody can answer, that question is the first item on your exit plan.

Jacques Domenie led the IT function of a bank under central-bank supervision and answered to its board, its supervisors and its auditor. He works for organisations part of the week through Delfen (delfen.com).

Contact: domenie@delfen.com or delfen.com/en/contact. The exit map is described at delfen.com/en/diensten.

Sources & further reading

Recognize this question in your own organization? That is worth a conversation.

Get in touch