How to Get Your ITSM Data Migration-Ready Before You Move to JSM

[#1]

If you've spent any time in the ‘New to JSM’ threads here, you've seen the pattern: someone posts ‘migrating from [ServiceNow/Zendesk/Freshservice] to Jira Service Management, where do I start?’ and the replies pile up fast. Here's the thing most of those threads eventually land on — the tool you pick matters less than most people assume. The real pain almost always comes from data that wasn't ready to move in the first place.

One quick note before we get into it: Atlassian’s Jira Cloud Migration Assistant now supports Jira Service Management projects, users, groups, and customers. However, it only works for Jira-to-Jira migrations, such as Server or Data Center to Cloud, or Cloud to Cloud moves. If you’re migrating from platforms like ServiceNow, Zendesk, or Freshservice — which is the case for many teams adopting JSM for the first time — Atlassian’s native tool won’t help. In those situations, you’ll need a third-party migration platform, a custom API-based migration, or a managed migration service.

Either way, the preparation work below applies no matter which path you take.

1. Audit what you actually have

Before you map a single field, get a real inventory:

• Ticket/request volume (and how far back it goes)
• Every custom field currently in use — not just the ones on your main forms
• Attachment volume and rough size
• Users, organizations, and any customer/requester hierarchy
• Knowledge base articles
• Asset or CMDB records, if your source platform has them

You can't clean or map data you haven't actually counted. Most people underestimate how many custom fields have quietly accumulated over the years.

2. Decide what you're not bringing over

Not everything deserves a seat on the new platform. Look hard at:

• Stale or duplicate tickets that never got closed properly
• Custom fields nobody has touched in years
• Inactive requester accounts

Trimming this down before migration isn't just tidiness — a smaller dataset means faster validation later, and fewer surprises when you're trying to figure out why something didn't map cleanly.

3. Map your schema before touching Jira Service Management

This is the step people skip, and it's the one they regret most. Before any data moves, work out:

• Old custom fields → their JSM equivalents (some won't have a clean match — decide now, not mid-migration)
• Old statuses → JSM workflow statuses
• Priority/impact/urgency matrices, if your source and JSM don't use the same model
• Request types and queues

If you go in without this mapped, you'll end up reverse-engineering it after the fact, which is a much worse way to spend your afternoon.

4. Treat users, organizations, and permissions as their own task

It's tempting to think of this as ‘part of the ticket migration,’ but it really isn't. Customer and organization mapping, plus permission schemes, need their own planning pass — done before cutover, not improvised during it. Get this wrong, and you'll have agents or customers who can't see the tickets they should, or worse, who can see ones they shouldn't.

5. Don't forget the non-ticket data

It's easy to build a mental model of ‘migration = tickets,’ and then discover late that you also needed to move:

• Knowledge base articles
• Asset/CMDB records
• SLA definitions
• Attachments tied to closed tickets

None of these show up if you're only thinking about the request queue.

6. Test with a small batch first

Whatever tool or approach you use, don't run the full migration cold. Move a small batch first and check that ticket ↔ comment ↔ user relationships actually survived the trip — this was consistently the top concern in the threads discussing ServiceNow-to-JSM moves. If comments get orphaned or attachments detach from their parent ticket in a 20-record test, you want to know that now, not after 40,000 records have moved.

Quick recap

1. Audit your data, including tickets, custom fields, attachments, users, organizations, knowledge base articles, and assets.
2. Clean up your data by removing outdated tickets, unused custom fields, and inactive user accounts before migration.
3. Map custom fields, statuses, priorities, request types, and other key data to their Jira Service Management equivalents before you migrate.
4. Plan user, organization, role, and permission mapping as a separate phase of the migration.
5. Make sure your migration includes knowledge base content, assets, SLAs, and attachments — not just tickets.
6. Run a test migration with a small batch of dataset, then verify data accuracy and relationships before performing the full migration.

Curious what this community has run into: what data type gave you the most trouble when you migrated into JSM? Custom fields, attachments, permissions, something else entirely? Drop it below — genuinely trying to figure out if there's a pattern here or if everyone's horror story is different.