Migrating 80,000 ServiceNow Tickets to Jira Service Management: A Digital Freight Platform’s Journey

[Syed Majid Hassan -Exalate-]

As one of North America’s most recognized digital freight platforms, the company connects shippers and carriers through a sophisticated digital marketplace. Behind the scenes, its platform engineering team manages the Atlassian ecosystem powering internal operations.

When their ServiceNow contract approached renewal, they made a strategic decision: transition their entire IT service management function to Jira Service Management (JSM).

Deciding to switch was the easy part. Moving the data was the real challenge.

The Problem

The migration covered around 80,000 tickets: Incidents, Request Items (RITMs), and Service Catalog Tasks going back three years. Several things made this harder than a standard migration.

JSM has character limits that ServiceNow does not, so field values couldn't be copied over without transformation. Many tickets had comments from employees who had since left the company and had deactivated accounts. 

The Jira API doesn't support backdating, so original timestamps couldn't be written directly. Tickets had parent-child relationships that needed to stay intact. 

And there was already a live integration between ServiceNow and Jira Software running in production that couldn't be disrupted during the move.

The team also had a clear requirement: no external party would be given direct access to their production systems.

To summarise the main issues:

• Around 80,000 tickets requiring field-level data transformation, not just field mapping.
• Comment attribution for former employees with deactivated accounts.
• No native way to preserve original timestamps via the Jira API.
• Parent-child ticket relationships that had to remain intact after migration.
• An active ServiceNow to Jira Software integration that had to keep running throughout.

"The complexity of what needed to move, and the consequences of getting it wrong, made the case for Exalate.": Platform Engineering Team

Finding the Right Solution

Standard migration tools could handle basic field mapping, but not the transformation logic this project needed. 

The team evaluated their options and chose Exalate.

Rather than a single cutover, Exalate set up a live bidirectional connection between ServiceNow and JSM. Both systems ran at the same time. The service desk kept working in ServiceNow while tickets were continuously synced into JSM in the background. When the team confirmed the data matched, they switched over on their own schedule.

"We needed a solution that could handle the data complexity, keep both systems running in parallel, and hand control back to us, not take it away.": Platform Engineering Team

The Actual Migration

Exalate’s Groovy-based scripting handled the transformation work. 

JSM character limits were managed with field-level logic. Comments from deactivated accounts were routed through a generic user, with the original author's name written into the comment body. 

Original creation dates from ServiceNow were preserved through direct API calls. Parent-child relationships were maintained using scripting logic.

The whole engagement ran in two-hour working sessions. No production access was handed over at any point.

The migration ran in two phases: live tickets first, then historical data. This kept the service desk running without interruption and gave the team time to validate before fully committing.

If you are scoping something similar, define your transformation requirements before touching any configuration. Know which fields need logic applied, not just a mapping. Set your validation criteria before you start, so you know exactly what you are checking before cutover. 

"The ability to run both systems in parallel, validate the data, and choose our own cutover moment made this feel manageable.": Platform Engineering Team

The Results

The project finished in three months.

The service desk operated in ServiceNow throughout the migration with no interruption. Once the team confirmed JSM had everything it needed, they cut over. No downtime, no scramble.

All 80,000 tickets moved to JSM with their full history: comments correctly attributed, original creation dates preserved, and parent-child relationships intact.

ServiceNow was decommissioned before the contract deadline, and everything was consolidated on one platform.

Because the team had been configuring and testing JSM throughout the process, they were already familiar with it by go-live. There was no adjustment period for the service desk.

"We decommissioned ServiceNow on schedule, with our full ticket history intact and our team already embedded in JSM. That's exactly what we needed.": Platform Engineering Team

If you are working through a similar migration and want to talk through the approach, drop a comment or reach out to get to know your experience.

[Urmo]

I have a similar experience with 142k tickets from Zendesk to Jira, and to be honest, setting up Exalate for the first time takes a bit more time than it seems, but it's all learnable today by relying on Gemini, ChatGPT, and Exalate's own Groovy AI.

These same volume limitations were also unexpected for me, but again, everything can be configured so that things remain intact during the move.

However, what did surprise me was how tedious it is, for example, with Zendesk, to process the volume of tickets, up to 1000 records at a time. In this regard, there could be an option for the Exalate add-on to automatically break down the entire volume of tickets into smaller batches so that Jira can receive them without much trouble. It's just time-consuming.

During this process, I noticed that not all tickets are always brought over, meaning the synchronization has to be done multiple times, which implies that for some reason, some tickets don't come across. My experience was that out of 142k tickets, about 120k came over the first time, so 20k were missing. About 5k more were recovered, and now I'm trying to understand why the rest have been left behind.

But overall, it is suitable for a user who doesn't want to create code from scratch but just wants to move data from one application to another.