Retiring, Merging and Renaming Categories Without Losing History

Kwame is cleaning up the category list at Oakridge Transport on a quiet Thursday. He has reached an entry called "Legacy ERP". The system it refers to was switched off in the spring. The replacement has its own entry. Nobody has filed a ticket under Legacy ERP for four months. He hovers over the delete button. Then he opens last year's annual report. Legacy ERP is the largest single line, fourteen hundred tickets. That number justified the replacement project in the first place. He does not know what the delete button will do to those fourteen hundred tickets. And he does not know what next year's report will say about a line that was the biggest thing on the page and is now simply absent. He closes the settings page. The entry is still there on Friday.

Kwame's hesitation is correct and his problem is real. A category list has to change, because the work changes, systems come and go, and the pruning review removes entries every quarter. But every entry on the list has tickets behind it, and the tickets are the desk's memory. Change the list carelessly and the memory goes with it. Trends break, old reports stop matching new ones, and searches return nothing. And the biggest line on last year's page becomes a mystery. Change it carefully and nothing is lost but a name on a pick list.

Retiring a category is removing it from the list of choices while keeping its tickets countable under a successor. Merging is folding two or more entries into one. Renaming is changing the label without changing what it means. This article is part of our Ticket Categorization & Taxonomy series. It is about doing all three without losing the history behind them. The quarterly review that decides which entries go is in Avoiding the 400-Category Monster. This article starts the morning after, with the list of decisions in hand.

It covers why an entry cannot simply be deleted, and the three operations and what each changes. It explains the deprecated state, and how to get one in a tool that has none. It covers the mapping table from old to new, which is the whole mechanism. It considers whether to re-tag old tickets, and the cost on each side. It covers the change note that keeps next year's report readable, and the cut-over day, in order. It explains why renaming is the dangerous one, and what to tell the team. The category mapping table at the end is built to be copied.

Why You Cannot Just Delete It

Deleting a category entry does one of three things to the tickets filed under it, depending on the tool, and none of them is good. Some tools keep the old value on the tickets as orphaned text. The tickets still say "Legacy ERP" but the entry no longer exists in any list, filter or report. The count is still there if you export, and invisible if you do not. Some tools blank the field, so fourteen hundred tickets become uncategorized in one click and last year's largest line becomes last year's largest hole. And some tools refuse to delete an entry that is in use. That is the kindest of the three and still leaves the entry on the pick list forever. Test yours on an entry with two tickets before touching one with fourteen hundred.

The deeper reason is that reports compare periods, and a comparison needs both periods to be counted the same way. "Business applications" this year against "Legacy ERP" plus "New ERP" plus "ERP (finance)" last year is not a trend. It is two different questions with a line drawn between them. The trend only survives if someone writes down that the three old entries count as the one new entry. That writing-down is the mapping table, which is most of this article. Deleting an entry deletes the chance to write that row.

Search suffers too. A technician looking next year for how the old system's export failures were handled will search the category. That is what the category was for. They will find nothing, because the category is gone. The tickets are there. The handle has been removed. The whole argument for categories in Why Ticket Categories Exist is that they are the structure that survives bad prose. Deleting an entry removes the structure from every ticket that had it. (The prose does not improve to compensate.)

The Three Operations and What Each Changes

Retiring, merging and renaming look similar on the settings page and are different in what they do to the record. So it is worth being precise about each before doing any. The table sets them side by side: what changes on the list, what changes on old tickets, what the report needs, and the risk if it is done carelessly.

Split is in the table because it is the operation the pruning review forgets. When "Software" is found to be half of all tickets and is broken into four entries, the old entry retires. The four new ones start from zero. The trend for all five is broken at the same date. That is unavoidable, and the fix is a note rather than a mapping. "Software, until the cut-over, is the sum of Access: permissions, Warehouse system: export, Warehouse system: other and Business applications: other from the cut-over on." The note lets a report reader add the four new lines together to compare with the old one, which is the best anyone can do.

All four operations share one rule, and it is the rule the whole article rests on. The tickets are never touched by the operation itself. Changing the list changes what new tickets can be filed under. What old tickets say is a separate decision, made on purpose, in its own section below. The default is to leave them exactly as they are.

The Deprecated State

A deprecated category is one that can no longer be chosen for a new ticket. It still exists, still has its tickets, and still appears in reports and searches for the period when it was in use. Deprecation is the state between live and gone, and it is where every retired entry should sit indefinitely. Deprecating instead of deleting costs nothing on the list, because the entry is hidden from the pick list. It saves everything in the record, because the entry is still there to be counted and found.

Some tools have a deprecated state built in, under a name like disabled, hidden, inactive or archived. The entry stays in the database and the reports, and disappears from the choices on the form. Use it. Some tools have no such state, and the entry is either on the list or deleted. For those, the workable substitute is a rename that moves the entry to the bottom of the pick list and marks it. "zz Retired: Legacy ERP" does this. The prefix sorts it last. The word says what it is. The tickets keep a value that is still searchable and still countable. It is ugly, it is honest, and it is reversible, which deletion is not.

A deprecated entry must not be chosen by accident, which is the one risk of the rename trick. A triager scrolling to the bottom of the list will find the retired entries there, and in a hurry may pick one. The defence is the close routine's category check, which catches it, and the monthly read of the report. Any ticket under a retired entry after the cut-over date is a mistake to correct. On a desk that keeps the list short, nobody scrolls to the bottom, and the risk is small.

Deprecated entries are reviewed once a year, not every quarter, and the question is only whether anyone has needed them. Suppose an entry has been deprecated for three years and has not appeared in a report or a search in that time. Its tickets are older than anything the desk compares against. In that case, it can finally be deleted if the tool keeps the old value on the tickets. Otherwise, it can be left alone. Most desks leave them. A hidden entry costs nothing, and the day someone asks about fourteen hundred tickets from the old system is a day you would rather have the handle.

The Mapping Table From Old to New

The mapping table is one row per retired, merged, renamed or split entry, saying what it was, what it became, and from when. It is the mechanism that keeps history readable, and it is the only part of this article that is strictly necessary. A desk that keeps nothing else but a complete mapping table can rebuild any trend across any change. A desk that keeps everything else and no mapping table has a report with unexplained steps in it, forever.

Each row has six things. The old entry's exact name. The operation: retired, merged, renamed or split. The new entry it counts under, or the list of new entries for a split. The effective date, which is always a period boundary. Whether old tickets were re-tagged, yes or no. And a one-line reason, for the person reading this in three years. It is the line most often left blank and most often needed. "Merged: both names meant the same thing" is enough. "Retired: system switched off; successor is New ERP" is enough. The reason is one line because nobody writes two.

The table lives in the taxonomy document, beside the tree and the naming rules, and it is appended to, never edited. A row, once written, is history. If a merge is later reversed, that is a new row, a split, with its own date. The table is therefore a change log as well as a lookup. Reading it top to bottom tells the story of the list. That is the story of how the desk's understanding of its work changed. That story is usually more interesting than the list.

Use the table at report time, every time a period crosses a row's effective date. The report may compare this quarter to last, with a table row dated between them. In that case, the old entry's count from last quarter is added to its successor's count before the comparison. The report then carries a footnote saying so. Most tools cannot do this for you, because the tool does not know that two names mean one thing. The spreadsheet does it in a minute with a lookup column that maps each old name to its successor. The table is what the lookup reads.

Re-tagging Old Tickets, or Not

Re-tagging is going back through the tickets filed under a retired or merged entry and changing their category to the successor. The default answer is no. The mapping table does the same work at report time without touching the record. The record is an audit trail that should say what the desk believed at the time. Re-tagging fourteen hundred tickets by hand is a week nobody has. Where the tool can re-tag in bulk, the week becomes a minute. The question then becomes whether a minute's convenience is worth a record that no longer says what it said.

Three cases justify re-tagging, and they are narrow. One is a pure rename, where the meaning is unchanged and the tool applies the new label to old tickets automatically. There, re-tagging has already happened and the only work is the mapping row that records the old name. Another is a merge of a tiny entry, a dozen tickets or fewer, into a sibling. This is a case where re-tagging takes ten minutes and saves a mapping row that would otherwise be consulted for a dozen tickets forever. And the last is a split of a broad entry where the desk needs the history of one new entry urgently. This could be for a vendor conversation or a budget case. The desk must also be willing to read the notes of the old tickets to assign them. This is work, and it is done once, for the one entry that needs it.

Everything else is left alone, and the cut-over date does the work. Before the date, tickets carry the old entries; after it, the new ones. The mapping table joins them at report time. The record then says, truthfully, that until the cut-over the desk thought of this work as Legacy ERP, and after it as Business applications: retired systems. A reader in three years can see both the work and the change of mind. A re-tagged record says only the second thing, and loses the first.

If re-tagging is done, it is done once, in a block, on the cut-over day. It has a note in each changed ticket where the tool logs field changes. It also has a line in the taxonomy document saying how many tickets were changed and from what. Some tools log a category change in the ticket's history with who made it and when. Some do not. Check yours by changing one ticket and reading its history. If yours does not log it, the only record of the re-tag is the line in the document, and the line matters more than it looks.

Documenting the Change So Next Year's Report Makes Sense

The change note is a dated paragraph in the taxonomy document, written on the cut-over day, saying in plain words what changed and why. It is the human version of the mapping table. The table is for the spreadsheet; the note is for the person. "On the first of the quarter the list went from 412 entries to 53. Nineteen printer-related entries merged into Printing with three children. Legacy ERP retired; its tickets count under Business applications: retired systems. The Software entry split into four; see the mapping table for the sum. Other fell from forty percent to seven the following quarter." Six sentences, and next year's report reader has the whole story.

The note is also where the report's footnotes come from. Every report that crosses a change date carries one line at the foot saying "categories changed on this date; see the taxonomy document". And the line is copied from the note. The footnote is the difference between a report reader who sees a dropped line and thinks "fixed" and one who sees it and thinks "merged". The reading of a report, and why a dropped line is the subtlest failure on the page, is covered in Categories That Make Reports Worth Reading. The note is what makes the footnote possible.

Keep the notes in order, in one place, with the mapping table and the quarterly pruning sheets. Together they are the only history the list has. A desk that has kept them for three years can answer any question about any line on any report in a minute. A desk that has not can answer the same question in an afternoon of reading old tickets, and will usually not bother. And the question will go unanswered, and the report will be trusted a little less. Documentation of this kind is not glamorous. It is the thing that makes the numbers believable, which is the only thing numbers are for.

The Cut-Over Day, in Order

The cut-over happens on a period boundary, the first day of a month or a quarter. That way, every report before it uses the old list and every report after it uses the new one. No period straddles both. The order of operations matters. Adding the new entries before deprecating the old ones means there is never a moment when a ticket has nowhere to go. And the announcement has to arrive before the list changes rather than after. Six steps, in this order, taking about an hour.

• Write the mapping rows and the change note the day before, so the paperwork exists before the change.
• Add every new entry to the list, and check each one appears correctly on the form and in the pick list.
• Tell the team, with the new list on one page and the mapping table beside it, before touching the old entries.
• Deprecate the old entries: hide them where the tool allows, or rename them with the retired prefix where it does not.
• Re-tag only the narrow cases decided in advance, in one block, and record the count in the change note.
• Update the report template with the footnote line, and run the first report under the new list to check that nothing counts under a retired entry.

The check in the last step is the one that catches mistakes. A week after the cut-over, pull the tickets created since the date and look for any under a retired entry. There will be a few, from triagers who scrolled to the bottom. Those mistakes are corrected by hand with a word to the person. A month after, the first monthly report under the new list is read with the change note open. And the lines that stepped are checked against the mapping rows. After that the change is history and the list is simply the list.

Do not do a cut-over on a Friday, during a migration weekend, or in the same week as any other change to the tool. If the first report looks wrong you will want to know it was the categories and not something else. One change, one boundary, one footnote. I once retired eleven entries on the same day a colleague changed the priority definitions. The following month's report was unreadable for reasons neither of us could separate. We learned to take turns.

Renaming Is the Dangerous One

Renaming looks like the safest of the operations, because nothing is removed, and it is the one that breaks the most things quietly. The entry's meaning is the same. But its name is what everything else refers to. That includes saved filters and views that select by category, and searches technicians have bookmarked. It includes knowledge articles that say "file this under Printing", the report template's row labels, and the triagers' own memory of the list. Every one of those still says the old name after the rename, and every one of them silently stops matching. Nothing errors. Things just return less than they did.

Rename only when the old name breaks a naming rule badly enough to cause misfiling, and never for taste. "Printers" becoming "Printing" because the rules say nouns for the activity is a rename for taste. The cost is every saved view that says Printers. "Perms" becoming "Access: permissions" because new technicians could not find it is a rename for cause, and the cost is worth paying. The test is whether the old name was producing wrong categories or merely untidy ones. Untidy stays.

When a rename is done, the old name goes into the definition line of the entry in the taxonomy document, in brackets, permanently. "Access: permissions (formerly Perms)" is an example. A search for the old name in the document then finds the new one, and a technician who remembers the old name can find where it went. The mapping row is written as for any other change, with the operation marked as a rename. And the saved views and knowledge articles are found and updated the same day. That is a search for the old name across everything the desk keeps. Some tools apply the new label to old tickets automatically and some only to new ones. Find out which yours does on a test entry, because it decides whether the old name needs a mapping row for reports or only for people.

Telling the Team, and the Requesters If They Choose

The team is told before the change, in two sentences and one page. The sentences are: "The list is shorter from the first of the month; here is where the entries you used to pick now live." The page is the new tree with the mapping table underneath it. Technicians adapt to a shorter list within a week, because a shorter list is easier. The only questions are about where particular old entries went, which the mapping table answers. A five-minute walk-through at the team meeting, with the page on the screen, covers it.

Requesters are told only if they choose a category on the form, and then only the top level, in plain words, on the form itself. Most requesters never notice a category list changing, because they see it once a quarter and did not know what the entries meant the first time. If the tool routes by department and requesters pick only that, nothing needs saying at all. That is one more reason to keep the fine category on the desk's side of the form, where the desk can change it without an announcement.

The one group that does need telling individually is anyone outside the desk who reads the reports. This includes the manager who gets the monthly page and the finance person who used the Legacy ERP count in a budget case. It includes the vendor who was shown a category count at a renewal. Each gets one sentence, with the mapping, before the next report they receive. That way, the dropped line arrives with its explanation rather than ahead of it. A report reader who finds out about a merge from the report has learned not to trust the report. A report reader told the week before has learned that the desk keeps its records straight, which is a thing worth being known for.

A Short War Story: The Legacy System at Redbrook Engineering

Redbrook Engineering's desk of four retired its old design-management system over a summer. The category list was tidied the following quarter. The "Design system (old)" entry had about nine hundred tickets behind it over three years. A well-meaning technician deleted it from the list, assuming the tool would keep the value on the tickets. It did not. The tool blanked the field, and nine hundred tickets became uncategorized overnight. Elena, who ran the desk, found out four months later. The engineering director asked for the old system's failure history to settle a dispute with the vendor over final-year support charges. The category that would have answered the question in a minute returned nothing. Elena spent three evenings re-tagging the nine hundred tickets from their subject lines and notes. She got to about seven hundred with confidence and presented a count with a caveat that the vendor's lawyers enjoyed more than she did. The dispute was settled at a figure she described as "about the cost of a deprecated flag". The lesson she wrote into the taxonomy document was two lines. Nothing is deleted from the list, ever. And the first thing to test in any tool is what a removed entry does to the tickets that had it.

The Category Mapping Table

The table is the mechanism. One row per entry that leaves or changes, appended on the cut-over day, never edited afterwards. Keep it in the taxonomy document under the tree. And keep a copy as a two-column sheet in the reporting spreadsheet, old name and new name. That way, a lookup can translate an export in one step. The example rows show the four operations; replace them with your own and keep adding.

The change note that accompanies the table is a dated paragraph, and the shape below is enough. Write it on the cut-over day. File it under the table, and copy its first line into the footnote of every report that crosses the date.

TAXONOMY CHANGE NOTE
Date: ______________   Owner: ______________   Pruning sheet reference: ______

What changed
  Entries before: ____   Entries after: ____
  Retired: __________________________________________________
  Merged:  __________________________________________________
  Renamed: __________________________________________________
  Split:   __________________________________________________

Why (one line each; the quarterly sheet has the numbers)
  ___________________________________________________________

Old tickets
  Re-tagged: [ ] none   [ ] ____ tickets, from ______ to ______ (logged in each ticket: [ ] yes [ ] note only)

Reports
  Footnote added to the report template: [ ] yes
  First report under the new list checked against this note: [ ] yes, on ______

Told
  Team: ______   Report readers outside the desk: ______   Requesters: [ ] n/a  [ ] form updated

Kwame's Legacy ERP entry at Oakridge Transport is a retirement. The row is one line: Legacy ERP, retired, counts under Business applications: retired systems, from the first of the quarter, not re-tagged, system switched off. The entry is hidden from the pick list. The fourteen hundred tickets keep their value. Last year's largest line still adds up. Next year's report carries a footnote that says where it went. The delete button stays where it is. It has never once been the right button, and it is not about to start.

Frequently Asked Questions