Renaming Without Breaking History

Renaming looks harmless and is the operation most likely to make a long record unusable. There are three ways to do it and only one preserves the history.

When this principle needs to support project or client work, refer to this supporting resource. It can help test whether the log preserves enough context without turning capture into a separate task.

The three approaches

Rename in place, everywhere. The old entries now carry the new label. History looks seamless and is wrong: entries from 2022 are described by a definition that did not exist then.

A related source worth keeping beside this note is Google Calendar, particularly for decisions involving calendar records.

Rename going forward only. Two labels for what you think of as one thing. Honest, and it fragments the series.

Rename with a mapping, dated. A note recording that A became B on a given date, with both preserved in the data. This is the one that works.

The mapping file

One line per change: old name, new name, date, reason.

Kept beside the data, alongside the definitions.

Any analysis can then choose: treat them as one series after applying the mapping, or as two, depending on the question.

Without it, only one of those is possible and you cannot tell which is correct.

When the change is cosmetic

"Admin" becoming "Administration", same meaning.

Rename in place. Record it anyway, in one line, so a future reader is not puzzled by data that changes label mid-file.

When the change is substantive

A category splitting into two, or two merging.

Never rename in place. The old data cannot be split retroactively without invention: you do not know which 2022 admin entries were invoicing.

Record the split with its date and accept that the earlier period has coarser granularity. That is a true statement about your record and it is fine.

Merging

Easier than splitting, because combining is lossless.

Keep both labels in the stored data and merge at analysis time rather than in the file.

A merge performed in the data destroys the ability to separate them later; a merge performed in the query does not.

This is the general principle: transform at read time, not at write time.

Practical mechanics

If your tool supports aliases or a mapping table, use it.

If not, a two-column file — old label, canonical label — that your analysis applies is enough, and it is the sort of thing that takes ten minutes to set up and works for a decade.

What to avoid entirely

Editing years of past entries in bulk. The chance of error is high, the change is unlogged unless you record it, and the original is usually unrecoverable.

If you must, copy the file first, and keep the copy permanently.

What to check

Have you renamed anything without recording it?

Do you have a mapping file, or only your memory of what changed?

Would an analysis spanning the rename produce a correct total?

And is your original data intact, or has it been edited in bulk at some point?

The point

Transform at read time, not at write time.

A merge performed in the data destroys the ability to separate later; a merge performed in the query does not.

Worth adding

Never edit years of entries in bulk.

The chance of error is high, the change is unlogged unless recorded, and the original is usually unrecoverable.

Additionally

Keep a mapping file: old name, new name, date, reason.

Any analysis can then choose whether to treat the series as one or two, which is impossible without it.

Finally

Splitting a category cannot be done retroactively without invention: you do not know which past entries belonged where.

Record the split date and accept coarser early data.

In summary

Three ways to rename: in place, going forward only, or with a dated mapping.

Only the third preserves the ability to compare the years either side.

Last word

The practice this points at is unglamorous: a small daily act, a short weekly correction, an annual read, and a written page of conventions beside the data. None of it is difficult and all of it is easy to skip, which is why most records do not reach the point where they start paying.