Methodology: built from Atlassian and Zendesk product documentation, developer references and pricing pages, all checked on 29 Sep 2026. No vendor reviewed or paid for this article. We did not run hands-on tests.
A Zendesk to Jira migration moves your support history into Jira Service Management (JSM): tickets, public replies, internal notes, attachments, end users, organizations and Help Center articles. Triggers, automations, macros, views and SLA policies do not move. They are rebuilt in JSM.
You are probably here because support is consolidating onto the Atlassian stack, where engineering already works. This guide covers getting data out of Zendesk, what Jira's importer does to it, and how to plan a cutover you can reconcile.
Key takeaways
- Zendesk's export tools are not available on Team plans, and the account owner must ask Zendesk Support to enable them (Zendesk, as of 29 Sep 2026).
- Zendesk's CSV export leaves out comments, and its JSON export drops comments on tickets with more than 1 MB of data (Zendesk, as of 29 Sep 2026).
- Atlassian says all comments imported by CSV into a JSM space become public (Atlassian, as of 29 Sep 2026). Internal notes need a different load path.
- SLAs keep counting on closed issues imported by CSV, because they have no history beyond creation (Atlassian, as of 29 Sep 2026).
Why teams move from Zendesk to Jira Service Management in 2026
Beyond consolidation, these dated, vendor-sourced 2026 triggers push teams from Zendesk to JSM.
| Trigger | What the source says |
|---|---|
| Atlassian packaged external support into Service Collection | Launched 7 Oct 2025, Service Collection bundles Jira Service Management, Customer Service Management ("built for external customer support"), Assets and Rovo agents (Atlassian, as of 29 Sep 2026). Customer Service Management is included with Standard and Premium, and customers are free (Atlassian, as of 29 Sep 2026) |
| Cloud is the only new target | New customers could not buy Data Center subscriptions after 30 Mar 2026, and Data Center products, including JSM, go read-only on 28 Mar 2029 (Atlassian, as of 29 Sep 2026). See our Jira Data Center end-of-life timeline |
| Atlassian price change | New cloud list prices apply to new purchases, renewals and upgrades from 13 Oct 2026; quotes issued before then keep the old price until they expire (Atlassian, as of 29 Sep 2026) |
List prices differ, but the plans are not like for like, so compare features before treating the gap as savings. Our Zendesk vs Jira Service Management comparison covers features, and our Jira Service Management pricing breakdown covers usage limits and add-on charges.
| Plan (billed annually) | List price per agent per month | Source |
|---|---|---|
| Zendesk Suite Team | $55 | Zendesk, as of 29 Sep 2026 |
| Zendesk Suite Professional | $115 | Zendesk, as of 29 Sep 2026 |
| Service Collection (JSM) Standard | $20 | Atlassian, as of 29 Sep 2026 |
| Service Collection (JSM) Premium | $51.42 | Atlassian, as of 29 Sep 2026 |
Zendesk to Jira integration or migration?
Many "zendesk to jira" searches are about integration: Zendesk's own Jira app links tickets to Jira issues while both tools keep running (Zendesk on Atlassian Marketplace, as of 29 Sep 2026). An integration moves no history, so if Zendesk is being retired, you need a migration.
Before you start: getting your data out of Zendesk
Your Zendesk plan and export route decide how much history, including comments, you can get out. Check both before designing a mapping.
| Extraction route | What Zendesk documents | Source |
|---|---|---|
| Data export (JSON, CSV, XML) | Suite Growth and above, or Support Professional and above. Not on Team plans. The account owner must contact Zendesk Support to enable it | Zendesk, as of 29 Sep 2026 |
| CSV export | Excludes deleted tickets, ticket comments and ticket descriptions | Zendesk, as of 29 Sep 2026 |
| JSON export | Comments are left out for any single ticket with more than 1 MB of data; accounts with over 1 million tickets download in 31-day increments | Zendesk, as of 29 Sep 2026 |
| XML export | Maximum file size 500 MB, which Zendesk says is roughly 200,000 tickets | Zendesk, as of 29 Sep 2026 |
| Incremental export API | Up to 1,000 items per page (Zendesk developer docs, as of 29 Sep 2026); 10 requests per minute as standard, 30 with the High Volume add-on | Zendesk developer docs, as of 29 Sep 2026 |
| Other Support API endpoints (comments, audits, side conversations) | 200 requests per minute on Team, 400 on Growth and Professional, 700 on Enterprise; the High Volume add-on raises a qualifying plan to 2,500 | Zendesk developer docs, as of 29 Sep 2026 |
For full history with every comment, plan on the API. File exports suit counts and spot checks. Your rate limit also sets how fast extraction and the delta pass can run, so record it during discovery.
Don't lose archived tickets
Zendesk archives tickets 120 days after they reach Closed. Archived tickets drop out of views and rules, but stay reachable through search, most API endpoints and data exports (Zendesk, as of 29 Sep 2026). The List Tickets and Show Ticket endpoints don't return them (Zendesk developer docs, as of 29 Sep 2026). Extraction built on those endpoints misses older closed tickets.
Inventory what you have
Count every object, in total and per status: tickets by form, brand and type; public replies and internal notes; attachments; end users, agents and organizations; Help Center articles and translations; custom fields, forms and tags; satisfaction ratings. Count side conversations too, because Zendesk stores them apart from ticket comments (Zendesk developer docs, as of 29 Sep 2026). List triggers, automations, macros, views and SLA policies separately. That is your rebuild list.
Then decide how much history moves: all of it, everything after a cut-off, or a cut-off plus a read-only archive. Agree this with your audit and reporting owners. For a fuller walkthrough of this step, see how to audit legacy help desk data before a migration.
What moves, what gets rebuilt, what's at risk
Records move as data; configuration is rebuilt. Agree this table with support leadership before anyone writes a mapping.
| What moves (as data) | What gets rebuilt (not migrated) | What's at risk |
|---|---|---|
| Tickets as JSM work items, with subject, description, status, priority and type | Triggers and automations, as JSM automation rules | Internal notes turning public on a CSV import |
| Public replies and internal notes, with author and original timestamp | Macros, as canned responses (Atlassian, as of 29 Sep 2026) plus automation | SLA clocks restarting or never stopping on imported history |
| Attachments and inline images | Views, as JSM queues and filters | Archived tickets missed by list endpoints |
| End users as customers, agents as licensed agents, organizations | SLA policies, as JSM SLA goals and calendars | Comments missing from JSON exports on large tickets |
| Custom fields, tags (as labels), ticket forms (as request types) | Ticket forms' conditional logic, as request type forms | Incident-to-problem links flattened into plain text |
| Help Center articles, into a Confluence-based JSM knowledge base (Atlassian, as of 29 Sep 2026) | Explore reports and dashboards | Status change history, which lives in Zendesk ticket audits |
Zendesk SLA policies track seven metrics across reply, update and resolution time (Zendesk, as of 29 Sep 2026). None of those definitions or running timers move. Rebuild the ones you still need as JSM goals and keep historical SLA results as data.
Zendesk keeps a read-only audit of every change to a ticket (Zendesk developer docs, as of 29 Sep 2026). JSM history starts at import, so if auditors need status-change timelines, extract and keep the audits. Keeping that context is what data fidelity in a migration means in practice: the record arrives with its meaning, not only its fields.
Zendesk to Jira field and record mapping
Zendesk to Jira mapping translates Zendesk tickets, forms and statuses into JSM work items, request types and workflow statuses.
| Zendesk | Jira Service Management | Watch for |
|---|---|---|
| Ticket form | Request type | On CSV import, use the request type ID, not the name. Otherwise request types may not map and portal visibility can suffer (Atlassian, as of 29 Sep 2026) |
| Status (New, Open, Pending, On-hold, Solved, Closed, plus custom statuses) | Workflow statuses | Map each one, including custom statuses, to a status in your JSM workflow |
| Priority (urgent, high, normal, low) | Priority | Align with your JSM priority scheme and SLA goals (Zendesk developer docs, as of 29 Sep 2026) |
| Type (problem, incident, question, task) and problem_id | Work type and linked work items | Incidents link to a problem through problem_id; recreate these as links, not text |
| Public reply / internal note | Public comment / internal comment | Zendesk marks each comment public or internal (Zendesk developer docs, as of 29 Sep 2026) |
| Requester (end user) | Reporter (customer) | Customers don't need a license (Atlassian, as of 29 Sep 2026) |
| CCs and followers | Request participants and watchers | Watchers who don't exist in Jira are not imported by CSV (Atlassian, as of 29 Sep 2026) |
| Tags, organizations | Labels, organizations | Clean up duplicate tags before import |
| Satisfaction rating | Custom field or archive | Keep it as data for trend reporting |
Status behavior differs
Zendesk moves a Pending ticket back to Open when the requester replies, and only the system can set Closed. By default an automation closes tickets four days after they are solved, with a system fallback at 28 days (Zendesk, as of 29 Sep 2026). Rebuild the rules you rely on as JSM automation.
Internal notes need special care
A CSV import makes Zendesk internal notes public in JSM. Atlassian's CSV import documentation says that in JSM spaces, all imported comments become public (Atlassian, as of 29 Sep 2026). Internal notes often hold engineering detail and personal data. Load comments with a method that sets visibility per comment, and prove in the test migration that internal notes stay hidden on the portal.
Attachments and Help Center articles
Jira's CSV importer fetches attachments from HTTP or HTTPS URLs your Jira Cloud site can reach (Atlassian, as of 29 Sep 2026). If Zendesk attachments need sign-in, re-host them first, and count attachments per ticket before and after the load so you can prevent a lost-attachment flood at cutover. Help Center articles carry HTML bodies and translations, with attachments on a separate endpoint (Zendesk developer docs, as of 29 Sep 2026). Expect article-to-article and ticket-to-article links to change.
The Zendesk to Jira migration plan in phases
A Zendesk to Jira migration runs as a controlled change in six phases, each with an owner and a go/no-go gate. It follows the same phase model as our ITSM migration guide, and it goes best with a named project lead who owns every gate. Durations depend on volume, API limits and test runs, so none are given here (see the FAQ below).
- Discover. Run the inventory. Record counts per object and status. Confirm your plan's export and API limits.
- Map. Build the mapping for forms, statuses, priorities, fields, users and comments. Configure JSM request types, workflows, fields and queues before data arrives.
- Test migration. Load a slice with every request type, archived tickets, long threads, attachments and internal notes. Check it as a customer, not only as an agent. Jira recommends about 1,500 work items per CSV file (Atlassian, as of 29 Sep 2026) if you batch that way.
- Cutover with delta sync. Load history in advance, freeze Zendesk changes for a short window, then pick up what changed. Zendesk's incremental export returns items changed since your last request (Zendesk developer docs, as of 29 Sep 2026), which suits the delta pass. Switch email channels and portal links after the delta lands.
- Reconcile. Compare counts per object and status. Sample tickets end to end: comment order, visibility, attachments, links, organization. Record sign-off.
- Hypercare. Watch new tickets, SLA goals and automation closely. Keep Zendesk read-only until audit and reporting owners confirm they have what they need.
Fix SLAs on imported history
JSM calculates SLAs from issue history, and closed issues imported by CSV have none beyond creation, so their SLA keeps counting. Atlassian suggests excluding imported issues from SLA goals with a custom field, or bulk transitioning them to done so the SLA stops (Atlassian, as of 29 Sep 2026). Choose during mapping, not after go-live.
Common failure points
Each failure point below comes from a documented Zendesk or Jira behavior covered above, so each one can be caught in the test migration before go/no-go. For risks that apply to any help desk move, see help desk migration risks to plan for.
| Failure point | Why it happens | How to catch it in the test migration |
|---|---|---|
| Internal notes made public | A CSV load into a JSM space makes every comment public | Open migrated tickets from a customer account and confirm no internal note shows on the portal |
| SLA breaches on old tickets | Imported closed issues have no history, so their SLA keeps counting | Check SLA fields on imported closed issues and apply your chosen fix before go-live |
| Archived tickets missed | List Tickets and Show Ticket don't return archived tickets | Reconcile archived counts separately from active counts |
| Comments missing | CSV exports leave out comments; JSON exports drop them on large tickets | Compare comment counts per ticket, starting with your longest threads |
| Requests hidden from the portal | Request types set by name instead of ID | Search for migrated requests as their original requester |
| Attachments that fail | Jira Cloud can't reach the attachment URL | Compare attachment counts per ticket, source against target |
| A slow delta pass | Incremental exports run at a lower rate limit than other endpoints | Time the delta pass in a rehearsal and size the freeze window from that |
| Relationships flattened | Incident-to-problem and ticket-to-article links loaded as text | Open linked records and confirm they are real links |
Zendesk to Jira migration checklist
- Confirm export access on your Zendesk plan and get exports enabled.
- Count every object per status.
- Include archived tickets in extraction and counts.
- Agree the history scope with audit and reporting owners.
- List triggers, automations, macros, views and SLA policies for rebuild.
- Configure JSM request types, workflows, fields and queues first.
- Map ticket forms to request type IDs.
- Map every status, including custom statuses.
- Pick a comment load method that keeps internal notes internal.
- Re-host attachments that need Zendesk sign-in.
- Pick your SLA fix for imported history.
- Run a test migration and check it from the customer portal.
- Plan the freeze window, delta pass and channel switch.
- Reconcile, record go/no-go sign-off, and keep Zendesk read-only through hypercare.
Zendesk to Jira migration FAQ
Methodology
We built this guide from Atlassian and Zendesk documentation, developer references and pricing pages, all checked on 29 Sep 2026. We read the pages that rank for "zendesk to jira" to find gaps but do not cite them. Every figure names the vendor that publishes it. We did not run hands-on tests.
Disclosure: MigrateX, the publisher of this article, runs ITSM data migrations, including between platforms named here. No vendor reviewed or paid for this article.