---
id: KB-IU-031
url: https://app.codecontract.io/help/manufacturing/making-something-that-will-last-thirty-years
idioma: en
categoria: sector-industria
subcategoria: ferroviaria
audiencia: usuario
nivel: avanzado
actualizado: 2026-08-13
tambienEn: [es]
relacionados: [KB-IU-022, KB-IU-006]
citadoPor: [KB-IU-020]
---

# 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._

**Responde a:** retaining technical documentation for decades · obsolete component and its documentation · asked about a part from twenty years ago · migrating technical history to another system

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.

> [!WARNING]
> 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.

> [!NOTE]
> 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.

## Ejemplos

**A component becomes obsolete and what was there must be established.**

- Keeps the design file accessible over the years

→ The substitution starts from what was decided then.

**A system change leaves the history behind in the old one.**

- Keeps the archive independent of the system of the day

→ The migration does not cut the product's history.

**Questions arrive about a unit made twenty years ago.**

- Stores which version covered each batch

→ There is an answer instead of an investigation.

**Documentation from a supplier that no longer exists is missing.**

- Keeps what third parties provided as your own

→ The supplier closing does not leave you with nothing.

**Versions overwrite each other in the same folder.**

- Stores each version with its period of validity

→ You can say what applied at each moment.

**The designer retires and their knowledge was never written down.**

- Keeps the file independent of individuals

→ The departure does not take the explanation.