What Transfers When You Migrate from Freshdesk or Zendesk to Jira Service Management?

The first question on a helpdesk migration is nearly always about the data. Will the tickets come across? What about the attachments, and the years of comment history sitting on them?

It is a fair thing to worry about and the wrong place to start. Moving from Freshdesk or Zendesk into Jira Service Management, the data is rarely what decides the timeline. What decides it is whether the destination is ready to receive the data, because Jira validates what you are importing against the configuration that already exists and rejects what does not fit.

So the more useful question is not what moves. It is what has to exist in Jira Service Management before anything can move at all.

What Actually Transfers From Freshdesk or Zendesk to Jira Service Management?

Records transfer. Configuration does not. Tickets, comments, attachments and requester identities can be carried across. Statuses, priorities, request types, SLAs and automation rules are rebuilt natively in Jira Service Management, and the records are then mapped onto them.

That split is the whole model. It sorts every object in your helpdesk into one of three groups, and each group needs a different kind of work from a different kind of person.

Group	What is in it	What the work actually is
Move	Tickets, comments, attachments	Extract, map, load. Effort scales with volume.
Match	Requesters, agents, organizations, groups	Identity reconciliation. Effort scales with how messy the source is, not how large.
Rebuild	Statuses, workflows, priorities, request types, SLAs, automation rules, knowledge	Design. Effort scales with how many legacy variants you choose to keep.

Most migration plans budget carefully for the first group and meet the third one late. The third is the one that runs long, because it is not a data task at all. It is a set of decisions about how your service desk should work, and no import tool can make them for you.

Why Does the Target Configuration Have to Exist Before the Import Runs?

Because Atlassian's admin CSV import checks your file against the space it is importing into, and fails the rows that do not match. Atlassian's documentation on importing work into an existing space states it plainly: "You can't add new statuses, work types, custom fields, or custom field options during import. All imported data must match the existing space configuration."

That sentence is worth reading twice, because the same page qualifies it further down and the qualification changes what you have to do.

• For statuses and priorities the rule is absolute. Atlassian's wording is "You can only map to existing statuses and priorities. New ones can't be created." If your file carries a status the destination has never heard of, the import fails and you resolve it before proceeding.
• For work types, custom fields and custom field options it depends on the project type. The same page notes that company-managed projects can create these during import, while team-managed projects require everything to exist beforehand.

So the constraint is real, but narrower than "nothing can be created". Two things follow from it, and they point the same way.

The first is that your status model is a precondition, not a migration output. Whatever Jira Service Management workflows you intend to run have to exist before the first ticket lands. The second is that choosing between a company-managed and a team-managed project is a migration decision, not only an administrative one, because it changes what the importer will accept from you.

This inverts how these projects are usually planned. The instinct is to move the data first and tidy the configuration around it afterwards. The import will not allow that, and on balance it is doing you a favour: it forces the design conversation to happen while there is still time to act on the answers.

One caveat covering all of the above. It describes Atlassian's own CSV import path. Third-party migration tools behave differently, and what each one can create or carry across varies by tool. When somebody tells you a particular object will or will not migrate, ask which method that answer is about, because the answer is rarely universal.

What Does Each Freshdesk or Zendesk Object Become in Jira Service Management?

Most objects have a clear Jira Service Management equivalent. The mapping is rarely the hard part. The decision each mapping forces on you is.

Freshdesk or Zendesk	Jira Service Management	The decision it forces
Ticket	Work item in a service project	How much history moves? A rolling window, or everything ever logged?
Subject and description	Summary and Description	None. These are the clean ones.
Requester	Reporter or portal customer	Who needs a licensed agent seat and who stays a portal customer? This is a cost driver, not a technicality.
Agent	Assignee	Which legacy agents still need agent access on day one?
Organization or company	Organization	Do you need organizations at all, or does the reporter carry enough context?
Group or team	Component, team field, or its own service project	Is this a routing label, or a genuinely separate service with its own queue, owner and SLA?
Status	Workflow status	Must exist first. Which legacy statuses are real workflow steps and which are reporting labels wearing a status badge?
Priority	Priority	Must exist first. Legacy scales rarely map one to one, and four levels often behave like two.
Tag or category	Label, component, or custom field	Which tags are reporting dimensions worth keeping, and which are years of accumulated noise?
Custom field	Custom field	Does it exist in the destination yet? On a team-managed project it has to.
Public reply	Customer-visible comment	Does your chosen method preserve the public and internal distinction?
Internal note	Internal comment	The same question, with a much worse failure mode.
Attachment	Attachment	Feasible, but it depends on method and file size. Verify a sample rather than trusting a count.
Knowledge article	Confluence page linked to the service project	Which articles are worth keeping? Usually far fewer than exist.
SLA policy	Jira Service Management SLA with start, pause and stop conditions	Rebuilt, not copied. Which legacy clock rules described the service, and which described a limitation of the old tool?
Automation or trigger	Jira Service Management automation rule	Rebuilt. Which rules were solving problems that the new design removes entirely?

Two rows in that table deserve more attention than they usually get. The internal note is the first. In Freshdesk and Zendesk the boundary between a private note and a public reply is a property of the comment, and if your migration method flattens that property, internal commentary about a customer becomes visible to that customer. Test it on a sample before you trust it on a set.

The second is the group. Treating every legacy group as its own Jira Service Management project is the most common way these migrations end up harder to run than the thing they replaced. A group is only a separate service if it has its own owner, its own queue and its own commitments. Otherwise it is a field.

What Should You Map First?

Statuses and priorities, before anything else. They are the objects the import cannot create for you, and almost everything later depends on them being settled.

1. Statuses and workflows. Decide the target set, then consolidate the legacy patterns into it. The reduction is the goal, not the mapping.
2. Priorities. Agree the scale and what each level commits you to, because SLAs will hang off it.
3. Request types. Build the catalog around services people recognise, rather than porting legacy ticket categories across unchanged.
4. Identities. Requesters, agents, organizations and groups, reconciled and deduplicated before any record references them.
5. Records. Tickets, comments and attachments, which now have somewhere valid to land.
6. Knowledge. Reviewed and rewritten rather than bulk-copied, because a migrated bad article is still a bad article.
7. SLAs and automation rules. Last, deliberately. Each one depends on statuses, priorities and request types already being final.

The order is not a preference. Each step is a precondition of the one after it, so running them out of sequence does not save time. It just means doing several of them twice.

How Many Customers and Organizations Can You Import at Once?

A limit of 1,000 rows and 1MB per file, according to Atlassian's documentation, and the import updates records that already exist rather than creating new ones.

That second half surprises people, so it is worth being exact. Atlassian's documentation on importing customer and organization details states that the import "will import values into fields that already exist but it will not add new fields or import new customers or organizations." The CSV populates detail fields on customers and organizations that are already present on your site. Getting them onto the site is a separate step, and planning the two as one job is where the schedule slips.

The mechanics, all from the same Atlassian page, are worth having in front of you before you build the file:

• Split anything larger than the 1,000-row or 1MB limit into multiple files.
• Email is the required column header for individual customers. Organization Name is required for organizations.
• Every other column header has to match a custom detail field name. Any column whose header does not match is ignored, and ignored quietly.
• Save the file as UTF-8.
• Dates use the YYYY-MM-DD format.
• A ,, in a row, meant as an empty value, causes that row to fail.
• Valid fields in a row still import when other fields in the same row are invalid, so a partly wrong file gives you a partly populated result rather than an obvious failure.
• The import updates details for all customers or organizations, including ones in other projects, and any you include from another project are added to the current one.

The quiet-ignore behaviour is the one to design around. A misspelled header produces an import that looks completely successful and leaves a column of empty fields behind it, and nothing raises a flag until somebody goes looking for data that was never there. Check a sample of records after the first run instead of trusting the summary screen.

Is Jira Service Management Still the Right Destination for External Customer Support?

On new Atlassian sites, those features have moved. Atlassian's own documentation now carries the notice: "With the introduction of Service Collection in October 2025, customer service features are no longer available in Jira Service Management on new sites. These features have been moved to our new app, Customer Service Management – included in Service Collection." Existing sites are unaffected and keep what they already have. If the migration you are planning is internal employee support, which covers IT, facilities, HR and business applications, none of this changes the mapping above, which is why it sits here as a note rather than at the top of the page. If you are consolidating external customer support onto a new site, check which product your licence actually entitles you to before you design the request catalog. It is worth checking the publication date on any other guide you read about this migration, because most of them were written before October 2025 and do not mention it at all.

What Does a Migration of This Size Actually Involve?

Numbers help calibrate scope, so here are ours, with the caution that they describe one engagement rather than a typical one.

In a selected engagement, AtlasOptima helped a building automation manufacturer consolidate Freshdesk, Zendesk and several internal support channels into Jira Service Management. That engagement assessed approximately 45,000 historical tickets and migrated around 28,000 relevant records against an agreed 24-month active-history window. It mapped 500-700 requesters and was designed for 6-8 service teams, with approximately 40 standardized request types. Eighteen legacy workflow patterns were consolidated into 6 workflows. Of approximately 120 knowledge articles reviewed, 75 high-value articles were migrated or rewritten, and the build included 25+ automation rules and 12-15 SLA policies.

The figure that says the most is the workflow one. Eighteen patterns became six, which means two thirds of the legacy variation described nothing anyone needed to keep. That is normal, and it is the work the import constraint pushes you into doing at the right moment. You can read the full engagement in the Freshdesk and Zendesk to Jira Service Management migration case study.

One more reason to be strict about the knowledge base. Structured request types and clean articles are also what Atlassian's AI features read from, so the cleanup pays twice — once in a service desk people can navigate, and again if you later turn on assisted search and summarization. We have written separately about where Rovo genuinely helps and where it does not. Migrating a messy knowledge base and expecting AI to compensate is the version of this that disappoints people.

What to Settle Before You Start

Seven questions. If you can answer these, the mapping largely writes itself.

• Which history window are you migrating, and what happens to the records outside it?
• What is the target status and priority model, given that neither can be created during the import?
• Company-managed or team-managed, and does that choice match what you need the importer to accept?
• Which requesters need licensed agent seats, and which stay portal customers?
• Which legacy groups are genuinely separate services, and which are fields?
• Which knowledge articles survive the review, honestly assessed?
• Which SLAs and automation rules describe your service, rather than describing your old tool?

A migration scoped this way is not a smaller migration. It is the version where the destination is deliberately better than the origin, and the only version where the validation pass at the end is something you can actually finish.

If you are weighing up a move from Freshdesk or Zendesk, our ITSM implementation work starts with exactly this mapping, before any data moves. For a wider view of what else sits on the platform once the service desk is settled, see our Atlassian product overview. We're here when you're ready.