Essay 07 / Digital

The Export You Can Actually Use

A download becomes an exit route only when another tool can recover the work, the structure, and enough context to continue.

A portable solid-state drive and cable lie beside an archival box of paper folders.
Records that can move with you. An original illustrative scene.

The button says “Export everything.” A few minutes later, a compressed archive appears in the downloads folder. Its size is reassuring. The account has offered an exit, and the data seems to have taken it.

But what exactly arrived? A collection of readable documents is different from a database dump that requires a programmer to interpret. A calendar with dates but no time zones is different from the calendar you relied on. A folder of photographs without their original filenames may contain every image while losing the relationships that made them useful.

An export is a translation. The practical question is whether enough meaning survives the translation to let you continue your work somewhere else.

Choose a task, not an archive

Basics · An export is a copy you can take elsewhere

Exporting asks an application to put your material into files you can keep outside it. Downloading those files is the transfer step. Importing asks another application to read them. These are separate operations: a successful download does not promise a successful import.

A compressed archive is simply a package that holds files together. Its contents still need to be in formats you can open and use.

Start with something smaller than an entire account. Choose a project containing a few representative complications: a note with an attachment, a document linking to another document, a recurring appointment, or a photograph with a caption. Ordinary edge cases are valuable here. The simplest item often travels well even when the collection does not.

Then name the task you want the exported material to support. Perhaps you need to find the receipt attached to a purchase record. Perhaps you need to revise an article while preserving its footnotes. Perhaps a collaborator needs to understand the order of decisions in a project.

This defines success in terms of work. Counting files can confirm that something happened, but it cannot tell you whether the result is usable. A thousand messages in a single unsearchable document might satisfy an export counter and still fail your task.

Prefer protocol copies over dashboard zips when they exist. Mail leaves more usefully through IMAP (mbsync) than through a “download your data” HTML tree. A git host leaves more usefully through git clone --mirror than through a zip of the default branch. A calendar leaves more usefully as .ics than as screenshots of a month view.

Open it somewhere unfamiliar

Keep the source untouched. Place the export in a separate folder, read any accompanying format description, and try opening the material with an independent application. For plain text, a basic editor may be enough. For tabular records, inspect a copy in a spreadsheet. For specialist work, identify a second tool that claims to read the format.

Notice which dependencies follow you out. Some exported pages contain links to attachments that remain on the provider’s servers. Some images are thumbnails. Some references point back to an account rather than to another file in the archive. A document that looks complete while connected may reveal missing pieces later.

Do not repair every problem immediately. Write down the first point at which the intended task becomes difficult. This keeps the exercise from turning into a migration project before you have understood its size.

Preserve relationships deliberately

Individual files often survive more easily than the relationships between them. Order, tags, comments, authorship, and links may live in the application’s database rather than in the documents themselves. A useful exit plan identifies which of those relationships matter.

For a reading collection, the essential structure might be the original source address, your annotation, and the subject under which you expect to find it. For a design project, it might be the editable source, the final output, the fonts or other permitted dependencies, and a note explaining which version was approved.

Sometimes the practical answer is a companion index. A short table connecting exported filenames to project names and dates can preserve a relationship that the export format drops. Sometimes it is a human-readable snapshot alongside the editable source. These copies serve different purposes: one shows what you meant, the other supports further work.

Avoid preserving everything merely because it exists. Identify the context whose loss would create expensive guessing.

Expert · Check integrity without confusing it with meaning

For a large archive, a manifest can record a relative path, a byte count, and a cryptographic digest such as SHA-256 for every file. Compare a newly computed manifest after copying the archive to independent storage. Matching digests provide strong evidence that those bytes survived the transfer. They do not establish that the export contained everything, that the source was trustworthy, or that another application understands its structure.

( cd export && find . -type f -print0 | sort -z | xargs -0 sha256sum ) \
  > /tmp/export.sha256
sha256sum -c /tmp/export.sha256

A second check concerns relationships. Parse a copy of the exported index, resolve its attachment and document references against the archive, and report unresolved targets. Preserve the original export before attempting repairs. Stable identifiers are often safer than display names: two records can share a title without referring to the same thing. Even a clean report needs a human task rehearsal, because syntactically valid links can still point to the wrong record.

For mail, formail / mb2md / Thunderbird “import” are different translations. Count messages on both sides before you delete the IMAP account. For git, git fsck --full on the mirror is the integrity check; the issue tracker is a separate export.

Price the distance to departure

You do not have to leave a useful service to benefit from this exercise. Knowing the cost of departure changes your relationship with it. A migration that takes an afternoon is a different commitment from one that depends on reconstructing years of undocumented structure.

Record the date, the export route, the format, the application used to inspect it, and the gaps. Include an estimate of the human work required. “Attachments copied manually” is more informative than “export supported.” Repeat the check after a substantial change in how you use the service, especially when you introduce new kinds of content.

The record should also say what the export is not. It may preserve your documents without preserving permissions, discussion history, or automation. Those limits are manageable when visible. They become unpleasant surprises when hidden behind the word “everything.”

Make the next exit cheaper

The most useful changes often happen during ordinary work. Give projects stable names. Keep original attachments when they matter. Write down decisions in a form that does not depend entirely on a particular interface. Prefer links that can be understood outside your own account when sharing durable references.

These habits reduce the amount of interpretation a future move will require. They can also improve today’s search, handover, and collaboration.

A successful rehearsal ends with evidence: someone completed the chosen task using the exported material. The service may remain the best place to work. You now know which parts of your work can travel, which need help, and what keeping that option open actually involves.

Next essay Back to the beginning ↑