Keeping History Without Keeping the Old System Alive

Eleven months after the switch, at Greyfriars School, the renewal notice for the old ticketing system lands in Tom's inbox. It has a polite reminder that the subscription continues unless he says otherwise. Tom runs a desk of two. He has not opened the old system since the spring, and he checks the login history to see whether anyone else has. One login, his own, in the spring, to look up a single ticket for the bursar about a laptop warranty. One lookup in eight months, and the school has paid for the whole of it. The old system is still running for one reason, which is that nobody owned the job of switching it off. And it is still running for one feeling, which is "what if". Tom has the notice open on one screen and the new system on the other. He is about to find out how much of "what if" is left.

A ticket archive is the desk's history kept in a form it can read but will never update. And it is the thing that lets the old system be switched off without losing what the old system knew. The migration moved the open tickets and a window of closed ones; everything older is the archive's job. This article is part of our Migrating Ticketing Systems series. It is about building the archive so well that the old system becomes unnecessary, and then noticing when it has.

It covers what the history is for; why the old system stays on anyway; the read-only archive in three shapes. Next come an export that can actually be searched, the question nobody asks after month six, and what the auditor really needs. Then come the day the old system is switched off, a short war story, and the archive decision sheet to copy, in that order.

What the History Is For

The history has three readers, and each reads it less often as time passes. The requester asks "what happened last time", usually within weeks of the last time, and almost never after a year. The technician asks "have we seen this before". That is the question that finds repeat problems and known fixes, and it is answered mostly from the recent past. Finding the Repeat Tickets is about doing it deliberately, and it rarely needs to look back more than a few seasons. The review, the audit or the dispute asks "who approved what, and when". This is the reader who may want a ticket from years ago, rarely, with notice, and usually by number or by name.

Those three readers set the archive's requirements, and the requirements are modest. It must be possible to find a ticket by its old number, by the requester's name or address, and by a date range. It must be possible to read the whole conversation once found, including the internal notes and the attachments. It must be possible to do that in minutes, not days, a few times a month, falling to a few times a year. And it must stay possible for as long as the organisation's retention rules say, which is a date someone can look up. Nothing in that list requires the old system to be running. It requires the data to be somewhere, in a shape someone has tested.

The archive also has a fixed size, which is the fact that makes the whole thing tractable. From the switch onward, if the new system keeps a complete event history on every ticket, as QuerySolv does, the record of the desk's work looks after itself. In that case, the archive is only ever about the time before the switch. That time does not grow. The archive is built once, tested once, and read less each month, which is the opposite of every other system the desk runs.

Why the Old System Stays On

The old system stays on because switching it off is a decision and leaving it on is not. The migration plan had a go-live date and, if it was a good plan, a switch-off date too. But the switch-off date arrives on an ordinary Wednesday with no ceremony. The person who owns it has a queue. The subscription renews by default; the server sits in the rack by default; the login still works by default. Everything about the old system's continued existence is the result of nobody doing anything. Nobody doing anything is the easiest thing in the world to keep doing.

The feeling underneath is "what if", and it is worth taking seriously for exactly as long as it takes to answer it. What if a requester asks about a ticket from three years ago? Then the desk looks it up in the archive, which is what the archive is for. What if the auditor wants a ticket from five years ago? Then the desk produces it from the archive, in the form the auditor accepts, which was confirmed before the old system was switched off. What if the archive is missing something? Then the archive was not tested, and testing it is the fix, not keeping a second system alive to cover for the first. Every "what if" has an answer that is a property of the archive. None of them is answered by the old system still being on.

The cost of leaving it on is larger than the renewal. A running system is patched, or it is a running system that is not patched, which is worse. Its logins still work, including for the technician who left in the summer. It is a second place to search, so searches take twice as long and half the desk only searches one of them. And it is a door. A system that still accepts updates is one mistaken reply away from becoming the second desk that Why Ticket System Migrations Go Wrong describes as the two-systems pattern. A frozen copy of a self-hosted system licensed once per installation, as QuerySolv is, costs the server it sits on and the patching it needs. A frozen subscription costs the subscription. Either way the old system is not free to keep, and it is not keeping anything the archive would not keep better.

The Read-Only Archive in Three Shapes

The archive can take three shapes, and most desks end up with two of them. The first is the old system itself, frozen read-only and left running. The second is an export of everything to files, most usefully a spreadsheet file, with the attachments in folders beside it. Most tools can export tickets to a spreadsheet file. The third is the window of closed tickets that was migrated into the new system. That window already holds the most recent and most-asked-about part of the history. The table sets them side by side on the things that matter. These are what it costs to keep, what it depends on, how well it answers the three readers, and how long it will last.

Read the table and the choice makes itself for most desks. For most desks, that means the export for everything before the window and the new system for the window and onward. In that arrangement, the old system is switched off once the export has been tested. The frozen old system is the shape that feels safest and is the least durable. That is because it depends on a payment and a server that nobody will remember to look after once the desk has moved on. The export feels crude and outlives everything. Files are not glamorous. They are, however, still there.

How wide should the window be? Why is the archive kept out of the new system's working queue rather than imported into it? Those questions belong to What to Migrate and What to Leave Behind. This article assumes the window is settled and the archive's contents are everything older.

An Export That Can Be Searched

An export is only an archive if someone can find things in it. Most exports fail that test on the day they are made because nobody tries. The usable shape is two tables and a folder. The first table has one row per ticket: old number, created, closed, requester name and address, department, category, status, priority, last owner, subject, and the resolution note. The second has one row per message: old ticket number, timestamp, author, whether it was a public reply or an internal note, and the body. The folder holds the attachments, in a subfolder per ticket named by the old number. That is the whole structure, and every question the three readers ask can be answered from it with a filter and a double-click.

Beside the tables goes a readme, one page. It is the part everyone skips and the part that makes the archive usable by anyone other than the person who made it. It says what each column means, in the old system's words and the new system's. It includes the mapping table from the migration so that a reader who knows only the new categories can find the old ones. It says where the attachments are and how they are named. It says who may open the archive, because it holds the same personal information the old system held and inherits the same rules. And it says the retention date, after which the archive is reviewed and, if the policy allows, deleted. A readme is a letter to the stranger who opens the folder in four years, and the stranger is often you. The habit of writing for that reader is the same one Notes for the Stranger teaches for a single ticket. The archive is that habit applied to all of them at once.

Test the export with the three readers' questions, and have someone other than the exporter do it. Find ticket 44871 and read its whole conversation, notes included. Find every ticket a named requester raised in a given year and list the subjects. Find the ticket in which a particular change was approved, knowing only roughly when and by whom, and open its attachment. Each should take under ten minutes with nothing but the files and the readme. If any takes longer, fix the export or the readme, not the tester. Then put the archive on a share that is backed up. Restrict who can read it to the people who could read the old system. Write its location on the decision sheet. The export is not finished when the file exists. It is finished when a stranger has found three things in it.

The archive is also worth one afternoon of mining before it is shelved. The tickets that recur across the years and the fixes that were found and written down nowhere else are all in the export. So are the ten questions the desk has answered a hundred times. The method in Search First, Before Solving works as well on an old archive as on a live queue. An afternoon with the ticket table sorted by subject usually produces half a dozen knowledge base articles that the new system did not have and should. After that, the archive is read only when someone asks. It has already paid for itself.

The Question Nobody Asks After Month Six

Log every lookup in the archive from the day of the switch, and the log will tell you when the old system can go. The log is four columns: date, who looked, what they were looking for, and whether they found it. In the first month there are a handful of entries, mostly requesters asking about recent tickets that turn out to be in the migrated window anyway. In the second and third months there are fewer. By month six the entries are rare and almost all of the review-and-audit kind, by number or by name, with notice. The desk does not have to guess whether the history is still needed. It can count.

The log also catches the one person who still searches the old system out of habit, and it catches them kindly. Suppose the log shows that every lookup was answered from the export or the new system and nobody opened the old system at all. Then the old system has been off in every sense but the electrical one for months. If the log shows one technician opening the old system weekly, ask what for. The answer is usually a saved search or a view that the new system has not yet been set up to match. Build the view in the new system, and the lookups stop. The old system was never the thing they needed. It was where the thing they needed used to live.

The question nobody asks after month six is "can we see the old system", and the silence is the evidence. Write the switch-off date into the plan as a review date rather than a promise, six months after the switch for most desks. On that date read the log. If the last entry that needed the old system is more than two months old, switch it off. If the log is empty because nobody kept it, keep it for two months and then decide. A decision made from a log is one the desk can defend to the bursar, the auditor and the technician who is still fond of the old interface. A decision made from a feeling is an argument.

What the Auditor Actually Needs

Before the old system is switched off, ask the person who owns retention what they would actually request and in what form. Write the answer on the decision sheet. The answer is nearly always specific tickets, identified by date range, requester or subject, produced within a reasonable time, with their conversations and attachments intact. It is nearly never "access to the original system". Auditors and reviewers work from records, and a record is a document they can read. A spreadsheet row with its messages and its attachment folder is a record in every sense they use. Some will want assurance that the export has not been altered since it was made. A dated copy on a backed-up share satisfies that without any ceremony, with its size and a checksum noted on the decision sheet.

Where the organisation is regulated, the retention rule names a period, and the period applies to the records, not to the software. Keep the export for the period, with its readme, and note the date it may be reviewed for deletion. Keep a final backup of the old system's database as well if the policy or the vendor's exit terms ask for it. In that case, label and store it. Understand that it is insurance rather than an archive. Nobody will be able to read it without the old software. It exists so that a question nobody expects can be answered at great effort rather than not at all. The archive is the thing people read. The backup is the thing nobody should ever need to.

Get the retention owner's agreement in writing, in a sentence: the archive in this form, in this place, satisfies the policy, and the old system may be decommissioned. The sentence takes them a minute and saves the desk every future conversation about whether the switch-off was allowed. It also tends to be the moment the retention owner first learns that the old system was still running. That is a conversation worth having before the invoice arrives rather than after.

The Day the Old System Is Switched Off

Switching off is a short checklist and an ordinary afternoon. It is run by the person who owns the switch-off date, with the decision sheet in front of them. The final export is taken, if the one from cutover day is not already the final one, and verified against the counts recorded at the freeze. The archive is tested, again, by someone who did not build it, with the three readers' questions. The lookup log is read and its last entries dated. The retention owner's sentence is on the sheet. The old mailboxes are confirmed stopped or redirected and the old portal link confirmed pointing at the new one. That should have been true since cutover day and is checked anyway. The day the old system goes dark is a bad day to discover that one address was still feeding it.

Then the system is stopped. For a subscription, the cancellation is sent in writing with the date. The vendor's confirmation is kept. Any exit export the vendor offers is taken and stored beside the archive, labelled as what it is. For a self-hosted system, the service is stopped. The server's final backup is taken and labelled with the retention date. The server is retired or repurposed in the ordinary way. Every account on the old system is disabled before it goes, which matters most for the people who have left. The old system's name is removed from the desk's documentation, the intranet and the on-boarding notes. That way, the next technician never learns it existed except as a line on the decision sheet.

Tell the desk in one line and tell nobody else, because nobody else will notice, and that is the measure of a migration that finished. At Greyfriars, Tom's afternoon ended with the cancellation sent. The export was tested by his colleague Aisha against three questions she chose herself. And the decision sheet had a date on the bottom. The bursar's laptop warranty question, when he checked, had been answerable from the migrated window all along. He had opened the old system in the spring out of habit, which was the only reason it had still been on.

A Short War Story: The Renewal Nobody Wanted at Millbrook Transit

Millbrook Transit moved ticketing systems with a plan that had a go-live date and no switch-off date. The old system's subscription renewed twice before anyone looked at it. Nadia, who took over the desk in the second year, found the renewal in the accounts. She asked the four technicians when they had last used the old system. Two had never logged in. One had looked something up "about a year ago". The fourth had been searching it every Monday for a saved report. The new system could have produced that report in five minutes had anyone set it up. Nadia built the export in an afternoon and had the newest technician test it by finding three tickets she named. She set up the Monday report in the new system. Then she cancelled the subscription with a sentence from the finance director on file confirming the archive met the retention policy. The organisation had paid two full years for a system that had answered, by Nadia's count, four questions. Three of those could have been answered by the new system too. Her note on the decision sheet was that a switch-off date is a decision and a renewal is the absence of one. The absence had cost the price of a technician's laptop every month for two years.

The Archive Decision Sheet

The decision sheet is one page, started on cutover day and finished on the day the old system is switched off. And it is the record of every decision in this article. The top block names the archive's shape, location, owner and retention date. The middle blocks record the test, the retention owner's agreement and the lookup log's verdict. The bottom block is the switch-off checklist, with the date and the name of the person who did it. Keep the finished sheet in the archive folder beside the readme. In four years the stranger who opens the folder will want to know why it exists. This is the page that tells them.

ARCHIVE DECISION SHEET — ONE PAGE, FINISHED ON THE DAY THE OLD SYSTEM IS SWITCHED OFF
Migration: ______________________   Switch date: ________   Archive owner: ______________

The archive
  Shape:        [ ] spreadsheet export + attachment folders   [ ] migrated window in new system
                [ ] old system frozen read-only (until ________)   [ ] final database backup (insurance)
  Covers:       tickets closed before ________ (the migration window starts there)
  Location:     ______________________________   backed up: [ ]   read access limited to: ______________
  Contents:     tickets table ______ rows   messages table ______ rows   attachment folders ______
  Readme:       columns explained [ ]   mapping table included [ ]   who may open it [ ]   retention date [ ]
  Retention:    keep until ________   review for deletion by ______________

The test (done by someone who did not build the archive)
  Tester: ______________   Date: ________
  Find one ticket by old number and read the whole conversation, notes included   [ ]  ____ min
  Find every ticket for one requester in one year and list the subjects           [ ]  ____ min
  Find an approval knowing only roughly when and by whom; open its attachment     [ ]  ____ min
  Result: ______________   Fixes made: ______________________________

Retention owner's agreement
  Name: ______________   Role: ______________   Date: ________
  "The archive in this form and place satisfies the retention policy; the old system may be decommissioned."  [ ]

Lookup log verdict (from the log kept since the switch)
  Entries in month 1 ____  month 3 ____  month 6 ____   Last entry that needed the old system: ________
  Old system still opened by: ______________  for: ______________  replaced in new system by: ______________

Switch-off checklist                                                           Done   By      Date
  Final export taken and counts match the freeze counts                        [ ]   ______  ________
  Archive re-tested with the three questions above                             [ ]   ______  ________
  Old mailboxes confirmed stopped or redirected; old portal link redirected    [ ]   ______  ________
  All accounts on the old system disabled                                      [ ]   ______  ________
  Subscription cancelled in writing (confirmation kept) / service stopped      [ ]   ______  ________
  Final backup labelled with retention date and stored                         [ ]   ______  ________
  Old system removed from documentation, intranet and on-boarding notes        [ ]   ______  ________
  Desk told in one line                                                        [ ]   ______  ________

Switched off on ________ by ______________   This sheet filed in the archive folder: [ ]

Tom's sheet at Greyfriars took the afternoon to finish and most of it was already true. The export had existed since cutover day, unlabelled and untested, in a folder called "old tickets". The test by Aisha took forty minutes and found that the attachment folders had been named by a different number than the ticket table used. That was a one-line fix to the readme. The lookup log had one entry. The renewal notice got a reply. The service stopped on the Friday. Nobody at the school has asked about the old system since. Tom regards this as the first migration he has finished rather than merely started.

Frequently Asked Questions