Appearance
Plan DH project sustainability at the proposal stage, before a line of code is written — because the choice of what to keep alive, in what form, and for how long determines your whole architecture. But "sustainability" does not mean keeping a live website running forever. The durable thing is the dataset; the interactive interface is often a liability you should be ready to retire. The skill is deciding, early, which is which.
When does sustainability planning need to happen?
Before the build. Sustainability is an architectural choice, not a closing-stage chore. If you decide up front that the lasting output is a documented dataset in a repository, you will design simple, exportable data structures. If you discover that requirement at the end, you may be trapped inside a bespoke database that no one will maintain. The cheapest sustainability decision is the one made first.
What is the difference between preservation and sustainability?
These are routinely confused, and the confusion wastes money.
| Concept | What it keeps | Typical cost | Usually worth it? |
|---|---|---|---|
| Preservation | The bits and their meaning (data, docs) | Low, one-off + storage | Almost always |
| Sustainability of a service | A running interactive site or tool | High, ongoing (hosting, security, updates) | Often not |
Preserving a CSV, TEI files and a README in a trusted repository is cheap and durable. Keeping a custom web application patched, secure and online for a decade is expensive and fragile. Treat them as separate decisions.
Does every project need a live site forever?
No, and pretending otherwise is how DH projects accumulate zombie servers. Separate the two layers explicitly:
- The data layer — transcriptions, gazetteers, images, metadata. This should be exported to standard formats and deposited so it outlives any interface.
- The interface layer — the map, the search UI, the visualisation. This is convenient but rarely fundable in perpetuity, and a security risk if left unpatched.
A responsible plan preserves the first and is honest about retiring the second.
How do I sustain a project with no ongoing funding?
Reduce the maintenance surface to near zero. The reliable pattern:
bash
# convert a dynamic project to durable static + archived data
# 1. export the database to plain, standard formats
pg_dump --data-only --column-inserts mydb > backup.sql
# 2. publish derivatives as static files (no server-side code)
# e.g. a static site generator output, plus GeoJSON / CSV
# 3. deposit the dataset and a snapshot of the static site
zip -r project-archive.zip data/ site/ docs/
# 4. upload to a trusted repository to mint a DOIStatic HTML, CSV, GeoJSON and TEI need no database, no patching and no per-month cost. They can sit on cheap object storage or a repository for years.
What does an exit or sunset plan contain?
Write it early and keep it short. For each output, decide:
- Archive — deposited in a repository with a DOI (the dataset, masters, documentation).
- Freeze — captured as a static snapshot and hosted cheaply (a read-only version of the site).
- Retire — allowed to go offline once the data is safe (the dynamic interface, the demo server).
Naming who is responsible and when each transition happens turns a vague hope into an actual plan.
When is it acceptable to let a project end?
When the data is preserved, documented and citable, and the only loss is an interactive layer few people use and nobody will fund. Letting a service sunset while keeping the dataset alive is not failure — it is responsible stewardship. The alternative, an unpatched server quietly rotting until it is hacked or silently vanishes, is worse for everyone.
How do I signal sustainability to a funder?
Show that you have separated preservation from service, named a repository and licence for the data, and written an exit plan for the interface. Reviewers are wary of projects that promise an eternal live site with no maintenance budget; they trust projects that promise durable, deposited data and an honest sunset for the rest.
Key Takeaways
- Plan sustainability before building — it is an architectural decision.
- Separate cheap, durable preservation from expensive, fragile live services.
- The dataset is the lasting output; the interactive interface is usually a liability.
- With no funding, convert to static files and standard formats and deposit in a repository.
- Write a short exit plan: archive, freeze or retire each output, with owners and dates.
- Letting a service sunset while preserving the data is a legitimate, responsible outcome.
Frequently Asked Questions
When should I start planning for sustainability?
At the proposal stage, before any code is written. Sustainability decisions — what to keep alive, in what form, for how long — shape your architecture, so retrofitting them later is expensive or impossible.
Does every DH output need a live website forever?
No. Distinguish the durable dataset, which belongs in a repository, from the interactive interface, which is often a costly liability. Many projects should preserve the data and let the live site sunset gracefully.
What is the difference between preservation and sustainability?
Preservation keeps the bits and the meaning safe over time; sustainability keeps a usable service or interface running. Preservation is almost always worth it; a live service often is not.
How do I sustain a project with no ongoing funding?
Reduce what must be maintained. Export to static files and standard formats, deposit in a trusted repository, and retire dynamic servers. Static, standards-based outputs can survive for years at near-zero cost.
What is an exit or sunset plan?
A documented decision, made early, about what happens to each output when active funding ends — what gets archived, what gets frozen as static, and what is allowed to disappear.
When is it acceptable to let a DH project end?
When the data is safely preserved and cited, and the only thing lost is an interactive layer that few people use and nobody will fund. Letting the service go while keeping the data is a legitimate, responsible outcome.