
use case:
Migration
tools:
ServiceNow - Jira Service Management
130k+
Tickets migrated into JSM
~2 mo
Planning to delivery
15 mo
Of service desk history preserved
0
Service desk downtime
When Uber Freight's ServiceNow contract was up for renewal, the platform engineering team chose to consolidate on Jira Service Management instead. They needed a migration partner that could handle scale, complexity, and a hard deadline. Without handing over access to production.
About
Uber Freight
Uber Freight is the logistics arm of Uber Technologies, founded in 2017 and headquartered in Chicago, Illinois. It operates a global freight platform connecting shippers and carriers across North America and Europe, with services spanning managed transportation, TMS, freight forwarding, customs brokerage, and consulting.
Its platform engineering team manages the company’s Atlassian footprint, including the tooling that supports the IT service desk referenced in this case study.
The Challenges
A hard contract deadline, a complex ITSM estate, and no room for error
Uber Freight’s ServiceNow contract was set to expire, and renewing wasn’t where the team wanted to spend the budget. Since the platform engineering team already owned the Atlassian footprint, consolidating ITSM into JSM was the natural next step.
The team weighed handling the migration in-house against bringing in outside help. The volume of historical data, the transformation work involved, and the cost of getting it wrong made the case for working with Exalate.
Thiyagarajan Anandan (Theo)
Sr. Engineering Manager, Platform Engineering, Uber Freight
The migration covered around 140,000 tickets; Incidents, Request Items (RITMs), and Service Catalog Tasks from the most recent 15 months of history. Several specific constraints added complexity:
Character limits
JSM has character limits that ServiceNow doesn't. Some field values needed to be transformed during migration, not just moved.
Data model mismatches
JSM has character limits that ServiceNow doesn't. Some field values needed to be transformed during migration, not just moved.
Deactivated user accounts
Many original ticket and comment authors were from deactivated accounts, but user attribution still had to be preserved in the migrated data.
Timestamp constraints
The Jira API doesn't support backdating, so comment timestamps couldn't be carried over natively, requiring a custom approach.
Parent-child ticket relationships
Ticket hierarchies had to survive the migration intact. They're load-bearing for complex request workflows.
No external production access
Reflecting mature security and data governance practices, Uber Freight required that no external party be given direct access to production systems.
the solution
Live, bidirectional sync — so the service desk never stopped
Exalate runs as a live, bidirectional sync between ServiceNow and JSM. That architecture mattered here. Both systems could run in parallel during the migration: the Uber Freight service desk kept operating in ServiceNow while data was continuously synced into JSM in the background. Day-to-day incident handling, request fulfillment, and SLA tracking continued without interruption. There was no big-bang cutover and no forced downtime window.
The Uber Freight team chose the cutover moment themselves; once they were satisfied that the datasets on both sides matched and that their service desk was operationally ready to run on JSM.
Running in parallel also changed the change management problem. Instead of asking service desk agents to switch tools overnight, the team had weeks to work in JSM on real tickets while ServiceNow was still authoritative. By cutover, they weren’t being onboarded, they were already running.

Take a look at what goes under the hood in regards to architecture, security and deployment options for Exalate
Groovy scripting inside Exalate handled the data transformation work a standard migration tool couldn’t: field-level character limit management, deprecated field mapping, deactivated user attribution via a generic account with the original author preserved in the comment body, original ServiceNow creation dates carried over via API calls, and parent-child ticket hierarchies reconstructed using scripting logic.
Exalate Services delivered this engagement directly, working hands-on with the Uber Freight team. No external production access was handed over, and there was no black-box handoff. Uber Freight engineers configured, tested, and validated the sync as the migration progressed. So by go-live, they were already operating the platform they’d be supporting.
results
Migration complete. ServiceNow decommissioned on schedule.
- Migration completed in approximately two months, from planning to delivery.
- Around 130,000 tickets migrated into JSM with user attribution, ticket hierarchies, and original creation dates intact.
- Live tickets were prioritized for a fast cutover, with historical data moved in a subsequent phase, so day-to-day service desk work was never blocked.
- ServiceNow was decommissioned on schedule, avoiding another renewal cycle of license spend and accelerating time-to-value on the JSM investment.
- The service desk team was already operating in JSM at go-live, keeping change management overhead low.
Thiyagarajan Anandan (Theo)
Sr. Engineering Manager, Platform Engineering, Uber Freight
What's next
Expanding the Atlassian footprint
With the move to JSM complete, Uber Freight has been able to expand its Atlassian footprint and streamline operations through in-house workflow customization and automation of repetitive tasks: reducing reliance on external resources for complex ServiceNow scripting and ongoing maintenance. The move has also enabled greater data visibility and integration across multiple Jira projects, improving collaboration, efficiency, and scalability.
Facing a Complex Migration?
Talk to the team about how Exalate handles migrations, data transformation, and zero-downtime go-lives.