That is how a hospitality company sums up their team's migration from ServiceDesk Plus to Jira Service Management. The data transfer took two stages and a handful of customizations. The harder work was getting stakeholders on board without letting experienced technicians down.
This case study covers both what the company migrated with Help Desk Migration and how keeping historical tickets helped the team win support for the new platform.
Why the Company Migrated from ServiceDesk Plus
The company set out to modernize its IT service delivery and bring it into one unified Help Center. The existing ticketing software could not support the ITSM framework the team had in mind.
The IT team had the following requirements for the new system:
Decentralized service routing
Automated ticket deflection through integrated knowledge articles
Clear SLA structures
Full context, with tickets linked directly to users and system assets
One criterion came from the IT employees themselves: keep the old tickets. Years of resolved issues held the technical context that the technicians relied on, and they couldn’t build any reporting without historical data. A fresh start with an empty IT service desk was not an option.
Migration Scope: The Data by the Numbers
Tickets
Users (requesters)
Agents
Companies
Challenges During Jira Service Management Migration
The hard part was not migrating tickets. It was transferring them without losing what made them useful.
-
1
History was non-negotiable.
Technicians needed closed tickets to troubleshoot and report. If the team lost historical data, they could put the project's internal support at risk.
-
2
Screenshots lived inside the conversations.
Inline images in ticket threads would not have carried over to Jira Service Management by default. Without them, many tickets would lose the evidence behind the fix.
-
3
Email signatures cluttered the threads.
Many inline images were logos from email signatures, not screenshots.
-
4
Resolutions had no direct home.
In ServiceDesk Plus, a resolution is a separate record with its own author and date. Jira Service Management has no matching field, so the fix and the credit for it risked getting lost.
-
5
Fields did not match.
The team had to map source fields to target fields, and not every field had a counterpart.
-
6
Work could not stop.
New tickets kept arriving in ServiceDesk Plus while the team transferred historical data.
-
7
People had to come along.
The team needed stakeholder buy-in for the new platform without letting experienced technicians down.
ServiceDesk Plus vs Jira Service Management: Data Mapping
ServiceDesk Plus and Jira Service Management name and structure the same help desk data differently. Here is how the records were matched between the two service desks. Rows marked (custom) were custom work for this migration.
| ServiceDesk Plus | Jira Service Management | What changes |
|---|---|---|
| Requests | Tickets | Request types and statuses must exist in the Jira Service Management project and be mapped before the migration |
| Requesters | Customers | Name, email, and organization move over; phone numbers and contact custom fields have no place on Jira Service Management customers |
| Departments | Organizations | Customers are grouped by organization instead of department |
| Technicians | Agents | Agents are set up in Jira Service Management first; several technicians can map to one agent |
| Conversations and notes | Public and private comments | Comments keep their author, privacy setting, and created-at date |
| Resolution | Public comment | Jira's Resolution field is a dropdown, so the text moved to a comment with its original author and date custom |
| Inline images | Attachments | Inline images became attachments |
| Support groups | Tags (labels) | Tickets have no group field, so each ticket got a tag for its group custom |
How the Migration Was Customized
The IT team tested first, then requested customization. They ran multiple Free Demo Migrations on sample tickets and reviewed how the data looked in the target platform.
Each test showed where the default settings fell short, and a customization would help. As a result, our tech engineers built every adjustment below as custom work, based on how the client's data actually looked.
| Option | What it did | Why the team needed it |
|---|---|---|
| Inline images to attachments | Converted images embedded in ticket conversations into attachments | Screenshots would otherwise have been lost |
| Resolution to public comment | Added each resolution as a public comment, keeping the technician who wrote it as the author and its original submission date | The fix stays in the ticket thread, credited to the right technician at the right time |
| Tag per group | Added a tag to each migrated ticket based on its group in ServiceDesk Plus | The original group stays visible and searchable in Jira Service Management |
| Delta Migration | Transferred tickets created or updated after the Full Migration | The team kept working in ServiceDesk Plus until the switch, with no gap in the data |
Results of Jira Service Management Migration
The company's new Help Center went live with its history intact. The migration ran in two stages: a Full Migration, then a Delta Migration that picked up everything created in between.
Expert Tips from the Hospitality Company
Why the team recommends Help Desk Migration:
"Fast and competent support. The tool is straightforward to use and cheaper than hacking together your own migration scripts. And testing is free."
Tips for teams planning a migration:
Let the tool handle the data
With an automated tool, the data transfer becomes the smallest part of the project. Success depends on everything around it: planning, communication, and the people involved.
Balance your stakeholders
Bring the right mix of stakeholders into the project. You need buy-in for the new platform, but not at the expense of the experienced technicians who rely on the old tickets.
Promise to keep the history, then keep it
Keeping historical tickets was a key part of change management. It showed the team that a new platform would not cost them years of context.
Keep the history, win the team
For this IT team, the historical tickets were more than data. Keeping them was a promise to the technicians, and delivering on it helped the whole team accept the new platform.
Your technicians will ask the same question they did: what happens to our old tickets? Answer it before the project starts. Try a Free Demo Migration and show your team their own tickets in the new platform.
