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 migrations in both directions between these platforms. This is how I approach Freshservice to JSM, 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. Freshservice derives priority from urgency and impact. JSM can do this too, but only with an automation rule or a lookup. If your SLAs depend on calculated priority, you need that logic working before go-live.
• 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.

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.

When to use a migration tool instead

For a service desk with years of history, I use a dedicated migration service. Help Desk Migration, for example, 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.

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

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. In JSM that becomes a single "Request new software" request type with a dropdown - or, better, an Assets field pointing at your Software License objects, so the request is linked to the license pool automatically. Fewer request types, better data, simpler reporting.

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.

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. 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, and a sample of devices 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

Treat the durations below as an example, not a standard: more volume, more integrations, or a bigger asset inventory will stretch them, and a small, simple instance can go faster. The order is what I'd keep:

1. Inventory and retire (weeks 1-2). Every admin section, every workflow, every catalog item, every asset type. 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, Confluence KB structure.
3. Load Assets first (week 6). Locations, vendors, people, then hardware and software. Validate against Freshservice counts.
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 (week 7), with notifications disabled on both sides, then reconciled against the acceptance criteria.
6. Delta and cutover (a weekend). Move the support email, migrate the delta, freeze Freshservice to read-only.
7. Keep Freshservice read-only for 60-90 days. Someone will need to look something up.

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 every Freshservice-to-JSM project I've been part of 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