Switching ITSM vendors looks like a data migration and is mostly a configuration rebuild. Your open tickets move. Your request catalogue, approval routing, SLA rules and automation do not, and that is where the weeks go.
TL;DR
- Tickets and asset records export reasonably well. Everything that made the desk work has to be rebuilt.
- The request catalogue and its approval routing is the single largest piece of work and the most underestimated.
- Historical ticket data usually arrives as a flat export without its workflow context, which makes it archival rather than operational.
- Expect four to eight weeks with a part-time owner, and run both desks in parallel for at least two.
- Export everything before you give notice, because your access ends with the contract.
- Count resolvers before you sign anything new, since almost everything here is priced per agent.
What transfers when switching ITSM vendors
Shorter than the sales conversation suggests, and worth being clear-eyed about.
Open tickets. Every credible vendor will import these, and the import generally works. Expect to lose threading on long conversations and attachments occasionally.
Asset records, if you kept them. A device list with serials and assignments moves cleanly because it is a table. The links between assets and historical tickets usually do not.
User records. If both desks authenticate against your identity provider, this is close to free. If the old one had its own user list, somebody is reconciling it.
That is the list. Everything in the next section gets rebuilt from nothing.
What you rebuild
The request catalogue. Every request type, its form fields, its routing and its approval chain. A mature desk has twenty to sixty of these and each represents a decision somebody made in response to a real situation. This is the bulk of the work.
Approval routing. Who signs off what, at which threshold, with which fallback when they are on leave. Rarely documented anywhere except inside the tool.
SLA rules and escalations. Response and resolution targets, business hours, holiday calendars, and what happens when a target is missed.
Automation. Every rule that assigns, tags, notifies or closes something. These accumulate invisibly and nobody has a list.
Reports. Whatever somebody senior looks at monthly. Rebuilding this last is a mistake, because it is the first thing anybody notices missing.
The historical data trap
Teams assume their ticket history comes with them in usable form. It usually arrives as a flat export: subject, body, dates, who closed it. What it loses is the workflow context, meaning which request type it was, which approval path it took, and which SLA applied.
That makes it archival rather than operational. You can search it and you cannot report on it, which matters if anybody expects year-on-year comparisons across the cutover.
What to do: decide early whether you need history to be reportable or merely retrievable. If reportable, run your key reports on the old desk before cutover and keep the outputs, because reproducing them afterwards from a flat export is usually not possible.
Running the switch without a gap
Checklist, in order:
- Export everything before giving notice, while access is normal
- List every request type, approval rule, SLA and automation as text
- Run and save your standing reports from the old desk
- Rebuild the top ten request types first, which cover most volume
- Run both desks in parallel for two to four weeks
- Cut over by team, not by date
- Keep the old desk readable for a month afterwards
The parallel period matters more here than in most migrations, because a service desk is where work arrives. A hard cutover with a missing request type means somebody cannot order a laptop on Monday, and that becomes visible immediately.
Cutting over by team rather than by date contains the damage. Move IT first, then one friendly department, then everybody. The first group finds the three gaps your testing missed.
What the destination costs
Every figure below was read from the vendor’s own page on 15 October 2026, and the basis is per agent almost everywhere, so count resolvers before you compare.
Jira Service Management publishes a free tier to three agents, then Standard at $21.50 and Premium at $55.28 per agent per month, which at 12 agents makes Standard $258 a month.
Freshservice publishes Starter at $19, Growth at $49 and Pro at $99 per agent per month on annual billing, with an AI add-on at $29 per agent per month on top.
ServiceNow publishes no readable figure for its ITSM product, so an evaluation there starts with a sales conversation rather than with arithmetic.
Verify these against the source before committing: Atlassian and Freshservice both publish openly, and pricing in this market moves within weeks.
The reason for switching that is not a product problem
A share of these migrations are prompted by volume rather than by the tool, and a new desk will not change volume.
What to do: count how many closed tickets were resolved by typing an answer rather than by doing something. If that proportion is high, your desk is working correctly and tracking questions that did not need a ticket.
Matram publishes $29 Basic, $69 Standard and $199 Pro per month, flat, with unlimited seats and a 30-day trial that takes no card. Disclosure that should shape how you read this: Matram is owned by the same people who publish this site.
Where it struggles, stated plainly: there is no free tier; it answers questions but does not action tickets, so nothing is provisioned or closed; and it is not an ITSM platform, so there is no asset register and no change management. It does not replace a desk and will not absorb a migration.
Final thoughts
The work in switching ITSM vendors is not the data. It is reconstructing decisions that live only inside the tool you are leaving, and the cheapest version of that is writing them down before you give notice rather than recovering them afterwards from memory.
Do the catalogue inventory first, keep your reports, run in parallel, and cut over by team. And check whether the thing prompting the move is the desk at all, because a migration undertaken for a volume problem delivers a new desk and the same workload.
How long does switching ITSM vendors take?
Four to eight weeks with a part-time owner, including two to four weeks running both desks in parallel. The ticket import takes hours and is not the work. The work is rebuilding the request catalogue, approval routing, SLA rules, automation and reports, none of which transfers between products because each only has meaning inside the tool it was built in.
Does our ticket history come with us?
The records usually do, as a flat export of subjects, bodies, dates and closers. What does not come is the workflow context: which request type it was, which approval path it followed, which SLA applied. That makes the history searchable but not reportable, so if anybody expects year-on-year comparisons across the cutover, run and save those reports before you leave.
What is the biggest piece of work?
The request catalogue and its approval routing. A mature desk carries twenty to sixty request types, each with form fields, routing rules and an approval chain, and every one of them represents a decision somebody made in response to a real situation. Almost none of it is documented outside the tool, which is why the rebuild takes weeks rather than days.
Should we run both desks at once?
Yes, for at least two weeks, and this matters more than in most migrations because a service desk is where work arrives. A hard cutover with one missing request type means somebody cannot order equipment on Monday, which is immediately visible to the whole company. Cut over by team rather than by date so the first group finds the gaps your testing missed.
When should we export our data?
Before giving notice, while the relationship is normal and your access is not time-limited. Take the tickets, the asset records, the user list and screenshots or text of every request type, approval rule, SLA and automation. The configuration export is the one nobody thinks of and the one that turns an eight-week rebuild into a four-week one.
How do we know a new desk will help?
Establish what is actually wrong first. If the complaint is that the tool cannot do something structural, a move is justified. If the complaint is volume, count how many closed tickets were answers rather than actions, because a new desk will track the same questions just as faithfully. Migrations undertaken for volume problems deliver a new tool and an unchanged workload.
