Archiving a database does not preserve the application that made the database useful.
SIARD is a sound starting point. It provides an open, software-independent format for preserving the structure and content of relational databases. It reduces dependence on proprietary database dump formats and, with suitable SIARD-compatible tooling, supports the transfer of archived data into a relational database when required.
That is valuable. It is also only part of the application-retirement problem.
Once the original system is switched off, future users rarely ask to inspect a table. They need to find a case, understand an invoice, retrieve the documents linked to a laboratory result, or reconstruct the evidence behind a decision.
A database export alone does not give them that experience.
What SIARD preserves well
SIARD was designed for the long-term preservation of relational databases. It captures database content and structural metadata in a ZIP64 container, using XML and XML Schema and drawing on SQL standards for identifiers and data types.
This makes SIARD useful as a preservation format and as an exit format. It can help organisations retain data without keeping the original database software alive indefinitely.
The Swiss Federal Archives also identify an important limitation: a SIARD file is not normally sufficiently self-documenting to guarantee that archived data will remain interpretable. Documentation about the source system and data model may need to be preserved alongside it, including data descriptions, code lists, system specifications, user manuals and screenshots.
That is where the distinction becomes important.
SIARD preserves the content and structure of a relational database within the format's defined scope. Application retirement must preserve the information people still need to use.
The gap appears when someone needs the data again
After a raw database has been archived, access still requires a technical route. Someone needs a viewer, a new front end, or a database into which the data can be loaded.
Even then, the user may see tables and column names rather than the business objects that existed in the application.
The missing layer can include:
- The relationship between a case and its documents;
- The header, lines and attachments that together form an invoice;
- Labels, code lists and definitions needed to interpret calculated values;
- Documentation of relevant workflows and business rules;
- The context in which a result was created;
- The search paths that users relied on;
- The access requirements, audit context and retention rules that must carry forward.
The more specialised the source application, the larger this gap can become. ERP, laboratory and instrument systems are obvious examples, but the same applies to almost any solution with a complex data model. Its data may remain technically present while becoming difficult to interpret without the surrounding context, relationships and readable representations.
Start with the business object, not the table
A more complete application-retirement approach begins by asking what users will need to retrieve after the system is gone.
For a finance application, that may be an invoice with its line items and attachments. For case management, it may be a complete dossier. For a laboratory system, it may be a test result together with the instrument, analyst, method, date and related files required to understand it.
Those are business objects. Their structure rarely maps neatly to a single database table.
In a Docbyte Vault application-retirement solution, the source data is analysed and assembled around these business objects. Relevant data, metadata and files can then be packaged for controlled ingest into the archive. The archival schema defines the object's structure, while a readable view helps future users interpret it without recreating the retired application.
This does not make SIARD irrelevant. A SIARD export or native database dump can still be a useful source or preservation component. The difference is that it is not treated as the finished user experience.
Preserve access as well as content
The archive must also provide a practical route back to the information.
Vault Explorer gives authorised users a lightweight interface for searching, browsing and viewing archived content. Search configurations can expose the fields, filters and result columns that matter to a specific user group. Linked searches can connect related objects, allowing someone to move from a case to its documents or from a parent record to associated items.
The viewer separates metadata, preview and available representations. Users can therefore see the record context, inspect readable content and access the preserved formats without working directly with database tables.
This is the operational difference between retaining data and retiring an application responsibly.
Five questions to ask before switching off the source system
Before accepting a database export as the retirement solution, ask:
- Which business objects will people need to retrieve later?
- Are their relationships and attachments preserved with them?
- Will users understand the fields, codes and context without the original application?
- Is there a readable, governed way to search, browse and view the records?
- Can the organisation demonstrate completeness, integrity, retention and controlled access after shutdown?
If the answer to these questions depends on rebuilding the source application later, the retirement design is incomplete.
SIARD is a component, not the whole solution
SIARD solves a real preservation problem. It provides an open route away from proprietary relational database formats and helps keep database content available beyond the life of the original software.
But an application-retirement archive must do more than retain tables.
It must preserve meaning, relationships, readable representations and practical access. It must allow future users to find complete records and understand what they are looking at. It must also retain the controls and evidence needed to govern those records over time.
The question is therefore not simply whether the database has been archived.
The better question is: when someone needs this information in five or ten years, what exactly will they be able to retrieve, understand and prove?
