Migrating from Zendesk to JSM: What Happens to Feature Request History
Nothing carries over automatically. Zendesk and Jira Service Management don't talk to each other, so a switch from one to the other is an export-and-import job, not a platform toggle, and what survives that job depends entirely on which import path you use. Jira's own CSV importer can bring in labels, comments, and custom field values, but it has no built-in connector for Zendesk specifically, so someone has to get your Zendesk data into a shape it accepts first.
That gap is exactly where feature-request history goes missing. Years of tags like feature-request or fr-billing, attached one conversation at a time by support agents, don't have anywhere to land unless the migration path is built to carry them. A same-tool switch keeps everything by default. A cross-vendor one keeps only what the path was built to carry, and the honest answer is it depends which path you take.
Why there's no native switch to flip
Zendesk stores tags as a native array field on every ticket object, confirmed in Zendesk's own ticket API reference, which describes tags as "the tags applied to this ticket." That field has no equivalent waiting on the other side. Jira Service Management requests are Jira issues, and Jira issues use labels, not tags, as their closest analog, plus whatever custom fields your project defines. Nothing about that mapping is automatic, because Atlassian's own CSV import documentation describes generic field mapping into Jira, not a purpose-built Zendesk connector.
That means every migration is a mapping exercise: someone decides that Zendesk's fr-billing tag becomes the label fr-billing (or something else) on the JSM side, and that decision gets applied consistently across however many years of tickets you're carrying over. Skip that step, or run it inconsistently, and the tag survives as text but stops being a filterable field.
“we need SSO before rollout”
“any update on single sign-on?”
“SSO came up twice on this call”
Linear issue, quotes attached
insight report in NotionWhat actually transfers, depending on the path
Three paths cover most Zendesk-to-JSM migrations, and each one keeps a different slice of your history:
Jira's native CSV importer. You export Zendesk tickets via the Incremental Ticket Export API rather than the standard list endpoint, which Zendesk's own docs say isn't meant for bulk pulls, reshape that export into columns Jira expects, and import. Per Atlassian's documentation, the importer can bring in labels (one per column), comments, and custom field values, mapping to existing fields or creating new ones. It says nothing about preserving a full audit trail, so status-change history and internal-note timestamps typically don't make the trip in a recognizable form. This path works, but the reshaping step is manual and it's where tag mappings get skipped under deadline pressure.
A dedicated migration tool. Services built specifically for this move, such as Help Desk Migration's Zendesk-to-JSM tool, map tags and custom fields to JSM equivalents automatically and carry full ticket thread history, statuses, and timestamps along with the request. The same documentation is explicit about the limits: "Macros, triggers, automations, views, and SLA policy configurations do not transfer because JSM models these features differently." Those get rebuilt natively in JSM, not migrated.
Nothing at all. Some teams migrate only open tickets going forward and leave the Zendesk account live, read-only, as an archive. This is the cheapest path and also the one that quietly loses the least, because the history isn't gone, it's just stuck in a second tool nobody opens after month three.
When "we kept the export" turns out not to be enough
Thermovane sells temperature sensors and alerting to food distributors, cold-chain gear that has to keep working when a truck's refrigeration unit fails at two in the morning. When the company moved off Zendesk to JSM last spring, mainly because engineering wanted requests living next to the Jira epics they already tracked work in, the migration landed on Elena Roussos, who leads support there. She ran the CSV import path herself over a weekend, mapping the handful of tags her team used most: feature-request, fr-alerts, fr-integrations.
Two months later, a product manager pinged her in Slack asking for every time Coldline Foods had asked for custom threshold alerts. The account had a contract renewal coming up eighteen months after signing, and leadership wanted to know if the feature had been a dealbreaker before. Elena could pull everything from JSM, but that only went back to April. Before that, the requests lived in the old Zendesk export, and the tag columns hadn't come through clean: some rows carried fr-alerts, others fr_alerts, left over from before she'd standardized the taxonomy.
The tag itself made it across fine in both systems, so what broke was consistency at the boundary between them, the exact thing no export file checks for you. Elena's export had two years of tickets tagged under a taxonomy that drifted before she cleaned it up, and the CSV importer preserved exactly what was in each cell, typos included. Reconstructing the full history meant a manual pass through the old export, re-reading tickets to catch the ones the mismatched tags hid.
Fixing the past doesn't fix what starts next
Even a clean migration only solves for the past. The moment JSM goes live, new feature requests start arriving in it again, tagged by whichever agent handles the ticket, and the same drift that hit Elena's old Zendesk tags starts over on day one in the new system. A migration is a one-time event; keeping the requester and the theme attached to every ticket, in both the archive and the new tool, is an ongoing job no import script does for you.
That's the point where a system sitting above the ticketing tool, rather than inside whichever one is live this year, earns its keep. We build Modem for exactly this reason, so we're not a neutral source here, but the mechanism is straightforward: Modem connects to Jira Service Management and reads requests, replies, and status directly, clustering them into topics tied to the person and company behind each one. If you're migrating from Zendesk, Modem can also read your Zendesk history directly rather than through an export file, so a request tagged two years ago and a request filed yesterday in JSM end up in the same topic instead of split across a tool boundary that a CSV import can't see across. Switching support tools again later doesn't reset anything, because the topic lived outside either tool to begin with.
That only matters past a certain scale. A team fielding a few dozen feature requests a year can keep a clean tag taxonomy and a disciplined migration checklist, and the CSV import path above is genuinely sufficient. The gap shows up once request volume and tool changes both happen regularly enough that nobody has time to re-verify the mapping every time.
For the piece of this that isn't migration-specific, our guide on keeping Zendesk and Jira ticket status in sync covers the ongoing two-way link teams build when they run both tools at once instead of fully cutting over, and mining feedback from Zendesk tickets covers the extraction side if Zendesk is staying as your system of record.
What to nail down before you migrate a single ticket
Before running any import, write down your actual tag taxonomy as it exists today, typos and all, by pulling a tag-frequency report from Zendesk rather than trusting memory. Fix the obvious drift (fr_alerts vs fr-alerts) in Zendesk first, so the export you migrate is already clean. Then decide up front whether tags become JSM labels or a custom field, and apply that mapping to every ticket the same way, not just the ones from the last quarter. That one hour of prep is the difference between Elena's two clean systems and her one clean system sitting on top of an archive nobody trusts.
