Migration Cost Is Part of the Decision, Not a Footnote

Thursday, 15:10, in the third-floor meeting room at Bluewater Bank. Omar has done everything this series asks. The requirements were written before the demos. The scoring sheet has two scorers' initials on it. The trial ran for two weeks with all five scenarios, and the recommendation is on the screen. The operations director reads it, nods, and asks the only question Omar did not prepare for: "And what will it cost to move everything across?" The vendor's quote says "data import assistance available". The project plan says "Migration: two days". Omar has six years of tickets in the old system, four hundred categories and ninety canned replies. He has a knowledge base with two hundred articles and a team of five who have never seen the new screen. He says "we think it's fairly straightforward". It is the first untrue thing he has said in the whole project, and he does not yet know it.

Migration cost is everything it takes to get from the old system doing the work to the new system doing the work. That means the hours, the money and the lost ground. Count them from the day the decision is signed to the day the old system is switched off and nobody misses it. It belongs in the decision rather than after it, because it is rarely small, it differs between candidates, and it is the one cost that staying put does not have. This article is part of our Choosing a Ticketing System series. It is about estimating that cost in hours before you choose, so that the director's question has a number for an answer. How to carry out the move itself is a separate series, Migrating Ticketing Systems. This article is only about what the move will cost and how that changes the choice.

It covers why the cost never appears in the quote. Then the article takes the five cost lines in turn, with how to estimate each in hours. Those are history, categories and fields, templates and knowledge, retraining, and the double-running period. Next comes how to put the total into the decision alongside the incumbent's zero. The cost table, a short war story, and the migration cost sheet to copy follow, in that order.

The Cost That Never Appears in the Quote

A quote is a statement of what the vendor will charge you, and migration is mostly not something the vendor does. The vendor may import a file for you, and some charge for it. Everything else is done by your desk, in your hours. That means deciding what to keep, cleaning it, and mapping the old shape onto the new one. It means rebuilding the templates and the articles, teaching the team, and running two systems while the tickets in flight land. You do all that on top of the queue that does not stop arriving while you do it. The quote is silent about those hours for the same reason a car dealer's invoice is silent about the cost of learning to drive. It is not their cost.

The phrase to be wary of is "import included" or "migration assistance available", because it is true and it is narrow. What is usually included is the loading of a spreadsheet file of tickets into the new system. Most tools can export tickets to a spreadsheet file, so the mechanical part is real. What the spreadsheet contains is the question. Often it is one row per ticket with the subject, the requester, the dates, the status and the last category. It often does not include the conversation, the internal notes, the attachments, or the history of who did what when. Loading that is two days. Deciding whether that is enough, and doing something about it when it is not, is the migration.

The cost also differs by candidate, which is why it belongs in the comparison rather than after it. One candidate accepts a spreadsheet and gives you a flat list of old tickets. Another lets you keep the old system's export as a searchable archive beside the new queue. A third needs a consultant for anything beyond users and categories. A fourth is the system you already have, whose migration cost is zero. That is the incumbent's one honest advantage and is addressed below. If two candidates are close on the scoring sheet and far apart on migration, the migration decides. A decision record that leaves it out has left out the deciding line.

Cost Line One: History

History is every ticket the old system holds, and the first decision is how much of it moves. The choices are all of it, the open tickets only, the last year or two, or none, with the old system kept read-only as an archive. Each choice has a cost. Moving everything means exporting, cleaning and importing years of tickets, most of which nobody will ever open again, and finding out that the import lost the attachments. Moving only open tickets is quick and leaves six years of answers to "did we fix this before?" in a system you are about to switch off. Keeping the old system alive as an archive costs whatever it costs to keep it alive. Under a recurring licence that is not nothing. Under a self-hosted one it is a server with a job attached. The trade-offs are laid out in what to migrate and what to leave behind, and the archive options in keeping history without keeping the old system alive. For the cost sheet, you need only to choose one route per candidate and estimate it.

Estimate it by doing a small piece of it during the trial. Export one month of tickets from the old system, look at what the file actually contains, and try to get it into each candidate. Time it, and multiply by the months you intend to move. The multiplication is rarely linear, because the first month finds the problems and the rest repeat them. But it gives you a floor and it gives you the list of what did not come across. Omar's team at Bluewater exported one month and found the conversation threads were present. But the internal notes were in a separate file with no ticket numbers in it. That was an afternoon's discovery that would have been a fortnight's surprise. Count the attachments separately. They are large, and they are often exported to a folder with filenames that mean nothing. Matching them back to tickets is the single most tedious job in any migration I have been near.

Then add the hours for the part nobody budgets: the questions after cutover. For the first two or three months, somebody will ask about a ticket from the old system several times a week. Whoever answers will open the archive, or the spreadsheet, or their memory, and spend ten minutes. Estimate that as a small weekly figure for a quarter and put it on the sheet. It is the line that proves the sheet was written by someone who has done this before.

Cost Line Two: Categories, Statuses and Fields

The old system's categories, statuses, priorities and custom fields are its shape. The new system has a different shape, so every old value needs a decision about where it goes. A category list of four hundred entries does not import into a list of fifteen. Somebody sits with both lists and a spreadsheet and writes "old: Printing/Laser/Jams" next to "new: Hardware" four hundred times, with arguments. Statuses map more easily, because most tools have a handful and they mean roughly the same things. But "Pending" in the old system and "Waiting on requester" in the new one may not behave the same way with the service-level clock. Someone has to check. Custom fields either have a home in the new system or they do not. The ones that do not are a conversation with the department that asked for them.

The honest estimate is one minute per old category plus the arguments, a morning for statuses and priorities, and an hour per custom field. Add a day on top for testing that the mapping did what you meant on the one-month sample. The temptation is to skip the mapping and import everything as "Other". That temptation should be resisted for the reason given in remapping categories, statuses and fields. History you cannot filter is history you cannot report on. A year of tickets filed under "Other" is a year the new system's reports cannot see. A migration is also the one chance a desk gets to shrink a four-hundred-category list to fifteen without anyone objecting, because everything is changing anyway. Take it. Nobody has ever been sorry to lose "Printers (Old)".

Cost Line Three: Templates and Knowledge Rebuilt

Canned responses, the saved replies a technician inserts in two clicks, almost never move between systems. That is because every tool stores them differently. The placeholders that fill in the requester's name or the ticket number are written in each tool's own code. Ninety templates is ninety copy-and-paste jobs, each needing its placeholders rewritten and its tone checked. That is before anyone notices that thirty of them are duplicates and twenty refer to a process that changed. Estimate ten minutes per template you intend to keep, and expect to keep about half. The pruning is a saving, not a cost. But it takes a person and an afternoon to decide, and that afternoon is on the sheet.

The knowledge base is larger and slower. Articles may export as text, and the text is usually the smallest part of the job. The screenshots show the old portal. The links point at old ticket numbers and old article addresses. The formatting arrives mangled. The split between articles technicians may see and articles everyone may see has to be set again by hand on each one. Estimate half an hour per article for a plain article and two hours for one with screenshots. Then decide which articles are worth it by looking at which were read in the last year. A knowledge base of two hundred articles usually has forty that matter. If the new system is QuerySolv, articles can be marked as visible to agents only or to everyone. In that case, the runbook-versus-user-guide split survives in principle. In any tool the first thing to check is whether that split exists at all. A knowledge base that cannot keep runbooks private has turned your technician notes into public documentation. Then add the portal's own guidance: the one-page "how to raise a ticket" that every requester will need in week one. It does not exist yet, and somebody writes it before cutover.

Cost Line Four: Retraining

Everyone who touches the desk needs to learn the new screen. The cost is in three parts: the time spent teaching, the time spent learning, and the weeks of being slower than before. For technicians, a desk of five needs perhaps half a day each of structured walk-through plus a week of working more slowly while the hands find the buttons. The slower week is the larger number. For the desk lead, add the administration: departments, mailboxes, targets, permissions and reports. Each was set up once years ago in the old system by someone who has left. Each is now set up again by someone finding out what the old settings were. For requesters, the cost is an announcement, a one-pager and the first-week questions, which land on the desk as tickets about the ticket system. (They are, at least, easy to categorise.)

Estimate it as hours per person by role, and be honest about the dip. A desk that closes forty tickets a day will close thirty for the first week in a new tool and thirty-five for the second. The shortfall is a backlog that someone clears in week three. The approach that keeps the cost down is in retraining users and technicians without a course. For the sheet, count the teaching hours, the learning hours and the lost tickets. Put the manager's time in too, because the monthly report will look different and someone will have to explain why the numbers moved. The reports have not changed what they measure. They have changed what they are called, which to a manager is the same thing until somebody says otherwise.

Cost Line Five: The Double-Running Period

The double-running period is the stretch when both systems are live. The new one is taking new tickets. The old one is still holding the ones that were open at cutover. Or it is still receiving mail from requesters who reply to old threads, or still being paid for because the contract runs to a date. During it, every technician works in two tools, every "where is my ticket?" has two possible answers, and every report is two reports added together by hand. For a small desk it lasts two to six weeks if the cutover is planned and much longer if it is not. The plan is in the cutover plan, and why it should be a Tuesday. For the sheet, you need its length and what it costs per week.

The per-week cost has three parts. First are the hours lost to working in two places. For five technicians, that is perhaps an hour or two each per week in switching, searching and double-entry. Second is the licence overlap, if the old system is recurring and the notice period means you pay for both. And there are the tickets that fall between the two, raised in one system and answered in the other or in neither. Those cost whatever a lost ticket costs your desk in trust. Estimate the first as hours, the second from the old contract's notice clause, and the third as a small number of tickets you will spend an hour each recovering. Then multiply by the weeks. A double-running period with no end date is not a period. It is a second system you are paying for. I have watched one last eleven months because nobody owned the day it would stop.

Putting It Into the Decision

The five lines add up to a figure in hours for each candidate. That figure goes into the same total-cost worksheet as the licence and the server, in the migration line of hosting and licensing models in plain words. It is a one-off cost, so it weighs more at a three-year horizon than at five, and that is correct. A desk that expects to change tools again soon should mind migration more than one that expects to stay a decade. Convert it to money only if your organisation requires it, using a loaded hourly figure that finance agrees to. Otherwise leave it as hours, which is what the desk will actually spend.

The incumbent, the system you already have, has a migration cost of zero. That is a legitimate advantage that should appear on its column of the worksheet rather than being wished away. It is also a smaller advantage than it looks, for two reasons. The first is that the incumbent's zero is only zero if nothing else about it changes. A forced upgrade, a licensing change or a vendor's end-of-life notice is a migration you did not choose, with the same five lines and no trial. The second is that the costs that made you start this project are recurring. Those are the duplicates, the report nobody could produce, and the mailbox that could not become a queue. A recurring cost beats a one-off one within a year or two. Put the incumbent's zero on the sheet, and beside it put the hours per month the current system is costing you in workarounds. That comparison is usually the whole decision in two numbers.

The table below is a fictional desk's estimate, stated as such. The desk is Bluewater Bank, with five technicians, six years of history, four hundred categories, ninety templates, two hundred articles, and two candidates. The ranges are Omar's, made after doing a sample of each line during the trial. The point of showing them is the shape rather than the figures. Candidate A accepted a spreadsheet and nothing else. Candidate B let the desk keep the old export as a searchable archive. Candidate B had a template format close enough to the old one that half the replies came across with their placeholders intact. The scoring sheet had them four points apart. The migration sheet had them a hundred and fifty hours apart, in the other direction.

Read the total as a range and report it as one, because a single number will be remembered as a promise. Then read the lines, because the lines tell you where the candidates differ and where the desk can save. The history line is the one most under your control, since moving less of it costs less and most of it will never be read. The retraining line is the one most desks underestimate, since it is paid in slower weeks rather than in a project plan. Finally, divide the total by the hours the desk works in a month and say the answer out loud. For Bluewater, candidate A was the better part of two technician-months. Omar had told the director it was fairly straightforward. He amended the record.

A Short War Story: The Included Import at Pennant Media

Pennant Media, a regional publisher with a four-person desk, chose a new ticketing system partly because the vendor's quote said "data import included". Hannah, the desk lead, put "Migration: one week" in the plan on the strength of it. The included import turned out to be the loading of a spreadsheet of ticket subjects, requesters and dates, with no conversations, no notes and no attachments. The vendor had never claimed otherwise, and nobody had asked. The desk kept the old system alive to hold six years of history. Under its recurring licence, that meant renewing it for a further year at the full headcount. The desk ran both systems for five months because no cutover date had been set and the old mailbox kept receiving replies to old threads. By the time the old system was finally switched off, the desk estimated it had spent about three hundred hours on the move against the forty it had planned. It had paid a year for a system nobody was using. It had lost the attachments anyway because nobody exported them before the renewal lapsed. A migration cost that is not estimated is not avoided. It is simply paid later, in a currency nobody agreed to.

The Migration Cost Sheet

The sheet below is one page per candidate, filled in during the trial, when each line can be sampled rather than guessed. Every line gets a range in hours and a note on how the range was reached. A line marked "vendor says" is a claim, and a line marked "we tried it" is an estimate. The incumbent gets a column too, with zero in the migration lines and its monthly workaround cost in the last block. The total goes into the migration line of the total-cost worksheet, and the sheet itself goes into the decision record. That way, the person asking "why did this take so long?" in six months finds the answer was written down before it started.

MIGRATION COST SHEET — ONE PAGE PER CANDIDATE, IN HOURS
Candidate: ______________________   Prepared by: ______________   Date: ____________
Old system holds: ____ years of tickets   ____ categories   ____ templates   ____ articles
Technicians: ____   Requesters: ____   Old licence notice period: ____ weeks

Evidence codes:  V = vendor says   S = we sampled it in the trial   G = guess, no sample yet

1. HISTORY
   Route chosen:  [ ] move all  [ ] move open only  [ ] move ____ years  [ ] archive, move none
   What the export contains (tested on ________):  [ ] conversations  [ ] internal notes
                                                   [ ] attachments     [ ] history of actions
   Export, clean and import, per month of tickets: ____ h  x ____ months  = ____ to ____ h   [ ]
   Attachments matched to tickets:                                         ____ to ____ h   [ ]
   Archive questions, first quarter after cutover (____ h/week x 12):      ____ to ____ h   [ ]

2. CATEGORIES, STATUSES AND FIELDS
   Old categories ____ x 1 min, plus arguments:                            ____ to ____ h   [ ]
   Statuses and priorities mapped and clock behaviour checked:             ____ to ____ h   [ ]
   Custom fields ____ x 1 h, including the conversation about each:        ____ to ____ h   [ ]
   Test of the mapping on the sampled month:                               ____ to ____ h   [ ]

3. TEMPLATES AND KNOWLEDGE
   Templates kept ____ x 10 min, plus the pruning afternoon:               ____ to ____ h   [ ]
   Articles kept ____ (plain x 0.5 h, with screenshots x 2 h):             ____ to ____ h   [ ]
   Agent-only versus everyone visibility set again per article:            ____ to ____ h   [ ]
   One-page "how to raise a ticket" for requesters:                        ____ to ____ h   [ ]

4. RETRAINING
   Technicians ____ x half a day:                                           ____ to ____ h   [ ]
   Desk lead administration (departments, mail, targets, permissions):     ____ to ____ h   [ ]
   First-week dip (usual closes/day ____ minus week-one closes/day ____):  ____ to ____ h   [ ]
   Requester announcement and first-week questions; manager briefing:      ____ to ____ h   [ ]

5. DOUBLE RUNNING
   Expected length: ____ to ____ weeks   Cutover date set: ____________   Owner: ____________
   Switching and double entry (____ h/technician/week x weeks):            ____ to ____ h   [ ]
   Licence overlap from the notice clause (money, noted separately):       ______________
   Tickets recovered from between the systems (____ x 1 h):                ____ to ____ h   [ ]

TOTAL HOURS (sum of ranges): ____ to ____ h     In technician-months: ____ to ____
Lines resting on V or G only: ____   (sample them before the decision if the ranking depends on them)

THE INCUMBENT'S COLUMN
   Migration cost if we stay: 0 h       Hours per month the current system costs in workarounds: ____
   Months until the workaround hours exceed the cheapest migration: ____

Omar filled in both sheets in the second week of the trial and took them to the director with the total-cost worksheet. The worksheet now had a migration line with a range in it instead of "two days". The director asked why candidate B was cheaper to move to. The answer was on the history line, where a searchable archive had replaced a fortnight of matching attachments by hand. Candidate B was chosen, and the cutover was set for a Tuesday six weeks out. The double-running period ended on the day it was supposed to. Omar describes that as the least dramatic thing that happened all year. He means it as the highest praise he has.

Frequently Asked Questions