Vanta’s 128K+ Ticket Migration to Jira Service Management: History Preserved, Complexity Simplified

Vanta, an Agentic Trust Platform, moved 128,000+ tickets, 512,000 comments, and 86,000 attachments from Freshservice to Jira Service Management with custom field mapping and historical data preservation — completing the migration in 21 days with Help Desk Migration.

About Vanta

Vanta is the #1 Agentic Trust Platform, founded in 2018 to help businesses automate compliance, manage risk, and continuously prove trust. The company was created in response to the growing need for stronger data protection and initially focused on automating compliance processes for standards such as SOC 2, HIPAA, and ISO 27001.

Today, Vanta provides a single, AI-powered platform that helps organizations continuously manage security, compliance, and risk. Trusted by 15,000+ customers, Vanta serves companies including Atlassian, Duolingo, Icelandair, Ramp, and Synthesia. Its platform enables businesses to build, maintain, and demonstrate trust through continuous, real-time processes. The company continues to focus on helping businesses protect data, streamline compliance, and prove trust at scale.

We spoke with Janiece Caldwell, who leads IT Operations within Vanta’s Corporate Engineering team, about the Freshservice to Jira Service Management migration. She oversees help desk support, internal ticketing, and IT systems, with a focus on automation, scalability, and efficient service delivery. Janiece shares Vanta’s migration goals, key challenges, and experience moving to JSM with the Help Desk Migration.

Why Vanta Decided to Migrate from Freshservice to Jira Service Management

JSM is our internal request portal — IT uses it for hardware, software access, and troubleshooting requests, but it's also become the shared platform for People Ops, Workplace, GTM Systems, HR, and Access Management. Basically every Vantan touches it as a requester, and our IT/Enterprise Engineering agents work out of it daily. We also have a Slack integration so tickets sync bidirectionally between Slack and JSM.

Freshservice had stopped keeping pace with our needs — scalability, flexibility, and integrations were all falling short as we grew. We wanted better workflows, better reporting, and tighter alignment with the rest of our engineering/IT tooling, so we made the call to move to JSM.

Challenges

• Freshservice and JSM fields don’t line up field-for-field.
• Every ticket had to keep the original reporter and assignee information.
• Catalog items, approval flows, and automations had to be rebuilt in JSM.
• Remove redundant or outdated request types rather than simply replicate them.
• A Demo Migration helped identify gaps early, including reporter and assignee mapping issues, before the full migration.

Customizations + Out-of-the-Box Migration Options Tailored to Vanta’s Needs

Which data was most important to preserve in Jira Service Management?

Preserving historical ticket data was important for continuity and audit purposes — we're a compliance company, so being able to show timestamps and request history matters for things like our own SOC 2 audit. We also wanted our teams to still be able to search past tickets in the new system rather than losing that institutional knowledge.

How important was the ability to customize the migration around your team's specific requirements, and which customizations were most valuable to you?

Customization was important. Freshservice didn't map cleanly to JSM in every field — for example, we had to make sure original reporter and assignee names carried over even though JSM didn't have a direct equivalent field.

We also needed our catalog items, approval flows, and automations rebuilt rather than just copied, since we used the migration as a chance to clean up redundant or outdated request types.

The demo migration let us validate field mapping and data integrity before committing to the full historical migration. It surfaced a few gaps early — like the reporter/assignee field issue — that we were able to fix before the real migration ran, instead of finding out after the fact.

Customizations Built to Preserve Vanta’s Data and Context

The migration required more than a standard data transfer to ensure Freshservice data fit the Jira Service Management environment. The migration was customized to preserve important field values, approvals, service items, original user information, and agent comment authorship. These tailored mappings also kept the migrated data structured, searchable, and easy for Vanta’s teams to use in JSM.

• Migrate field values into the ticket description: Original ID, Group, Source, Issue type, People Issue Type, Legal Issue Type, AWS Role, Category. If a source field is empty, migrate it with the value empty.
• Migrate Service Items for Service Requests (SRs) into the ticket description.
• Migrate Approvals into the ticket description, including the approver's name, email address, and approval date.
• Do not pass the Assignee and Reporter fields when creating tickets. Set the issue as Unassigned and display the reporter as Anonymous in the interface.
• Migrate the original assignee to a custom Original assignee field and the original requester to an Original reporter field.
• For comments left by agents, add the original comment author's details at the beginning of the comment in the following format: First & Last Name email@vanta.com
• Identify Employee Onboarding and migrate it into the ticket description.
• Format field names in the ticket description in bold.

Out-of-the-Box Migration Options for Greater Data Control

The additional migration options were used to ensure important ticket content remained accessible and easy to manage after the move. Inline images were preserved as ticket attachments, while custom tags helped identify and organize migrated records.

• Migrate inline images as ticket attachments: Transfer images embedded directly in ticket content as separate ticket attachments, so they remain accessible after migration.
• Add a new tag: Tag tickets based on the Group field. If no group is specified, add the migrated-no group tag. Add the FS- prefix to all these tags.
• The Premium Support Package: included re-migration, which was exactly what the Vanta team needed. After completing all the required customizations and initial testing, re-migration allowed them to perform the final transfer with no errors.

Result: A Unified JSM Platform with Historical Data Intact

We now have one unified platform instead of juggling systems, better reporting and automation, and searchable historical tickets in the new portal. There was a normal adjustment period post-launch, but nothing major — mostly expected cleanup.

Feedback

"End-to-end, from discovery to full cutover, the project ran a few months. We went live on JSM itself in early September, then did the historical ticket migration with Help Desk Migration afterward. It took a little longer than our original target date, but the extra time went toward getting the mapping right rather than rushing — worth it in hindsight.

I'd recommend Help Desk Migration to other teams doing a similar move. The team was responsive and made a genuinely complex historical migration feel manageable."

Janiece Caldwell
Lead IT Operations, Corporate Engineering at Vanta

Written by

Kvitoslava Martsynyshyn

Content Marketing Manager, Help Desk Migration

Kvitoslava is a Content Marketing Manager, driving marketing for Help Desk Migration. She creates comprehensive guides, checklists, and landing pages, adapting technical migration processes into clear, value-driven messaging.