Manufacturing
Making something that will last thirty years
What leaves the plant today will still be in service after you have changed systems four times. The archive has to outlive all of them.
Your product is designed to be running twenty-five or thirty years from now. **Your information systems do not last five.** Over that span you will change document manager two or three times, design supplier at least once, servers several times, and at each of those changes somebody will decide —usually without much thought— what comes along and what stays behind.
How long each thing lasts
| What | How long it lasts | What happens to it |
|---|---|---|
| The product in service | 25-30 years | It keeps generating questions |
| The system holding its archive | 3-7 years | It gets replaced |
| The file format | Variable | It may stop opening |
| **The person who designed it** | **Less** | **Retires or moves on** |
Important
**In this position the archive is not a place where things are stored: it is something that must be actively migrated for decades.** That is a shift in thinking, not a technical matter. A passive archive —«it is on the server»— works while the server exists; afterwards nobody is responsible for it continuing to exist. And there is no warning: the history is lost silently and discovered when somebody looks for it, fifteen years later.
What decides whether the archive arrives alive
- 1
Every migration explicitly including the old material
That is where it is lost. It must be a project task, not a footnote.
- 2
Formats openable without the original software
At least for what must be readable twenty years from now.
- 3
Traceability not tied to one particular system
The link between part, version and document has to travel.
- 4
And keeping what others gave you
Suppliers disappear before the product does.
Watch out
The problem that always arrives and for which there is never an archive is **the obsolete component**. A supplier stops making something inside your product, it has to be substituted, and doing so requires knowing exactly what was there and why it was chosen. That information existed: it is in the design file from twenty years ago. Whether it can be opened decides whether the substitution is an engineering task or a full redesign.
Worth knowing
What technical documentation must be retained, for how many years, under what conditions and what the applicable certification scheme demands **depends on the product and the sector, and is settled by your adviser or the relevant body**. Here we cover the organisational part: how to get an archive alive to a horizon of decades, across several system changes.
›How long must it be kept?
Count from the last unit in service, not from the end of production.
›What format is advisable?
One openable without the program that created it, at least for the essentials.
›And when changing systems?
Make the history an explicit task of the migration project.
A real case
The situation
A component becomes obsolete and what was there must be established.
What you do
- Keeps the design file accessible over the years
What you get
The substitution starts from what was decided then.
The situation
A system change leaves the history behind in the old one.
What you do
- Keeps the archive independent of the system of the day
What you get
The migration does not cut the product's history.
The situation
Questions arrive about a unit made twenty years ago.
What you do
- Stores which version covered each batch
What you get
There is an answer instead of an investigation.
The situation
Documentation from a supplier that no longer exists is missing.
What you do
- Keeps what third parties provided as your own
What you get
The supplier closing does not leave you with nothing.
The situation
Versions overwrite each other in the same folder.
What you do
- Stores each version with its period of validity
What you get
You can say what applied at each moment.
The situation
The designer retires and their knowledge was never written down.
What you do
- Keeps the file independent of individuals
What you get
The departure does not take the explanation.
This article answers
- retaining technical documentation for decades
- obsolete component and its documentation
- asked about a part from twenty years ago
- migrating technical history to another system