Why Ticket System Migrations Go Wrong: The Five Patterns

Monday, 08:40, at Meridian Parts. Dana opens the new system for its first real morning. The switch happened on Saturday, and the import ran clean: 1,912 tickets in, 1,912 tickets out. It was a tidy number she had been pleased with over the weekend. The first thing she notices is that all 1,912 of them were created on Saturday at 14:10. The warehouse scanner ticket Raj raised three weeks ago now looks two days old, and so does everything else. That makes the backlog report the best the desk has ever produced and entirely false. At 09:15 Raj replies to that ticket from his phone. The reply goes to the old address, lands in the old system, and sits there, because nobody is watching the old system any more. At 09:30 Dana finds what happened to the categories: 214 of them, pressed into one text field called "legacy_category" that nothing can filter on. By 10:00 the old system is open on her second monitor, "just to check something". It will stay there until spring.

A ticket system migration is the move from one help desk tool to another, and it carries far more than tickets. It carries the open work, the history, the categories and statuses, and the knowledge base. It also carries the addresses people write to and the habits of everyone who touches the desk. None of that is in the export file. This article is part of our Migrating Ticketing Systems series. The series treats the move as the project it is rather than the weekend it is usually planned as.

It covers why migrations fail quietly rather than loudly. Then we cover the five failure patterns in turn. We start with the history that did not make the trip and the categories that became one field. Next come users retrained by e-mail, two systems for a year, and the brave weekend. We cover the early sign of each, visible before the switch or in its first week, then the early-sign table. We finish with a short war story and the migration risk list to copy, in that order.

Migrations Fail Quietly, Weeks Later

A migration almost never fails on the day. The import runs, the new system opens, the first e-mail arrives and becomes a ticket, and everyone goes home. The failure is found three weeks later, when a requester asks about a ticket that no longer exists anywhere a technician looks. Or it is found six weeks later, when a manager asks for the quarterly report. The new system cannot produce it because the categories arrived as text. By then nobody remembers which decision caused it, because the decision was never made out loud. It was made by the import, on a Saturday, by default.

The reason is that a migration gets treated as a technical task when it is mostly a project about meaning. The technical part is genuinely small. Most tools can export tickets to a spreadsheet file, and the file is a file. What the file cannot carry is what each column meant or which address each department wrote to. It cannot carry what "Pending" meant on the old desk as against the new one. Nor can it carry what a technician is supposed to do at nine on Monday. Those are decisions. A decision nobody makes is still made; it is made by whoever wrote the import, and they were not in the room.

The five patterns below are the ones I have seen most often, and two of them I have personally caused. Each has an early sign, something you can check before the cutover or in its first week. That is when the fix is an afternoon rather than a year. The patterns feed each other, which is why a desk rarely has just one. Lost history makes the old system indispensable, which keeps it alive, which splits the record, which makes the history worse. Migrations do not fail once. They fail in a loop.

Pattern One: The History That Did Not Make the Trip

The lost-history pattern is a new system that holds tickets without what made them tickets. Sometimes the conversations are missing and only the first message arrived. Sometimes every date was set to the day of the import, so the desk has no idea what is old. Sometimes the ticket numbers changed and nobody kept the old ones, so the number in the requester's e-mail signature finds nothing. And sometimes the history simply did not come, because somebody said "let's start fresh" and everyone was too tired to argue.

It happens because the history is the heaviest thing to move and the easiest to declare optional. The person planning the move has not needed a three-year-old ticket this month, so they decide nobody will. The requester who will need it next month has not been asked. And the auditor who will need it next year is not on the mailing list. "Start fresh" sounds like a decision. It is the absence of one, said confidently.

The cost arrives through the three uses of history. The article Keeping History Without Keeping the Old System Alive takes them in turn. There is the requester asking what happened last time and the technician asking whether the desk has seen this before. There is also the review asking who approved what. Each is a question the desk could answer last month and cannot answer now. There is a quieter cost too. A ticket whose creation date is the migration day has no age. And a backlog with no ages is a backlog that cannot be read. So the first month in the new system produces reports that are accurate about nothing. If the new system keeps a complete event history on every ticket, as QuerySolv does, the record from the switch onward looks after itself. The migration decides only what the record looks like for the time before, and that decision is the whole of this pattern.

The early sign is a test import of fifty real tickets, opened and read, before the plan is approved. Pick an old one, a long one with ten replies, one with an attachment, one that was reopened. Does each have its messages, its original dates, and its old number somewhere a search will find? If the fifty have not been imported and opened, that is itself the sign, and it is the loudest one on this page.

Pattern Two: The Categories That Became One Field

The mangled-categories pattern is a new system in which the old categories mean nothing. The commonest form is Dana's: every old value pressed into a single text field that nothing can group by. The second form is a new tool with fifteen clean categories and every migrated ticket sitting in "Other", because the import had to put them somewhere. The third form is a mapping done at speed by one person guessing. The result is that "Printer, Floor 2" became "Hardware" and "Printing" became "Software" and nobody can say why.

It happens because mapping is boring and nobody owns it. The old category list grew for years without a decision, the way category lists do. The history of that growth is in Avoiding the 400-Category Monster. A migration is the one moment the desk has to escape it. Instead the list is handed to the import as it stands. The import wants one new value for each old one, and the person running it at eleven at night picks something. Categories do not survive a migration on their own. They have to be carried, one at a time, by someone who knows what they meant.

The cost is that every report breaks at the boundary. The desk can say what happened before the switch and what happened after, in two different vocabularies, and cannot put the two on one chart. The first quarterly report out of the new system has one tall bar labelled "Other" and a footnote. Managers, who had just been told the new system would improve reporting, are patient about this for roughly one meeting.

The early sign is the absence of a mapping table. That is a document with one row for every old category, status and field value. Beside each is the new value and the name of the person who agreed it. No table, no mapping, whatever the project plan says. The second sign is in the test import: if more than a tenth of the fifty tickets landed in "Other", the map is a bucket. How to build the table, and what to do with the values that have no home, is in Remapping Categories, Statuses and Fields.

Pattern Three: Users Retrained by E-mail

The badly-retrained pattern is an all-staff e-mail on Friday afternoon saying "from Monday, please use the new portal". It is followed by a Monday on which nobody does. People write to the old address, because it is in their sent folder and their muscle memory. People phone the technician they phoned last time. People walk up. The old address, depending on how the switch was done, bounces or forwards into a mailbox nobody reads. Or it keeps working and feeds the old system. That is how the old system gets its first new ticket after the switch.

It happens because training is assumed to be about the tool, and the tool is assumed to be the hard part. Neither is true for requesters. A requester has to learn three things. They need to know where to write and what the new acknowledgment looks like so they do not think it is spam. They also need to know what happened to the ticket they already had open. That is a page, not a course. The course, when one is offered, is attended by the people who would have worked it out anyway. That is a pattern that holds for most training and all fire drills.

The technicians need more than a page, but not much more. They need a week at the desk with someone who has used the new system. They need a list of the old words and the new words. And they need a daily ten minutes where "how do I" questions get answered before they become habits. The mailboxes matter here as much as the people. In a system where every department has its own mailbox, as QuerySolv does, the list of addresses to redirect is the list of departments. That list is short, and it should be written down before the switch rather than discovered after it. The whole of this is in Retraining Users and Technicians Without a Course.

The early sign is where the mail goes in week one. If the old address receives more messages than the new one on Wednesday, the retraining did not happen, however many people were on the distribution list. Before the switch, the sign is simpler: ask ten people how they would contact IT tomorrow. If fewer than seven name the new route, the one-page what-changed has not reached them, or has not been written.

Pattern Four: Two Systems for a Year

The two-systems pattern is the old system that was kept on "for reference" and is still being used for work. A month after the switch, two technicians are still closing tickets in it, because the tickets they were working on were there. Requesters reply to old threads, which land in the old mailbox, which still feeds it. Someone searches it every morning. The renewal comes round and is paid, because switching it off would lose something, though nobody can say what. The desk now has two queues, two sets of reports, and one set of people.

It happens because the plan ended at go-live. There was a date for the new system to start and no date for the old system to stop. And a system with no stop date runs forever. Fear does the rest: nobody wants to be the person who switched off the thing that held the answer. The old system is kept alive the way a spare key is kept in a drawer. But the spare key does not bill you, accept new mail, or let a colleague file a ticket in it by mistake.

The cost is double work and a split record, and the split record is the worse of the two. For as long as both systems accept updates, neither holds the truth. So every question about the desk's year needs two reports and an argument about overlap. The money is real too, a second subscription or a second server kept patched, but it is the smaller cost. The larger one is that the desk cannot say what it did.

The early sign, before the switch, is a plan with a go-live date and no switch-off date, or a switch-off date with no name beside it. In week one, the sign is a count: tickets created or updated in the old system after the freeze. The number should be zero on Tuesday and stay there. If it is seven on Thursday, the old system is not a reference. It is a second desk, and it is winning.

Pattern Five: The Brave Weekend

The brave-weekend pattern is a cutover scheduled for a Saturday so that "nobody is affected". It is run by two people with a laptop and a box of pizza. The export finishes at six, the import starts at seven, and at eleven it stops with a message nobody understands. The vendor's support line opens on Monday. So does the desk, at eight, on whichever system half-worked, with sixty requesters arriving at once to test it. The migration got its first real load at the worst hour of the week with the fewest people watching.

It happens because a quiet building feels like a safe change. It is the opposite. A quiet building means nobody notices the problem, nobody can answer the question, and the first test of everything is the Monday rush. A quiet Tuesday has the whole desk in, the vendor answering, and requesters available to say "that acknowledgment looks odd". It has a light enough queue that the first new tickets can be watched one by one. The weekend is brave. Tuesday is dull. Dull is what you want from a cutover.

The deeper fault is that the rollback was never written. A rollback is the decision, made in advance, of the exact point after which the desk will not go back to the old system. It includes what the desk will do if something fails before that point. Written down, it is a paragraph. Unwritten, it is an argument at midnight between two tired people about whether "mostly imported" counts. The point of no return is the switch of the mailboxes. That is why everything before it, freeze, export, import and verify, is cheap to undo and everything after it is not. The whole day, step by step, is in The Cutover Plan, and Why It Should Be a Tuesday.

The early sign is the plan itself. Suppose the cutover is on a weekend, the verification step reads "check it looks right", and the word "rollback" does not appear. In that case, the migration has been planned as a weekend and will behave like one. Fixing it costs a conversation and a calendar.

The Early-Sign Table

The table puts the five patterns beside the sign that gives each away and the check that catches it. Run it against your plan before the date is fixed, and again at the end of the first week. Three of the checks take ten minutes. The test import takes an afternoon and is the best afternoon the project will spend.

Expect to find two. A plan with none of the five is either very good or has not been read closely, and the second is more common. If you find all five, the migration is not late; it has simply not started yet, whatever the project tracker says.

A Short War Story: The Double Queue at Tollgate Foods

Tollgate Foods switched ticketing systems in the autumn, with Priya running a desk of four. The plan ended at go-live, and the old system was kept on "for a month, for reference". Its mailbox was still live because nobody wanted to bounce a requester's reply. Requesters kept replying to their old threads, which landed in the old system. Two technicians kept working there, because that was where those tickets were. Within a fortnight the old mailbox was receiving new requests from people who had simply hit reply on an old acknowledgment. Fourteen months later, when the second renewal notice for the old system arrived, Priya counted 212 tickets opened or updated in it after the switch. Of those, 31 were still open. Priya found that the quarterly reports for the year could not be reconciled because each system held roughly half the work. The desk had paid a second year for a tool nobody was supposed to be using. It had run two queues with four people for the whole of that year. The lesson Priya wrote at the top of the next plan was one line: a go-live date without a switch-off date is not a migration, it is a second help desk.

The Migration Risk List

The risk list is one page, kept by the person who owns the migration. It is filled in twice: once before the cutover date is agreed, and once at the end of the first week. The top block holds the two dates that most plans forget, the switch-off date and the rollback owner. The middle block is the five patterns with the check for each. A pattern is not "checked" until the check has been done and the result written in. The bottom block is the week-one counts, which are the earliest honest signal the desk will get. Add your own risks underneath; every migration has one that is not on anybody's list.

MIGRATION RISK LIST — ONE PAGE
Migration: ______________________   Owner: ______________   Cutover: ________
Switch-off date for the old system: ________   Rollback owner: ______________

Pattern                Early sign to check                       Done   Owner   Result
1. History lost        Test import of 50 real tickets opened:
                       messages, original dates, old number       [ ]   ______  ______
2. Categories mangled  Mapping table exists, one row per old
                       value, a name beside each; "Other" small   [ ]   ______  ______
3. Users untrained     One-page what-changed sent; old address
                       redirected; new acknowledgment reviewed    [ ]   ______  ______
4. Two systems         Switch-off date in the plan with an owner;
                       old system read-only from the freeze       [ ]   ______  ______
5. Brave weekend       Cutover on a quiet weekday; rollback
                       paragraph written; verification listed     [ ]   ______  ______

Week-one counts (fill in daily)
  Tickets updated in the old system after the freeze   Mon __ Tue __ Wed __ Thu __ Fri __
  Messages arriving at the old address                 Mon __ Tue __ Wed __ Thu __ Fri __
  New tickets landing in "Other"                       Mon __ Tue __ Wed __ Thu __ Fri __
  Requesters asking where their old ticket went        Mon __ Tue __ Wed __ Thu __ Fri __

Risks particular to this migration
  ________________________________  sign: ____________________  owner: ______
  ________________________________  sign: ____________________  owner: ______

Reviewed before cutover by: ______________ on ________
Reviewed after week one by: ______________ on ________

Dana filled one in at Meridian Parts, after the fact, as a way of writing down what she would do differently. Four of the five were ticked "found", which she said was a tidy number and one she had not been pleased with. The fifth, the brave weekend, she had already lived through. The next migration she ran was on a Tuesday, with a switch-off date in the plan before the go-live date. And the old system went dark eight weeks later to no complaint from anyone. The second monitor went back to showing the queue.

Frequently Asked Questions