What to Migrate and What to Leave Behind

Thursday, 11:10, at Harbourview Clinic. Ruth, the practice manager, leans into the IT room on her way to somewhere else. "We're keeping everything, aren't we? The auditors will want it." Marcus, who runs the desk of three, says yes before he has thought about it. He then spends lunch thinking about it. Everything is 61,400 tickets going back nine years, of which 38 are open and about 600 were closed in the last three months. Everything is 340 knowledge base articles. Of those, 90 were about a patient-records system the clinic retired long ago, with screenshots of a tool nobody will see again. Everything is 46 canned replies, half of them signed by people who have left. Everything is nine years of attachments, including, he discovers, a 400-megabyte video of a printer making a noise. Marcus has promised to keep it all. He has not yet decided what "keep" means.

Choosing what to migrate is making a decision for every kind of data the old system holds. Does it move into the new system or stay behind in a form the desk can still read? Does it get rebuilt from scratch for the new tool, or is it let go? Those are four different fates, and "keep everything" collapses them into one. This article is part of our Migrating Ticketing Systems series. And it is about making that choice deliberately, data type by data type, before the export runs.

It covers the principle that not everything deserves the trip. Next come open tickets, which always go, and recent closed tickets, which usually go. Then come the old archive, which stays behind read-only, and the knowledge base, which is rewritten rather than copied. It covers templates, rules and reports, which are rebuilt. Then come requesters, departments and addresses, which are the address book. The keep-or-leave decision table, a short war story, and the data inventory to copy follow, in that order.

Not Everything Deserves the Trip

The question to ask of every kind of data is who will open it in the new system, and when. If the answer is "a technician, tomorrow, to do work", it migrates. If the answer is "someone, eventually, to look something up", it is archived where it can be found without the old system. If the answer is "the desk, daily, but it was written for the old tool", it is rebuilt. If nobody can name a person or a moment, it is dropped, and the sky stays where it is. Four fates, one question, applied to each row of the inventory at the end of this page.

The reason to be strict is that everything moved into the new system has a cost that lasts. Every migrated ticket is a search result, forever, competing with current work. Every copied article is a page a requester might land on, with a screenshot of a tool they have never seen. Every old template is a reply a new technician might send. The import takes a morning; living with what it imported takes years. "Keep everything" is cheap on the day and expensive every day after, which is the wrong way round for a decision made by tired people.

The reason not to be too strict is that the desk's history is the desk's memory, and a desk with no memory repeats itself. The answer is not to migrate less. It is to migrate what the desk will act on and archive what it might read. It is also to make the archive good enough that nobody misses the old system. The three uses of the archive, and how to keep it alive without the tool it came from, are in Keeping History Without Keeping the Old System Alive. This article decides what goes into it.

Open Tickets: Always, and Completely

Every open ticket migrates, with its whole conversation, its requester, its owner, its dates and its status mapped to the nearest new one. There is no version of a migration in which the desk tells a requester the problem they raised last week has been lost in the move. They did not ask for the move. Open means anything not resolved or closed. That includes the tickets waiting on a requester and the tickets waiting on a supplier. It also includes the one that has been on hold since the spring that everybody has agreed not to mention.

Completely means the parts a quick export drops. The attachments on open tickets, because the screenshot of the error is the ticket. The internal notes, because the note saying "do not reboot this one, finance month-end" is the only thing standing between a new technician and a bad afternoon. The supplier reference numbers on anything waiting on a vendor, because the vendor will ask for them and the old system will be gone. This also means the original dates. An open ticket that appears to have been created on cutover day has no age. A ticket with no age is a ticket the backlog report cannot see.

The count of open tickets is the first number on the cutover runbook, because it is the one you can verify to the ticket. Thirty-eight out of the old system should mean thirty-eight into the new one, each with a conversation. The check is to open all thirty-eight, not a sample. Anything raised between the export and the switch is the one gap, and closing it is a matter of freezing the old system first. The mechanics are in The Cutover Plan, and Why It Should Be a Tuesday. Thirty-eight tickets is an hour's reading. It is the best hour of the migration.

Recent Closed Tickets: Usually

Recently closed tickets usually migrate, and the question is how far back "recent" goes. Three things want them in the new system. Requesters reply to closed tickets, often weeks after the close, with "it's doing it again". A technician will say "this is the same as the one we fixed for finance last month" and want to open it. And the first reports out of the new system need the previous months beside them. Otherwise, the first month's numbers are a single dot with nothing to compare to. Each of those uses has a horizon, and the longest horizon sets the window.

The reopen horizon is the one most desks underestimate. In many systems, QuerySolv among them, a requester's reply to a resolved ticket reopens it, with the whole history attached. A reply to a ticket that never made the trip reopens nothing. It arrives as a new ticket beginning "as I said in my last e-mail". The technician has no last e-mail to read. The requester explains the problem a second time to a desk that looks as if it was not listening. Look at your own closed tickets: how long after the close do replies still arrive? For most desks it is a few weeks with a long tail. The window should cover the body of that tail.

The report horizon is usually longer, and it is a judgement about what the desk will be asked. If management sees a quarterly report, the new system needs at least the previous quarter so the first quarterly chart has two bars. If the desk compares against the same month last year, that is a year. A year of closed tickets is a different size of import. Many desks settle on a season. That is long enough to catch the reopens and give the first reports a neighbour. It is short enough that the import is a morning rather than a weekend. Choose the window with a reason you can say in a sentence. Write the sentence in the inventory, and expect to defend it once to someone who wanted everything.

Whatever the window, the closed tickets that migrate come with the same completeness as the open ones: conversation, notes, attachments, dates, old number. A closed ticket without its resolution note is a title and a date, and the resolution note is the part the technician wanted. Half a ticket is not a smaller ticket. It is a reason to open the old system, which is the thing the whole migration is trying to avoid.

The Old Archive: Read-Only, and Somewhere Else

Everything closed before the window becomes the archive: history the desk can read but will never update. It is kept somewhere the desk can reach without the old system running. The archive is not a smaller migration. It is a different thing, with different rules. Nobody writes to it. Nobody works from it. Its only job is to answer "what happened with ticket 44871" in under ten minutes, a few times a month, for as long as the retention policy says.

The archive stays out of the new system for the reason given earlier: everything in the new system is a search result forever. Suppose the working queue contains nine years of closed tickets. Then a technician searching for the clinic's current printer problem gets the printer problems of a decade first, each as real-looking as the last. The old system's own search was probably poor at this too, which is one of the reasons the desk is leaving it. Do not import the problem along with the data.

What the archive looks like is a decision with its own article. It might be a frozen copy of the old system or a spreadsheet export with one row per ticket and one per message. Or it might be something in between. The short version is that most tools can export tickets to a spreadsheet file. A spreadsheet file that someone has tested a search on will outlive any software. For this article, the decision is only that the archive exists, that somebody owns it, and that its contents are the closed tickets older than the window. Write all three on the inventory. An archive with no owner is a folder nobody can find.

The Knowledge Base: Rewrite, Don't Copy

The knowledge base is rewritten for the new system, not copied into it. And this is the decision that meets the most resistance, because the articles took years to write and copying them looks free. It is not free. Articles about the old ticketing tool are now wrong. Articles with screenshots of the old portal now confuse the people they were meant to help. Articles about retired systems, which were tolerated as clutter in the old tool, become a first impression in the new one. And the structure of a knowledge base is shaped by the tool it lives in. The categories, the audience split, the way articles attach to tickets all differ. So a copied article lands in a structure it was not written for. Marcus's 340 articles were, on inspection, about 120 that anyone had opened this year. The other 220 were well-preserved.

The method is to let usage choose. Pull the list of articles sorted by how often they were viewed or attached to tickets in the last year. Rewrite from the top. The first twenty cover most of what the desk actually hands out, and rewriting twenty articles is a fortnight of odd hours, not a project. Each rewrite is a chance to run the health check in A Knowledge Base Health Check: is this still true, is it still followable, does it have a name on it? Articles below the cut are not deleted. They go into the archive beside the old tickets, where a technician who remembers one can find it.

The rewrite is also the moment to settle each article's audience. The new system may distinguish articles visible to agents only from articles visible to everyone, as QuerySolv does. In that case, every rewritten article gets a conscious answer to "who is this for" rather than inheriting whatever the old tool's default was. Most knowledge bases carry a few articles that were meant for technicians and have been readable by every requester for years. These are usually the ones with the admin password in step four. A migration is a polite way to find them.

Templates, Rules and Reports: Rebuild From the Work

Canned replies are rebuilt the same way as the knowledge base. Pull the usage and keep the ones that were sent. Rewrite them in the new system's voice and with the new system's placeholders, and let the rest go. A template signed by someone who left is a template nobody has read since they left. The twenty a desk really needs, and how to write them so they do not sound canned, are in The Twenty Templates Every Desk Needs. The migration is the moment to build that twenty and no more. Forty-six templates, half of them variations on "we are looking into it", is not a library. It is sediment.

Routing rules and automations are written down in plain words before anything is rebuilt. That is because the old system's rules were almost certainly never documented. Some of them are doing things nobody remembers asking for. "Mail to facilities@ goes to the facilities queue" is worth keeping. "Any ticket containing the word urgent is set to the top priority" was added for one director and has been promoting lunch orders ever since. List what each rule does and who relies on it. Then rebuild only the ones with a name beside them, using whatever the new system offers. Routing by department, form and mailbox is the usual skeleton, and how to set it up without it misfiring is in Routing by Department, Form and Mailbox.

Reports are not migrated at all; their numbers are. Before the old system is frozen, run its standard reports for the last twelve months, by month, and save them as files. Include volume in and out, backlog by age, response and resolution times, reopen rate, whatever the desk actually looks at. These are the baseline the new system's first reports will be compared against. Once the old system is off there is no second chance to produce them. Saved report files are small, boring and the single most-requested item from an old system six months after it is gone.

Requesters, Departments and Addresses

The address book migrates, and it is easy to forget because it does not feel like data. Requesters are identified in most tools by their e-mail address. The address is what ties a migrated ticket to the person who raised it. If the import creates requesters from the tickets, the shared mailboxes come across as people. That is how "bursary-team" ends up with a first name. Departments map one to one where they match and are decided where they do not. Technician accounts are created fresh, with the permissions written down rather than copied. The old system's permissions were set by whoever was there at the time and have been inherited since.

The intake addresses are the part of the address book that cannot be wrong. List every address a requester has ever written to. Include the main one, the department ones, and the one printed on the sticker on the printers. Include the one in the staff handbook from three reorganisations ago. Each either moves to feed the new system or redirects into one that does. And each gets a line on the inventory with the decision beside it. An address that is missed keeps working, feeds the old system, and starts the two-systems problem on day one. Addresses are patient. They will wait years for someone to notice.

Service levels, business hours and the holiday calendar are configuration rather than data. They are rebuilt from the written policy rather than from the old system's settings. That is because the settings and the policy have usually drifted apart. If the desk promises a response time per priority, the promise is in a document somewhere. In that case, set the new system to that document and note where the old settings differed. The drift is often the explanation for a report that never quite matched the policy, which is a small mystery solved for free.

The Keep-or-Leave Decision Table

The table gives the default fate for each kind of data, the reason, and the question that would change the default. Defaults are not rules. A desk under a strict retention regime may need every ticket in a searchable archive. A desk with a two-year-old knowledge base that is actually good may copy more than it rewrites. Use the table as the starting position and write down every departure from it.

Read the right-hand column honestly. Five of the eleven rows say "nothing", and they are the rows where the default is the rule. The other six are where the argument with Ruth should be had, politely and before the export, with the inventory on the table between you.

A Short War Story: Nine Years of Everything at Ashgrove Housing

Ashgrove Housing's desk lead, Lena, took "keep everything" literally. She migrated nine years of tickets, every attachment and all 410 knowledge base articles into the new system in one go. It took place over a weekend she had budgeted as a morning. The import took most of three days. During that time, the desk ran on paper and the old system in parallel. When the new system opened, every search for a current problem returned a decade of similar ones first. So technicians stopped searching and started asking each other. Tenants who used the new portal found articles with screenshots of a tool they had never seen. They also found a dozen pages about a heating controller the housing association no longer installed. The desk spent six months answering "ignore the old articles" before someone finally hid them. When the auditors did come, they asked for eleven specific tickets, all from the last two years, which the window would have covered. Lena's note for the next migration said she had spent three days and six months moving things nobody opened. That was to protect against a question nobody asked. The note said the archive she eventually built from a spreadsheet export did the job in an afternoon.

The Data Inventory

The inventory is one page per migration, filled in before the cutover date is agreed, with a row for every kind of data the old system holds. Each row gets a count, a location, a fate from the four, a one-line reason, an owner and a tick when the fate has been carried out. The counts matter more than they look: the number of open tickets is what the cutover verification checks against. And the number of intake addresses is the list that must reach zero missed. Fill in the counts from the old system while it is still running. That is because the moment it is frozen the counts are the only evidence of what it held.

DATA INVENTORY — ONE PAGE PER MIGRATION
Migration: ______________________   Owner: ______________   Filled in: ________
Window for closed tickets: from ________ to the freeze   Reason: __________________

Fates:  M = migrate into the new system    A = archive, read-only, outside it
        R = rebuild for the new system     D = drop (nobody and no moment named)

Data                          Count    Where it is now        Fate  Reason (one line)        Owner   Done
Open tickets                  ______   ____________________    M    requesters are waiting   ______  [ ]
Closed tickets in the window  ______   ____________________    M    ________________________ ______  [ ]
Closed tickets before window  ______   ____________________    A    ________________________ ______  [ ]
Attachments (open + window)   ______   ____________________    M    follow their ticket      ______  [ ]
Attachments (archive)         ______   ____________________    A    ________________________ ______  [ ]
Knowledge base, used articles ______   ____________________    R    ________________________ ______  [ ]
Knowledge base, the rest      ______   ____________________    A    ________________________ ______  [ ]
Canned replies                ______   ____________________    R    ________________________ ______  [ ]
Routing rules / automations   ______   ____________________    R    ________________________ ______  [ ]
Reports (12 months, by month) ______   ____________________    A    saved as files           ______  [ ]
Requesters                    ______   ____________________    M    keyed by e-mail address  ______  [ ]
Departments / groups          ______   ____________________    M    ________________________ ______  [ ]
Technician accounts           ______   ____________________    R    permissions written down ______  [ ]
Intake addresses              ______   ____________________    M    every one moved/redirect ______  [ ]
Service levels and hours      ______   ____________________    R    from the written policy  ______  [ ]
Other: ______________________ ______   ____________________    _    ________________________ ______  [ ]

Departures from the defaults, and who agreed them
  ______________________________________________  agreed by ______________ on ________
  ______________________________________________  agreed by ______________ on ________

Archive owner: ______________   Archive location: ______________________
Signed off before cutover by: ______________ on ________

Marcus took the inventory to Ruth the following Monday with the counts filled in. The conversation was shorter than he had feared. The 38 open tickets and the season of closed ones would move. The nine years would sit in a read-only archive with his name on it. Ruth said that was what she had meant by "keeping everything" all along. The 220 unopened articles went to the archive too. The 120 that were used were rewritten over the following month. And the printer video, after some discussion, was let go. Nobody has asked for it. The printer has been quiet.

Frequently Asked Questions