The ultimate ITSM migration checklist: How to switch service desks without data loss

On paper, an IT service management (ITSM) migration can look straightforward. Export the data, connect the new platform, move users over, and retire the old tool. Simple, right?

In practice, there’s more to account for. You may need to rebuild workflows and reconnect integrations, while also preparing employees to use the new service desk. You’ll also need a plan for historical records and any open tickets that are still being worked when you switch systems.

Miss something and you could lose ticket history, break a workflow, or leave an employee request stranded between the old and new platforms.

In this article, we’ll walk through the ITSM migration process step by step, from auditing your current setup and deciding what data to keep to running both systems in parallel and retiring the legacy service desk.

TL;DR

• Only migrate if the new ITSM is a clear improvement. Decide what needs to get better, such as auto-solve rate or resolution time, before committing to the switch.
• Audit your current setup before rebuilding it. Map workflow dependencies, integrations, custom fields, and reporting so nothing critical breaks during migration.
• You probably don’t need to move every historical ticket. Archive older records when appropriate and focus on the data your new service desk still needs.
• Choose between a parallel run and hard cutover based on how much transition risk you can accept. A parallel run keeps the legacy system available while you validate the new setup and manage in-flight tickets.
• Treat go-live as part of the migration. Test the new setup, support employees through the change, and retire the old platform only after you’ve confirmed everything works as expected.

Is migration worth it?

An IT service desk migration only makes sense if the new platform solves problems your current setup can’t. One IT lead we spoke to when evaluating a switch put it simply: “Migration only makes sense as a step forward, not parity or regression.”

Before you start planning the migration itself, look at the problems your current setup is failing to solve and define what meaningful improvement would look like.

Pressure-test the decision with questions like:

• Will your auto-solve rate improve enough to take meaningful work off IT’s plate?
• Will employees get help through the channels they actually use, or will they still bypass the service desk and ask in Slack?
• Can your team build and update automations faster than it can today?
• Is your current stack creating so much maintenance work that you need specialist resources just to keep workflows running?
• Will resolution times improve enough to justify the switch?

Before you start evaluating the new platform, capture your current performance baseline. Pull the metrics you’ll use to evaluate the new platform, such as auto-solve rate and resolution time, so you can compare results on a like-for-like basis.

You can also replay a sample of recent historical tickets through the new platform to estimate how many it would have resolved automatically before you commit to the switch.

Auto-solve rate is one way to set that benchmark. One Risotto customer had used its previous AI assistant for years, but it was still only auto-solving around 30% of tickets. Within roughly three weeks of switching, that figure reached around 50% to 55%. It later climbed above 70%.

What's really at risk when migrating to a new ITSM tool

Once you’ve decided the migration is worth pursuing, the next step is to identify what could go wrong during the move.

Review the parts of your current setup that are most likely to be affected:

Ticket data

Separate historical records from in-flight work. Check what can be exported cleanly and what needs to remain accessible after the migration. Different ITSM platforms structure data differently, which can make moving large volumes of old ticket history into the new system much more complicated than you anticipated.

Custom fields and forms

Check whether any workflows depend on information captured in custom fields. One team we spoke to had complex Jira request types where custom fields passed data into Okta Workflows. If those fields weren’t mapped correctly in the new platform, the downstream automation wouldn’t have the information it needed to run.

Automations, workflows, and runbooks

Document what each automation does and what it depends on before you rebuild it. Then decide whether it should be recreated, simplified, or retired. This helps you avoid carrying outdated processes into the new service desk or overlooking a dependency that another workflow relies on.

Integrations

Audit every system connected to your service desk, including your identity provider (IdP), HRIS, mobile device management (MDM), knowledge base, Slack, and Teams. For each connection, document what information passes between the systems and what actions rely on it.

Reporting and compliance

Check which reports and dashboards rely on your current ITSM data. Changes to fields or ticket structures can break existing reporting, so make sure each report has the data it needs in the new setup before cutover. You may also need to keep older records accessible for legal or audit requirements.

CTA 1: Worried about what breaks in a migration? See how you can adopt a new AI layer to your ITSM with nothing dropped mid-switch. Book a demo.

The ITSM migration checklist

Once you know what could be affected by the move, your next step is to turn that into a migration plan. Start by working backward from your current ITSM contract end date and checking any renewal or opt-out deadlines, so you leave enough time for migration, testing, and any overlap period you need. 

Then work through the setup and testing in stages before routing employee support through the new platform.

Use these eight phases as your ITSM platform migration checklist.

1. Audit workflows, custom fields, and automation dependencies

Start with an audit of how work moves through your current service desk. Document each request type and the workflow behind it, including the fields it relies on and any other systems involved.

Track what happens after each request is submitted, especially when the process continues in another system. A custom field, for example, may supply information to an access workflow elsewhere in your stack. You need to know that before you rebuild the request on a different platform.

For your 10 highest-volume or most complex request types, build an old-vs-new parity matrix. Note what the new platform can reproduce as-is, what needs to be rebuilt, and where extra work may be required. This gives you a clearer picture of migration effort before you start rebuilding workflows

For example: One team we spoke to found around 36 runbooks during its migration audit. Those runbooks had to be reviewed and refined, while the forms and routing behind them were reconstructed for the new setup.

2. Decide what to do with historical data

You probably don’t need to move every old ticket into the new platform. Importing historical tickets creates extra mapping and validation work because ITSM platforms don’t always structure ticket data in the same way.

In many cases, it makes more sense to archive older records so they remain accessible and only migrate the data you still need in the new service desk.

For example, one migration involved around 42,000 historical tickets that had to be kept for legal reasons. Instead of importing them all, the team archived the records and indexed the solved tickets so AI could search past resolutions when answering similar support requests.

The team could still access the old ticket history when needed without moving thousands of records into the new ITSM.

Use the table below to decide what needs to move and what can stay archived:

3. Connect integrations before launch

Take the external systems you identified in step one and connect them to the new service desk before cutover. Don’t overlook less obvious connections either. Niche knowledge connectors, for example, are one of the dependencies teams can discover late in a migration.

Once each integration is connected, test the workflow that depends on it from beginning to end. For example, if an access request uses Okta, run the request through the new setup and confirm it completes the expected action.

Also check that the integration has the permissions it needs to perform that action. An integration can connect successfully but still lack permission to provision access or update the data a workflow needs.

4. Rebuild and refine workflows

Don’t assume an old workflow should be recreated exactly. Migration is a chance to remove redundant steps and rebuild around the way your team wants support to work now. It’s often better to rebuild processes for the new system than copy them directly from the old one.

Migration can also expose gaps in processes that look fine on paper. Get input from the teams who work with those workflows every day, then fix those gaps as you rebuild. 

For example, one IT team evaluating a switch said every new automation required a workflow step to be built manually, followed by a development release cycle of roughly two weeks. Rebuilding that same process would carry the bottleneck into the new service desk.

With Risotto, you don’t have to rebuild every automation manually. Our Assistant turns natural-language instructions into runbooks, which define how repeatable requests are resolved. IT simply reviews and approves the actions before the automation goes live.

For common requests, Risotto also provides prebuilt workflow templates based on processes other IT teams already use. Your team can start with the template and adapt it instead of building every runbook from scratch.

5. Map fields and test the sync

Don’t map fields based on their names alone. Different ITSM platforms can represent the same information differently, so check what each field actually means and how the new system stores it. A request category in one platform, for example, may need to map to a different ticket type or category structure in another.

For every field you carry across, define where it should live in the new system and how its data should be handled. Pay particular attention to custom fields, attachments, and dates, including time-zone differences. These are all areas where migrated records can end up incomplete or inconsistent.

Then test the sync in both directions. Create and update test tickets from each system and confirm that the information your team relies on follows them correctly. With Risotto’s Jira integration, ticket titles, categorizations, comments and status updates stay synchronized between Jira and Slack. Those are the kinds of changes you should verify before relying on the sync during a parallel run.

6. Choose your cutover approach and manage in-flight tickets

Before go-live, decide whether you’ll use a parallel run or a hard cutover. A parallel run keeps the legacy service desk available while you start using the new platform. A hard cutover switches support to the new system on a fixed date.

Here’s how the two approaches compare:

If you choose a parallel run, bi-directional sync keeps in-flight tickets accessible and up to date during the transition. Your team can keep working them without manually recreating each request.

Before you start routing work through both systems, take a snapshot export of the open-ticket queue. This gives you a record of every ticket that was open at that point, so you can check that nothing gets lost during the transition.

7. Plan for cutover 

Once you’ve chosen your cutover approach, plan the go-live itself in detail. Even with a parallel run, you need a clear point when employees start using the new service desk and a plan for what happens before and immediately after that switch.

We recommend scheduling cutover so you have time to test the new setup before employees start using it. For example, one team we spoke to began its technical cutover on a Friday afternoon, continued user acceptance testing into Saturday and moved employees over on Monday. Company-wide communications went out Monday morning, followed by a three-day hypercare period so the IT team could catch and resolve any issues quickly.

Make employee communication part of the plan too. Contact anyone with an in-flight ticket directly and explain how they can continue following their request. Update training materials and internal documentation before go-live so employees know how to use the new service desk from day one.If an org-wide switch feels too disruptive, roll the new service desk out by department instead.

Define your rollback plan before cutover too. Set the conditions that would trigger a rollback, what would need to be reverted, and who has authority to make that decision.

If possible, leave some time between go-live and the end of your legacy contract. One customer went live in mid-May while its old contract ran through the end of July, giving the technical migration a buffer before the contract expired.

8. Sunset the legacy system and verify reporting

Only retire the old platform after you’ve confirmed that the new service desk is working as expected and any historical records you need to keep are still accessible.

Check that dashboards and reports are pulling from the right data source, and confirm that archived records can still be retrieved for audits or other retention requirements.

Then shut down the old system properly. Disable its service accounts and remove its Slack, Jira, and other integrations so it can no longer interact with your environment.

Finally, compare post-migration performance against your pre-migration baseline. Look at the metrics you used to justify the switch, such as auto-solve rate, time to resolution, escalation rate, backlog, and hours saved.

Start with Risotto alongside your existing ITSM

A full ITSM migration makes sense when you genuinely need to replace the whole service desk. But if the main problem is that too much Tier-1 work still reaches your team, you may not need to take on that migration all at once.

A hybrid approach lets you improve support without immediately replacing the systems, reporting, and processes your team already depends on. Risotto sits alongside your existing service desk, auto-solving Tier 1 requests in Slack while your current ITSM remains the system of record.

That gives you a lower-risk way to start. You can see how much work Risotto actually takes off your team before deciding whether a full migration is worthwhile. If the hybrid setup gives you what you need, you can keep it. If you want to consolidate later, you can move ticketing into Risotto when your team is ready.

This gives you a gradual path to an AI IT service desk, so you can improve automation without replacing your existing setup.

FAQs about ITSM migration

How long does an ITSM migration take?

There’s no fixed timeline for an ITSM migration. It depends on how much you need to audit, rebuild, integrate, and test before go-live. The more workflows, dependencies, and data you need to account for, the more time you’ll need to validate the new setup before cutover.

Should you migrate historical tickets to a new system?

Not necessarily. Older tickets often don’t need to be imported into the new ITSM if they can be archived and retrieved when needed. Prioritize in-flight tickets and records required for legal, audit, or reporting purposes. Historical tickets can also be indexed for AI without being migrated.

What is a parallel run in an ITSM migration?

A parallel run keeps both the old and new service desks available during the transition instead of switching everything at once. With bi-directional sync, in-flight tickets can stay accessible and up to date while the team validates the new setup before fully retiring the legacy platform. 

How do you handle open tickets during an ITSM migration?

Start by taking a snapshot export of the open-ticket queue. During a parallel run, bi-directional sync can keep in-flight tickets actionable without manually recreating them. Contact affected employees directly, explain how to follow existing requests, and confirm nothing has been lost before retiring the legacy system. 

What causes data loss during ITSM migrations?

Data loss can happen when teams overlook custom fields, attachments, ticket history, integrations, or open requests during migration. Poor field mapping or retiring the legacy platform before records have been checked can also leave important information inaccessible, which is why validation and backups should happen before cutover.