What “we own our data” actually needs to mean

Ask a business whether it owns its data and the answer is always yes. It's in the contract. The supplier has confirmed it. Nobody is disputing it.

Then ask what would happen if that supplier's service stopped tomorrow, and the answers get vaguer. Ownership as a legal fact and ownership as an operational reality are different things, and the gap between them is where businesses get stuck.

Here's what ownership needs to mean in practice — five capabilities, all testable this week.

1. You can get a complete copy, without asking

Not a support ticket. Not an export the supplier runs for you as a favour. You, or software acting for you, can retrieve everything on demand.

"Complete" is doing work in that sentence. It means the records and:

• the attachments and documents, not just references to them
• the history — who changed what, when — if the system holds it
• the custom fields you added, which are often where the most valuable information lives
• the relationships between records, not just flat tables that lose which invoice belonged to which job

Most businesses have never tested this. It takes an hour and the results are frequently surprising.

2. The copy is in a format something else can read

A PDF is not your data. A screenshot is not your data. A proprietary backup file that only that vendor's software can open is barely your data.

Usable means structured: CSV, JSON, a database dump, something with fields another system can consume. The test is simple — could a competent developer load this into a different system without hand-transcribing anything? If not, you have a printout, not a copy.

3. Somewhere else already has a copy

The one nobody does. If your data exists in exactly one place — even a reputable cloud platform — you're one account dispute, one billing failure, one mistaken deletion away from a bad month.

Suppliers back up for their own resilience, which protects against their hardware failing. It does not protect against your account being suspended, a user deleting records in bulk, or a dispute freezing access. Their backup isn't your backup, and their retention policy isn't your retention policy.

A scheduled copy into storage you control is cheap and boring, and the only version of ownership that survives an argument.

4. You know what it means without the supplier's interface

A table of order records where status is an integer and nobody knows what 4 means is data you possess and can't use. Understanding is part of ownership, and it's the part that decays silently.

What's worth writing down, once: what the core entities are, what the status values mean, which fields you populate and why, and which of them are load-bearing for how you operate.

Two sides of A4 per system. It also happens to be the document that makes any future migration or integration dramatically cheaper.

5. Nothing critical exists only inside someone else's automation

The one people miss entirely. As businesses configure software, they build logic inside it: automations, workflows, calculated fields, notification rules, approval chains.

That logic is business knowledge, and it usually exists nowhere else. Export the data and you get the records — not the fifteen rules that determined how they got that way. Rebuilding those from memory, after the fact, under time pressure, is where migrations actually fail.

The mitigation is unglamorous: keep a written list of the automations and rules you rely on, and update it when they change. Nobody does this. Everyone who has migrated a system wishes they had.

Where AI makes this sharper

This all mattered before, in a slow, insurance-policy way. It matters more now for a specific reason: the value of joined-up historical data has gone up.

Language models can now read across a business's own history and answer questions that previously needed an analyst. But only over data you can actually reach and join. A business whose five years of history is distributed across four platforms it can only view through their interfaces cannot do any of it — not because the technology is unavailable, but because the raw material is out of reach.

So the practical consequence of not owning your data has changed. It used to be a risk. It's now a capability gap, and it widens as everyone else's data gets more usable.

The five-question test, applied

Take your three most important systems and answer honestly. Most businesses find one clean pass, one partial, and one uncomfortable.

That table is roughly what every small business finds, and the pattern is consistent: exports are better than expected, second copies are worse, and documentation doesn't exist anywhere.

The attachment problem

Worth singling out, because it catches people badly.

Most exports give you records and a reference to each attachment, not the attachment itself. So you export ten years of jobs and get every field except the photographs, the signed paperwork, the drawings and the certificates — which in some businesses are the most valuable part of the record.

Pulling those out is usually possible but rarely automatic: it means iterating every record, requesting each file, and storing it against a sensible identifier. It's a job worth doing deliberately rather than discovering the gap during a migration.

The specific question for a supplier: "does the export include the files, or only links to them?" The answer is almost always links.

What a scheduled copy actually involves

Modest, and worth being concrete because "back up your data" is uselessly vague advice.

A scheduled job — daily is plenty for most things — that calls each system's API, writes the structured result into storage you control, and keeps a rolling set of versions so you can go back rather than only having last night. Object storage costs pence at this volume.

Two refinements that make the difference between a copy and a usable copy. Keep the raw response exactly as it arrived, so nothing is lost by a transformation you later regret. And record the run — what was fetched, how many records, whether it completed — so a copy that silently stopped in March is visible rather than assumed.

Then test a restore once. Not a full migration; just take one day's copy and confirm you can read it and identify the records. Untested backups are a common and expensive genre of false confidence.

The automation inventory

The fifth capability is the one nobody does, so here's what it looks like in practice.

A single page per system listing every rule you rely on: automated emails and what triggers them, workflow stages and what moves records between them, calculated fields and their formulas, notification rules and who receives them, approval chains, and any integration to another system.

One line each is enough. The point isn't documentation for its own sake — it's that this logic represents years of accumulated decisions about how your business runs, and it currently exists only inside somebody else's software. Export the data and none of it comes with you.

Keep it in the same place as the data dictionary, and update it when something changes. It takes minutes and it's the single cheapest insurance policy available.

The version worth aiming at

You don't need to leave your suppliers or build everything yourself. What's worth having is modest:

• A scheduled copy of everything important, in a structured format, in storage you control.
• A short written note per system saying what the data means.
• A list of the automations and rules you depend on.
• Read access via API wherever it exists, so the copy is automatic rather than a task.

That's a week of work, mostly writing rather than building, and it converts "we own our data" from something in a contract into something you could prove on a Tuesday afternoon.