Appearance
To plan a data handoff at project end, assemble a self-explanatory package — data in open formats, full documentation, a licence, and fixity checksums — and deposit it with a named, durable recipient who can keep it alive. The goal is simple but exacting: someone with no contact with you should be able to find, open, understand and reuse the data years later. A handoff that preserves the bits but loses the meaning has failed.
When should the handoff be planned versus executed?
Plan it on day one; execute it in the final weeks. Almost everything that makes a handoff smooth — open formats, consistent file naming, documentation written as you go — has to be decided early. If you arrive at the end with a tangle of proprietary files and no notes, the handoff becomes a salvage operation. Bake the destination and standards into the project from the start, and the closing handoff is mostly packaging.
What goes in a complete handoff package?
A package a stranger can use without asking you anything. The minimum contents:
text
project-handoff/
data/ # the datasets in open formats
images/ # master files (TIFF / JP2)
docs/
README.md # what this is, scope, how to use it
data-dictionary.md # every field and code defined
provenance.md # sources, processing steps, decisions
LICENCE.txt # how others may reuse it
manifest.csv # every file, its size and checksum
CHANGELOG.md # versions and what changedIf any of these is missing, the recipient inherits a puzzle rather than a dataset.
Which formats should I hand off in?
Open, well-supported, application-independent ones — because the recipient may open them in software that does not exist yet.
| Content | Hand off as | Avoid |
|---|---|---|
| Tabular data | CSV (UTF-8) | XLSX-only, Access |
| Encoded text | TEI-XML (P5) | Proprietary word formats |
| Spatial data | GeoJSON, GeoPackage | Shapefile-only, vendor GIS |
| Master images | TIFF, JP2 | Layered PSD as the only copy |
| Documentation | Markdown, PDF/A | Closed wiki exports |
The test is simple: will this file open without the original software in ten years? If not, convert it before handing over.
How do I prove the files arrive intact?
Generate fixity checksums for every file and record them in the manifest. The recipient re-computes them on receipt to confirm nothing was corrupted in transfer or storage:
bash
# create SHA-256 checksums for every file and save a manifest
find data images docs -type f -exec sha256sum {} \; > manifest.sha256
# the recipient verifies on arrival
sha256sum -c manifest.sha256
# expect: every line ends in "OK"Using the BagIt packaging convention formalises this: a "bag" bundles the payload with checksums and a manifest in a standard, machine-checkable layout.
Who should receive the handoff?
A durable, named destination — never an individual's laptop or personal cloud. Suitable recipients are a trusted repository with persistent identifiers, an institutional archive, or a partner organisation with a mandate to keep the data. Confirm three things before transfer: they will accept the formats, they can sustain the storage beyond the project, and there is a named contact responsible. A handoff to "the team's shared drive" with no owner is not a handoff.
What is the most common handoff failure?
Data that survives but cannot be interpreted. A folder of well-preserved files with no README, no data dictionary and no provenance is functionally lost — the recipient has the bits but not the meaning. Documentation is not the optional extra of a handoff; it is the part that makes the data reusable. Spend at least as much of the final effort on the docs as on the data files themselves.
How do I run the final handoff checklist?
In the closing weeks, work through this list:
- All data converted to open formats and validated.
- README, data dictionary and provenance complete and accurate.
- Licence stated for data and any code.
- Checksums generated and a manifest written.
- Recipient confirmed, formats accepted, contact named.
- Transfer completed and checksums verified by the recipient.
- A persistent identifier (DOI) minted, if the recipient supports it.
Key Takeaways
- Plan and prepare the handoff from day one; execute it at the end.
- Hand off a self-explanatory package: data, docs, licence, checksums, manifest.
- Use open, application-independent formats that will still open in a decade.
- Verify integrity with fixity checksums; BagIt formalises this neatly.
- Deposit with a durable, named recipient — never a personal device.
- Documentation is what makes the data reusable; preserved-but-undocumented data is lost.
Frequently Asked Questions
When should I plan the data handoff?
Plan it at the start and prepare for it from the start, but execute it in the final weeks. Handoff is far easier if your formats, documentation and naming were chosen with deposit in mind from day one.
What should a complete handoff package contain?
The data in open formats, a README, a data dictionary, provenance and processing notes, a licence, fixity checksums, and a manifest listing every file. Anyone should be able to understand and reuse the data without contacting you.
What formats should I hand off in?
Open, well-supported formats: CSV or TEI-XML for text, GeoJSON for spatial data, TIFF or JP2 for master images. Avoid proprietary or application-specific formats that may not open in a decade.
How do I prove the handed-off files are intact?
Generate checksums (such as SHA-256) for every file and include them in a manifest. The recipient verifies the checksums on receipt to confirm nothing was corrupted in transfer.
Who receives the handoff?
A named, durable destination — a trusted repository, an institutional archive, or a partner organisation — not an individual's laptop or a personal cloud account. The recipient must be able to keep the data beyond the project.
What is the single biggest handoff failure?
Data that is technically preserved but undocumented, so no one can interpret it. A folder of files with no README and no data dictionary is functionally lost even though the bits survive.