Skip to content
← Back to the toolkit
DisposeUseDataSoftwareHardwareOrganisational

Data portability

The ability to extract the data and context required within the stated scope in a documented, usable form and transfer or load them into an independently chosen system.

Portability supports Data Dispose and continued Data Use. An exercised transfer shows what can move, what meaning survives and which dependencies remain.

Portability is a scoped capability. Start by naming the destination use and the information it requires. A reporting migration, an archive, a live service replacement and a regulatory handover can need different data, fidelity, timing and evidence.

A download is useful evidence, but its value depends on what can be done with it. Check:

  • completeness against a defined inventory and time range;
  • schemas, identifiers, relationships, history and meaning;
  • permissions, provenance and audit evidence where the destination needs them;
  • documented formats and interfaces that an independent implementer can use;
  • export duration, throttling, cost, incremental updates and cutover behaviour;
  • lawful retention, deletion and transfer constraints;
  • software, infrastructure, skills and supplier cooperation needed to complete the move.

Open standards can reduce dependence, but a format name alone does not establish portability. Conversely, a non-standard format may still support a scoped transfer when the customer has durable specifications, suitable tools and the rights to use them.

Exercise the full path into a representative destination and reconcile the result. A successful test is evidence for that tested scope and date, not proof that every volume, failure mode or future release will work. Record exclusions, manual transformations, timing and residual dependencies, then repeat after material changes.

Portability contributes to sovereignty without establishing it on its own. An organisation still needs the authority and supplier cooperation to leave, while Software or Hardware dependencies can prevent an otherwise complete data export from supporting an actual exit.

Common misconceptions

The vendor provides an export endpoint, so the service is portable.

An endpoint is evidence of one mechanism. Test whether the scoped records, relationships, history, metadata, permissions and audit evidence needed at the destination are available, documented and usable.

A CSV export is never portable enough.

A documented CSV may be sufficient for a simple scope. It is insufficient where continuity depends on relationships, types, events, policies or other context that the files omit.

Put this to work

Apply this checklist

Can you leave? The exit-readiness checklist

Twelve checks that tell you whether you could actually move off a critical supplier, before you need to. Print it, take it into a stand-up, and mark honestly.

Questions for your vendor

Questions to ask a vendor before you sign

The questions that make a supplier prove data sovereignty, and what a real answer versus an evasive one sounds like. Copy them into an RFP, or read them down a vendor call.

Related concept

Vendor lock-in

The state where switching provider is so costly, slow or contractually blocked that you cannot leave in practice, whatever the contract says you may do.

Related concept

Exit clause

The contractual terms that decide what happens to your data and your access to it, when the arrangement ends, on any terms including the ones you did not choose.

Copyright 2026HOIST IT. All Rights Reserved