An export you have never restored is not an exit

The contract has an exit clause. The vendor’s documentation has a page called “Export your data”. Someone in procurement ticked the box asking whether data can be retrieved at the end of the agreement. On paper, the organisation can leave.

Then the renewal arrives with terms nobody likes, and for the first time somebody presses the button. What comes back is a set of files: a few large CSVs, a JSON document with fields named after internal identifiers, a folder of attachments without the records they belonged to. Everything is technically there. Nothing can be loaded into anything else without weeks of work by people who understand both the old system and the new one — and the only people who understand the old one work for the vendor being left.

The renewal gets signed. Not because the product is good, but because the exit turned out to be a file rather than a route.

Why this keeps happening

An export is an output. An exit is an operation: taking what the old system held, putting it into a new one, and carrying on with the work. Contracts and checklists describe the first because it is easy to verify. They rarely describe the second, because nobody tries it until they need it, which is the worst possible moment to find out what is missing.

Backups went through the same lesson a generation ago. Teams that had run backups for years discovered during an incident that nobody had ever restored one, and the industry’s answer was the restore test. Exits have not had their restore test yet.

Where exports quietly fail

The data comes out, the meaning does not. Records arrive with internal ids instead of names, status codes without the list that explains them, and relationships that only made sense inside the vendor’s schema. A file that needs the old system to interpret it is not independent of that system.

History is missing. Many exports give the current state and drop the audit trail, the versions, the comments and the reasons a record changed. For anything regulated, that history is often the part that matters most.

Configuration stays behind. Workflows, permissions, automations, templates, the rules that decide what happens to a record. These usually live in screens rather than tables, are rarely included, and rebuilding them by hand is where most migration time goes.

Attachments lose their owners. Files come out in one place and records in another, with nothing reliable to join them.

Nobody owns the operation. The exit clause sits with legal, the export with IT, the business process with operations. A rehearsal needs all three in one room, which is why it rarely happens.

What to do instead

Treat the exit as a procedure with an owner, a target and a date, the way a disaster-recovery plan is treated. In some sectors this is becoming an expectation rather than a choice: rules on operational resilience in the financial sector, and EU data rules that also cover switching providers, push towards exit plans that work in practice and not only on paper. What applies to a given organisation depends on its sector and how it uses the service, and is worth checking with someone who knows that sector well. Where no rule applies, the logic is the same.

Name the destination. Not a specific vendor, a class of system: another product in the same category, a database you run yourself, or a plain archive you can still read in ten years. Each needs a different export.

Define done in business terms. “We can issue an invoice from the new system with the full customer history” is a test. “We received a ZIP file” is not.

Rehearse on a slice. One department, one quarter, one product line. Load it into the destination, run one real process end to end, and write down every manual step it took.

Put the gaps in the contract. Whatever the rehearsal shows is missing — history, configuration, documented field meanings — becomes something the vendor commits to provide, with a format and a timeframe, at the next renewal.

Repeat it. Systems change and exports change with them. A rehearsal from three years ago describes a product that no longer exists.

This is also how we look at the companies we build. A product whose customers could leave has to make this procedure boring: documented formats, history included, configuration exportable as data. If the exit only works on the vendor’s good days, it is a courtesy rather than a property of the product.

A test you can run this week

Pick the one system your organisation would find hardest to leave. Then, without asking the vendor for help:

1. Export everything the interface allows you to export.
2. Hand the files to a colleague who has never used that system.
3. Ask them to answer three ordinary questions from the files alone: what happened to a particular customer last year, who approved a specific change, and which rules decide how a new record is handled.

Time it, and write down what they could not answer. That list is your real exit clause. Everything not on it is already portable; everything on it is what you are actually paying for when the renewal arrives.

Why we treat this as a supply-chain matter rather than an IT one is in sovereignty is a supply chain question, and what XUBRiS is, and is not, is on the homepage.