Freshservice to Jira Service Management Migration: Tickets, Assets, Knowledge Base, and What Breaks

A Freshservice-to-JSM migration looks, on paper, like the easier cousin of a Zendesk migration. Both tools are ITSM platforms. Both have incidents, service requests, changes, problems, a CMDB, and a knowledge base. Surely it's a like-for-like move?

It isn't, and the reason is exactly that similarity. When a team moves off Zendesk, everyone expects to rebuild the ITSM layer. When a team moves off Freshservice, they expect everything to "just map" - and then discover that Freshservice's modules, statuses, asset model, and automation engine are opinionated in ways JSM doesn't share. The tickets are the easy part. The asset relationships, the service catalog, the change lifecycle, and the internal notes are where these projects succeed or fail.

I've led ITSM migrations at several companies over the years. This article is built around the most recent one: a Freshservice-to-JSM move for a global company of about 1,000 employees, with 13 agents - seven on the service desk and six in IT infrastructure and security - and three years of Freshservice history behind them. In practice that meant roughly 25,000 tickets and a few thousand hardware asset records, before counting anything a discovery agent had collected.

The reason for the move wasn't dissatisfaction with Freshservice. It was consolidation: the company already ran Confluence and Jira Software for its development teams, and having IT on a separate platform meant separate licensing, separate identities, and no clean way to link an incident to the engineering work that fixed it. We planned two months for the project, including full documentation and training for the IT team and for employees, and we delivered on that date. Here's how, with screenshots from both sides showing where the real work is.

Start with the inventory: Freshservice has more modules than you think

Freshservice's admin console is organized around ITSM processes, and over the years every one of those sections quietly accumulates configuration. Before anyone exports anything, I walk through each section with the service desk lead and write down what's in use.

A few of these deserve special attention because they have no direct JSM equivalent:

• Priority Matrix. In Freshservice it's a grid in the admin console: urgency down one side, impact across the other, and each cell sets the resulting priority automatically - Low urgency and Low impact gives Low, High and High gives Urgent, and so on. JSM has no equivalent screen. You build it yourself: Impact and Urgency fields on the request, and an automation rule that runs when a work item is created or either field changes, with one condition branch per combination that sets Priority. Write the matrix down as a table first and build the rule from the table. If your SLAs depend on calculated priority, that rule has to be working and tested before go-live, or every new incident lands on the default priority and the wrong SLA clock.
• Business Rules for Forms and Closure Rules. Conditional form logic and "can't close until…" rules. In JSM these become form conditions, workflow validators, or automation - three different places, so decide per rule.
• OLA Policies and XLA Policies. JSM SLAs can model internal targets, but XLAs (experience-level agreements) don't have a native equivalent. Decide whether you keep measuring them or move that to survey reporting.
• Journeys and Employee Offboarding. Multi-step, multi-team processes. These usually map to JSM request types with automation creating linked work items, and they're worth redesigning rather than copying.

Tickets: getting them out of Freshservice

Freshservice exports tickets to CSV or Excel from the ticket list, but the standard export contains ticket-level fields - not the full conversation, and not service request item fields. It's also capped at 10,000 tickets per export. Freshservice's account-wide XML export does include full conversations, but for a real migration you'll be using the Freshservice API, and that has a practical consequence worth knowing: Freshservice's public APIs are rate-limited per minute, and Freshworks runs an approval process for data migration partners that raises the limit during a migration window. If you're using a migration vendor, ask whether they're an approved partner. It can be the difference between a weekend and a week.

On the project I'm describing, we didn't request the raised limit. Our volume and our two-month timeline made the standard limits workable, and the time it cost showed up in how long each run took, not in the schedule. On a larger instance or a tighter cutover window, I'd ask for it at the start.

It's also worth knowing exactly what the built-in export gives you before anyone promises it'll do. In the ticket list, the export dialog lets you pick the fields to include and a date range, and that's essentially it: ticket-level fields only, up to 10,000 tickets per export, with no conversation thread and no requested-item values from catalog forms. It's useful for counting and for reconciliation. It's not a migration source.

The other thing that makes Freshservice history valuable - and dangerous - is private notes. Freshservice technicians work in them constantly:

Keep that screen in mind for the next section.

Tickets: the CSV importer, and what it tells you

JSM doesn't have a native Freshservice connector. The built-in option is Jira's External System Import, using CSV. I prepared an export of real Freshservice tickets - incidents and service requests, including the one above with its private notes - and took it through the importer as far as the final confirmation screen.

Field mapping is familiar territory:

The value mapping screen is where Freshservice-specific problems show up:

1. "All internal comments will become public." Every private note from the ticket above would become a public comment, visible to the requester in the JSM portal. For Freshservice, where private notes are the working record of every ticket, this rules out the CSV importer for anything except the simplest histories. I tagged private notes with [PRIVATE NOTE] in the file, which makes them identifiable - it doesn't make them private.
2. Ticket types don't match. Freshservice's "Incident" and "Service Request" aren't recognized, and the importer offers to create new issue types with those names. Don't. JSM already has its own Incident and Service Request work types, tied to the right workflows and request types. Creating duplicates gives you two "Incident" types with different behavior, and it breaks queues, SLAs, and reports quietly.
3. Priorities don't match exactly. Low and Medium line up, but Freshservice's "Urgent" doesn't exist in JSM's default scheme. Map it to Highest rather than adding a new priority.

Freshservice's default statuses map cleanly to JSM's - in my file, Open, Pending, and Resolved all matched automatically, which is a pleasant change from other migrations. Custom statuses you've added in Freshservice won't, so check them one by one, along with Closed if your export includes it.

A few more things I always do:

• Keep the Freshservice ID. Freshservice ticket numbers carry a prefix - INC-101, SR-99 - that people remember and reference in emails and documents. Create a "Legacy Freshservice ID" field in JSM before import and map to it.
• Set the request type - by ID. Imported tickets don't get a JSM request type automatically, which means they don't show properly in the customer portal. You can set it in the import, but not by name: the importer needs the request type's ID, the number after request-type/ in the address bar when you open the request type in space settings. The alternative is a bulk edit afterward. Either way, log in as a real customer before go-live and check that their old requests are there.
• Get the comment format right. Author and date only survive if each comment cell follows the importer's exact pattern, with the author identified by their Atlassian account ID rather than their name. Prove it on a small test import, or the whole history arrives written by the admin on import day.
• Plan the identity mapping. The importer matches Reporter and Assignee by email address or Atlassian account ID, and it can create Jira users from them - but not in every setup, and portal-only JSM customers behave differently. Decide who should exist as an agent and who as a customer, and verify it on the test import.

I stopped at this screen; nothing was imported. That's how every first dry run should end - with a screenshot of the mapping reviewed by the service desk lead before any data is created.

Active tickets and history don't have to go to the same place

The decision that simplified this project more than any other was splitting the data. Open tickets were migrated into the live JSM service space, where agents carried on working them. Closed tickets - three years of them - went into a separate Archive project, set to read-only and kept purely as a record. We did the same with change history: past changes and their CAB approvals went to the archive, and the live change process started clean in JSM.

The benefits were bigger than I expected. The live service space never had to accommodate legacy statuses, old categories, or retired request types, so its workflows, queues, and SLA reports were built for how the team works now, not how it worked three years ago. The archive project got a deliberately simple workflow that accepts every legacy status as it was, and a permission scheme that lets people browse and search but not edit. With the Legacy Freshservice ID field on both, anyone looking for "that ticket from last year" finds it in seconds - and nobody's SLA dashboard is polluted by history. Employees could still see their old requests in the portal, read-only - they just couldn't reply to them or reopen them.

When to use a migration tool instead

For a service desk with years of history, I use a dedicated migration service - usually alongside our own scripts. On this project we combined both: Help Desk Migration for the tickets, conversations, and attachments, and in-house scripts for the parts that needed our own logic - user mapping, the asset and relationship loads, and the validation checks after each run. Help Desk Migration is listed on the Atlassian Marketplace for Freshservice to JSM and moves tickets with full history, private notes as internal comments, attachments, requesters, agents, departments, changes and problems, and knowledge base articles into Confluence. Tools like this work API-to-API, which also solves the attachment problem - Freshservice attachment URLs aren't generally reachable by Jira's importer without authentication.

One thing to ask any vendor before you start: how they handle notifications. Migrating tickets through the Freshservice API can trigger Freshservice's own notifications and automations, and creating tickets in JSM can trigger JSM's. Disable outbound notifications on both sides during the migration window, or your users get a flood of emails about tickets from three years ago.

Assets: this is the part that decides the project

The CMDB is where Freshservice and JSM differ most, and it's the part I spend the most planning time on.

In Freshservice, assets live in a built-in inventory organized by asset type:

In JSM, assets live in Assets, which is object-schema based. Instead of a fixed inventory with asset types, you design schemas with object types, attributes, and - critically - references between objects.

That difference drives the whole asset migration:

• Design the schema first. Decide your object types - Employee, Location, Vendor, Laptop, Monitor, Software License - and their attributes before importing anything. Freshservice's asset types are a starting point, not a design.
• Import in dependency order. A laptop's Owner is a reference to an Employee object, so Employees must exist before Laptops. My usual order is Locations and Vendors, then People, then hardware and software, then relationships.
• "Used By" becomes a reference. In Freshservice it points to a user. In Assets it should point to an Employee object, which you'll usually sync from your directory rather than import from Freshservice.
• Relationships need rebuilding. Freshservice's CI relationships and impact views don't carry across as-is. Export them and recreate them as references in Assets, or you lose the impact analysis you relied on during incidents.
• Ticket-to-asset links need re-linking. Associations between Freshservice tickets and assets don't survive a CSV import. If that history matters, your migration tool or script has to reconnect tickets to Assets objects after both are loaded.

Once the references are in place, Assets gives you back that picture - the object graph shows each object with everything it points to and everything that points to it:

Assets has its own importer - CSV, JSON, discovery, and external app imports - configured per schema:

The dependency order becomes very concrete in the attribute mapping. Here's a computers export from Freshservice mapped to the Laptop object type:

The failure I see most often in Freshservice-to-JSM migrations isn't in the tickets at all - it's right here, in asset ownership. Freshservice's "Used By" points at requesters, and three years of history means a long tail of people who have left, contractors who were never in HR, and shared accounts. If those people don't exist as Employee objects before you import computers, the importer can't resolve the reference, and the laptop arrives with an empty Owner field. Nothing errors. It typically surfaces in the dry run, if you check - or weeks later, when someone runs an "unassigned laptops" report and gets a number nobody can explain. The fix is boring: import people first, decide explicitly what to do with leavers, then import hardware - and after every run, count the laptops with no owner.

A licensing note that changed the math on several projects: Assets used to require JSM Premium. It's now available on Standard plans and above, with an object allowance that grows with the tier.

Check your object count against your plan's allowance before you import. A Freshservice inventory with discovery agents running can hold far more records than anyone expects - and much of it may not be worth migrating.

Service catalog: rebuild, don't migrate

Freshservice's service catalog is one of its strengths: categories, items, custom variables per item, and approval workflows.

In JSM, the closest equivalent is request types, grouped into portal groups, each with its own form:

I don't migrate catalog items one-for-one. Freshservice catalogs tend to have an item per product - one for Illustrator, one for InDesign, one for Premiere - and each item carries its own custom variables: a license-type dropdown, a "business justification" text box, a cost center, sometimes a manager-approval checkbox. Open three of them side by side and you'll usually find the same four variables built three slightly different ways.

In JSM that becomes a single "Request new software" request type. Instead of a dropdown that someone has to maintain by hand, the form gets an Assets field - "Which software do you need?" - that lists the approved titles from a software catalog object type in Assets. Adding a new title becomes an Assets update, not a form change, and every request is linked to the object it's about, so reporting on demand per title comes for free. The other variables become ordinary fields on that one form, defined once.

The consolidation is significant. In an organization of around 1,000 people, it's common to see 60 to 100 catalog items after a few years, and for those to collapse into something like 15 to 25 request types. Fewer request types, better data, simpler reporting - and a portal employees can actually navigate.

Historical service requests also lose their requested item fields in any CSV-based export - the values users filled in on the catalog form. If those matter for audit (who requested which license, with which justification), make sure your migration method captures them, or export them from Freshservice analytics before switch-off.

Knowledge base: Solutions move to Confluence

Freshservice's knowledge base - Solutions - is organized into categories and folders, with folder-level visibility, drafts, version history, approval workflows, and review dates.

In JSM, the knowledge base is Confluence:

What to plan for:

• Categories and folders become Confluence spaces and page trees. Decide the structure before migrating.
• Visibility changes model. Freshservice folders can be visible to everyone, logged-in users, agents only, or specific departments. In Confluence, it's space and page permissions plus how the space is shared with JSM customers. Get this wrong and an agents-only runbook ends up in the customer portal.
• Drafts, versions, approvals, and review dates don't carry across. Migrate published content, and treat the review dates as a checklist for a content cleanup rather than something to preserve.
• Internal links and embedded images still point to Freshservice after migration. Use a tool that rewrites them, then run a link check before go-live.

Workflows and automation: rebuild on purpose

Freshservice's Workflow Automator is a visual, node-based engine, and its change lifecycle enforces rules on every transition.

None of this migrates. In JSM, the logic splits across three places: workflows (statuses, transitions, approval steps, validators), automation rules (routing, notifications, field updates), and SLAs. That split is actually cleaner once it's built, but it means each Freshservice workflow has to be taken apart and reassembled.

My approach: list every active Workflow Automator flow, write down in plain English what it does, and rebuild from that description - not from the flow diagram. Flows accumulate branches for edge cases that no longer exist. Rebuilding from intent almost always produces fewer, simpler rules.

What breaks (my Freshservice-specific checklist)

• Private notes become public with the CSV importer. Use a migration tool for any history with meaningful notes.
• Ticket types "Incident" and "Service Request" aren't recognized; the importer offers to create duplicates. Map to JSM's existing work types.
• Urgent priority doesn't exist in JSM's default scheme. Map it, don't create it.
• Standard exports skip conversations and requested item fields, and cap at 10,000 tickets. Plan on the API.
• API rate limits stretch timelines. Use an approved migration partner or plan for the limits.
• Notifications fire on both sides during migration unless you disable them.
• Legacy ticket IDs (INC-, SR-, CHN-) need a dedicated field.
• Imported tickets have no request type unless you import the request type ID - not the name - and they don't show properly in the portal.
• Comment authors and dates collapse to the importing admin and import day if the format or the author account ID is wrong.
• Identity mapping - decide how agents and customers are matched, and test portal customers separately.
• Assets need a schema and an import order; "Used By" becomes a reference; relationships and ticket links must be rebuilt.
• The service catalog, Workflow Automator, change lifecycle, SLA/OLA policies, priority matrix, and closure rules don't migrate at all.
• Knowledge base visibility, drafts, versions, links, and images need deliberate handling in Confluence.
• Assets with no owner after import, when "Used By" points at people who don't exist as Employee objects. Count them after every run.
• Marketplace apps and integrations (identity, device management, portal) need purchasing time. List them in week one.

Proving it worked: acceptance criteria

A dry run tells you the import works. It doesn't tell you the migration succeeded. Before the historical run, agree on acceptance criteria with the service desk lead, and reconcile Freshservice against JSM after every run:

• Ticket counts by type, status, and year, across the live space and the Archive project together. Incidents, service requests, changes, and problems, side by side. Any gap has to be explained, not rounded off.
• Comments, split into public and private. If private notes arrived as public, or disappeared, this is where you see it.
• Attachments. Count and total size in source and target, and open a sample by hand.
• Orphans. Tickets with no reporter, no request type, or no Legacy Freshservice ID. The target number is zero.
• Assets. Object counts per type against the Freshservice inventory, devices with no owner (the target is zero), and a sample checked for the right Owner, Location, and Vendor references.
• Knowledge base. Article count per folder, a clean broken-link report, and every agents-only article confirmed invisible from a customer account.

If a criterion fails, the run fails. Fix it and repeat.

How I run the cutover

This is the plan from the project above - two months end to end, and it held. The durations will differ for your organization; the order is what matters:

1. Inventory and retire (weeks 1-2). Every admin section, every workflow, every catalog item, every asset type - and every integration and Marketplace app the new setup will need. Decide what not to bring.
2. Design Assets and build JSM (weeks 2-6). Asset schema, workflows, request types, fields including legacy IDs, queues, SLAs, automation, the Archive project, Confluence KB structure.
3. Load Assets first (week 6). Locations, vendors, people, then hardware and software. Validate against Freshservice counts, and check for assets with no owner.
4. Dry run with real tickets (week 6). A few hundred tickets including your ugliest ones. Review as an agent and as a customer in the portal, and run the acceptance checks above.
5. Historical migration into the Archive project (week 7), with notifications disabled on both sides, then reconciled against the acceptance criteria.
6. Documentation and training (weeks 6-8). Runbooks for the IT team, short guides and sessions for employees on the new portal. We kept this inside the two months, not after go-live - it's the first thing that gets squeezed, and the main reason adoption stalls when it is.
7. Delta and cutover (a weekend). Move the support email, migrate open tickets into the live space, freeze Freshservice to read-only.
8. Keep Freshservice read-only for 60-90 days. Someone will need to look something up.

What I'd do differently

Bring procurement and the application owners in during the first week, not when you need them. We needed Marketplace apps to connect JSM to Okta and Intune, and Refined for the portal - and none of that was in the original plan. Each one meant a purchasing cycle, and those cycles don't run on a project's timeline. We absorbed the delay by re-sequencing the plan and still made the date, but it was avoidable. Now the inventory in week one includes a list of every add-on and integration the target setup needs, and procurement sees it the same week.

Where this is heading

Migration between ITSM platforms is less of an ordeal than it was a few years ago. API-to-API tools preserve notes and attachments, and JSM's decision to bring Assets to Standard plans removed what used to be one of the biggest cost obstacles for teams coming from Freshservice, where the CMDB was always included.

But the lesson from this project - and from the migrations I've led elsewhere - is the same: the tools are both ITSM platforms, and that's exactly why the migration needs care. They model the same processes differently. Treat the move as a redesign of your service catalog, your asset model, and your automation - informed by years of Freshservice data about what your team actually does - and you end up with a cleaner service desk than the one you left.

---

References: Exporting tickets - Freshservice Support · Migration via public APIs for Freshservice data migration partners · Import data from a CSV file - Atlassian Support · Set the request type when importing from CSV - Atlassian Support · Freshservice to Jira Service Management - Atlassian Marketplace