Data retention, explained without the jargon

It comes up on almost every project, usually later than it should. Here is data retention without the vocabulary that usually surrounds it.

Numbers get quoted in meetings long after anyone remembers how they were calculated. Write the reasoning down alongside the decision, because the reasoning is what changes first.

The short version

Keeping everything forever is a liability, not an asset. Where this goes wrong is almost never a lack of knowledge. Budget a little time for it every quarter and it never becomes a project of its own.

Why people complicate it

Most of the confusion comes from tooling rather than from the idea itself. The teams that handle this well are rarely the ones with the biggest budgets.

Retention rules should be written down and enforced automatically. The teams that handle this well are rarely the ones with the biggest budgets. Doing this properly once is usually cheaper than doing it approximately three times.

A reasonable first step

Deletion has to work across backups too. There is a version of this that is over-engineered, and it is worth avoiding. Most teams find the first pass takes an afternoon and the maintenance takes minutes a month.

The short version

Data outlives the applications built on top of it, which is why the model deserves more thought than the screens. Three things worth confirming about data retention before you move on:

• Someone can say what the current setup is without going to look
• Keeping everything forever is a liability, not an asset — and you know whether that is true here
• There is a way to tell whether the last change to this helped

If you want a second opinion on how yours is set up, ask.