A Pre-Contract Data Portability Test: Proving That Exports Are Actually Usable

Why the test belongs before the signature

Almost every evaluation examines how well data flows into a product: loading a catalogue, approving a record, reconciling a reference table. Almost none examine how it flows out — yet that is the question that decides whether you can ever leave. A vendor selling you a system wants entry to feel effortless and exit to stay invisible: during the sales cycle you get answers to any question, while after the signature the same questions take months and cost extra.

A portability test is a short procedure best run during the pilot or trial, before you have paid anything. It typically takes a few hours and immediately reveals what you would inherit: open, machine-readable formats, a documented API and a structure a competent person can load elsewhere, or a proprietary black box whose data can only be extracted by the vendor's hands. An excellent system that is hard to leave may still be the right choice — but you should learn the price of leaving before you sign, not after.

• An export run in the trial is cheap, quick and disproportionately informative.
• Ask exit questions while the vendor still wants your business; the same answers are hard to obtain later.

What “usable” actually means

Usability is not “a file was generated and downloaded”. An export has measurable attributes: format, completeness, legibility, preservation of relationships and re-ingestability. The format should be structured, commonly used and machine-readable — CSV, JSON, XML or an open domain standard, not a summary PDF report. Completeness means that attachments, comments, audit logs and change history export along with core records, not that a screen of account fields arrives intact.

Relationships between records are the most underestimated criterion. If an export produces flat tables that no longer show which document belongs to which customer or contract, the data is formally present but practically useless. Finally, usability is proven by loading the file back: can another system ingest it without a bespoke script written for this one vendor? A rough check is to look at the export and ask honestly whether a competent person could load it elsewhere without custom code. If clearly not, that is the lock-in cost, and it belongs on the same scale as the price.

Running the test: real data, your own hands

Sample data is clean, consistent and complete; yours is none of those, and that gap is where implementations fail. Ask for a test environment with your real data and perform the export yourself, through the interface, without asking vendor support to do it. If the export can only be produced by the vendor on request, record that fact: at a real termination you will depend on their queue and goodwill in exactly the same way.

Start with the core: export everything that has been entered into the system, open the files and confirm the fields are populated and the structure is comprehensible. Then check that attachments and documents come out as files, not as filenames or links. Check history separately — comments, change log, approval stamps — because this is what is most often left behind. Verify that relationships survive, that it is still clear which record belongs to which, rather than arriving as disconnected tables.

Do not stop at the happy path. Test the awkward cases: records with large attachments, long approval histories, fields with unusual characters and encodings. Keep the output as-is, then try to re-import it into a neutral system — an open database or another tool — and count the losses: how many records and attachments arrived without distortion. That percentage is your real portability figure.

• Run the export yourself, not along the vendor's demo script.
• Check attachments and history — that is where exports fail most often.
• Verify relationships and attempt a re-import into a neutral system.

What to write into the contract

The test captures the current state; the contract must hold it for the entire term. While the vendor still wants the deal, get and fix in writing: the export format that will be available, how long data is retained after termination and in what form, whether an export or migration fee applies, the notice period and the handover procedure. These answers are easy to obtain before signing and nearly impossible afterwards.

It helps to distinguish an export from a migration. An export is a file; a migration is that file in a state another product can ingest. A vendor can fully satisfy the first while leaving you with something no other system will accept. So the contract should separate these obligations and require open machine-readable formats, a documented API and a workable export window even if the vendor sunsets the product or leaves the market. Confirm that export remains possible after support ends — otherwise the right to your own data loses most of its value.

The regulatory backstop: Article 20 GDPR and the EU Data Act

Law reinforces the idea of an export check, but it does not replace it. Article 20 of the GDPR gives a data subject the right to receive the personal data they have provided to a controller in a structured, commonly used and machine-readable format and to transmit it to another controller without hindrance. The right applies where processing is based on consent or contract and is carried out by automated means, and direct transmission is possible where technically feasible. That is a legal floor that does not guarantee completeness or convenience for your business purposes — which is why the technical test remains necessary.

For cloud services in the European Union, Chapter VI of Regulation (EU) 2023/2854 (the Data Act), applicable from 12 September 2025, obliges providers of IaaS, PaaS and SaaS to remove technical, contractual and organisational obstacles to switching, to support export in structured, commonly used and machine-readable formats, and to phase out switching fees — only reasonable direct costs until January 2027, then no switching charges at all. This is general information about EU law, not advice for your jurisdiction; for organisations outside the EU, or for systems that are not “data processing services”, these rules do not apply directly, which only increases the weight of the contract and of your own test.

• Article 20 GDPR covers only personal data “provided” by the subject and requires a machine-readable format.
• Chapter VI of the EU Data Act requires removing switching barriers for cloud services from 12 September 2025.
• General information about the law is not a substitute for qualified advice on your jurisdiction.

Limits, and the cost of skipping the test

Some switching cost is unavoidable and often worth accepting; the mistake is accepting it without knowing its size. An excellent product that is hard to leave may still be right; an adequate product that is hard to leave is a poor bargain, and you cannot tell the difference without running the test. The test also cannot promise that future updates or a vendor platform migration will not change the format — which is why you should repeat it annually and keep the file as an independent backup of your own data.

The test has its own limits. It captures portability as it is today, not how the system will behave later; it requires access to real data, which may conflict with confidentiality and call for an NDA; and it does not answer what to do once an export exists but nobody can ingest it, which is a separate acceptance plan for the receiving system. Remember too that an export check is not a legal opinion on your rights to the data — it is an engineering control of usability that lets you sign the contract with open eyes.