The Data You Should Be Able to Export on Any Tuesday

Exporting data is filed mentally under leaving. It is the thing you do at the end, when relations have soured, and it is therefore never tested until the day it has to work.

That framing is a mistake, because a routine export is useful in ordinary circumstances and because the only way to know whether the emergency version works is to have run it when there was no emergency.

The ordinary reasons to export

To check something the interface will not tell you. Every system's reporting stops somewhere. A spreadsheet of the underlying records answers questions the built-in reports were not designed for, in about ten minutes.

To find what is broken. Duplicate customers, records with no owner, addresses that were never valid, fields containing three different conventions. These are visible in an export and almost invisible in an interface that shows one record at a time.

To give somebody a copy. An accountant, an auditor, a consultant, a client who wants their own file. This happens more often than departures do.

To keep an independent copy. Not because you distrust the platform, but because a copy you hold is a copy that survives a mistake — including your own.

None of these are adversarial. All of them exercise the same machinery you will one day need in earnest.

What a real export contains

The word covers a wide range of things, and the differences matter.

Records, not screens. An export organised by what appears on each page of the interface is not a dataset; it is a set of screenshots in spreadsheet form. What you need is the underlying entities.

Relationships preserved. A file of customers and a file of orders are of limited use if nothing in the second identifies which customer each order belongs to. Identifiers must survive, and they must match across files.

History, not just current state. The present value of every field is the least interesting part. What changed, when, and by whom is what makes an export a record rather than a snapshot.

Attachments as files. Contracts, images, signed documents. An export where the file column contains a link back into the platform is an export that becomes worthless the day the account closes.

The standard worth holding any system to is the one written into data protection law: personal data provided "in a structured, commonly used and machine-readable format" with the ability to transmit it elsewhere "without hindrance" [1]. Each of those three phrases rules out a common failure. Ours is a JSON export of all your records [2], and the reason to state the format plainly is that a format is checkable in a way that a promise is not.

The test, and why it should be boring

Run the export. Not read about it — run it, on real data, on an ordinary day.

Then open the result and try to answer three questions using nothing else. Who are my ten most recent customers? What did one of them buy, and when? What was said to them, and by whom?

If any of those cannot be answered from the file alone, you have found a gap, and you have found it on a Tuesday rather than during a migration. That is the entire point of the exercise.

It is worth repeating occasionally, because exports break quietly. A new field gets added to the product and not to the export. A format changes. A previously included section becomes a paid add-on. None of these produce an announcement.

Exports are personal data, and they leave the building

A practical warning, because this is the part that turns a good habit into an incident.

The moment an export is produced, a complete copy of your customer data exists outside the system that was protecting it. It is now in a downloads folder, an email attachment, a shared drive, or a consultant's laptop — none of which have the access controls, the audit trail, or the deletion schedule that the platform had.

The most common data loss in small businesses is not a breach of a vendor. It is an export sitting somewhere it was never meant to persist, on a device that was subsequently lost, sold, or shared.

Two habits make this manageable and neither is onerous. Export to a defined place rather than wherever the browser puts things, and delete the file when the task that required it is finished. And when sending an export to someone outside the business, treat it as what it is — a copy of everything about your customers — rather than as an attachment.

The point of exporting regularly is to prove you can. It is not to accumulate copies, and a business with eleven old exports scattered across three machines has made itself less safe, not more.

What an export does not solve

Two honest limits, because pretending otherwise leads people to skip the harder thinking.

Configuration is not portable. Your workflows, custom fields, permission structure and automations are shaped by the platform and mean nothing outside it. That is a real cost of adopting any system and should be counted at the time rather than discovered later.

And an export is not a backup. A file on somebody's laptop, produced once, is not a recovery plan — it has no schedule, no verification, and no test. A backup is something restored on purpose at intervals; anything else is a copy you hope is current.

The deletion side of the same question

Export and deletion are two halves of one subject: control over data you have placed somewhere else.

The same rigour applies. What does deletion actually remove, how long does it take, and is there a window in which a mistake can be undone? A stated schedule is what makes this checkable — ours is a 30-day recoverable window, then 60-day retention for legal and forensic needs, then hard-purge [3].

Both halves matter for the same reason. A business that cannot get its data out does not fully control it, and one that cannot get it deleted does not either. The pleasant thing about both is that they are testable in an afternoon, long before either becomes urgent.