How to convert a Jira Service Management ticket into a development issue without losing the thread

Don't move the ticket. Jira Service Management requests and Jira Software issues can look interchangeable from the issue list, but moving a JSM request into a development project detaches it from the customer's portal access and reply history, which is the thing you actually needed to keep. The right move is to create a separate development issue and link the two together, leaving the original service ticket exactly where the customer can still see and reply to it.

That's the short answer, and it's also what Atlassian's own community lands on every time this question comes up. Here's why moving breaks things, how the linked-issue pattern works in practice, and where it stops holding up once more than a couple of people are doing the linking.

Why moving the ticket breaks the thread

A JSM request isn't a plain issue with a different icon. It's tied to a customer's portal access, their reply notifications, and the SLA clock running against your service level agreement. A Jira Software issue has none of that machinery; it's built for engineers, not requesters.

When someone uses Jira's move-issue action to relocate a service request into a dev project, the request's connection to the reporter's portal view goes with it. On the Atlassian Community forum, longtime Atlassian expert Nic Brough puts it plainly: "you could take an issue from a JSM project and move it into a development type project for further work, but there's a big problem with doing that - you'll lose the request the customer made." The customer stops getting updates on a ticket they can no longer find, and the support agent loses the paper trail that shows what was promised and when.

A separate thread on the same forum asks the identical question a year later. That's not a one-off mistake; it's a structural trap that a fresh admin walks into every few months. The accepted answer is consistent with the first: "You don't want to move the JSM issue as that will break the connection with your customer."

The pattern: create a linked issue, don't convert

The fix both threads converge on is a linked issue, not a converted one. In the best-practice thread, the recommendation is to trigger an automation rule when an agent transitions the request into a development-needed status, so the rule "automatically creates a linked issue in the appropriate product." In the Nic Brough thread cited above, Dirk Ronsmans gives the manual version of the same idea: "create a Linked Issue in the correct software project and have that linked to the Support ticket."

Practically, this takes two steps, whether you do them by hand or automate them:

1. Create the development issue in your Jira Software project, with a summary that describes the engineering work, not the customer's original wording.
2. Link it back to the JSM request. Jira's default link types are Blocks / is blocked by, Relates, Duplicates, and Clone; for this use case Relates is the safe default unless you've defined something more specific like "is tracked by."

If you want this to happen automatically instead of relying on someone remembering to do it, Jira's automation supports it, just not as one action. The automation actions reference documents a Create work item action that opens the new issue in the target project, and a separate Link work items action that connects it back to the trigger issue. There's no single "create and link" step; you chain the two.

One ticket, start to finish

Callum Solano runs support at Palmwright Freight, a routing and dispatch platform for regional trucking companies. A customer opens JSM-914 in the portal, reporting that their dispatch board stops loading whenever a route has more than 200 stops, and it's blocking their morning planning call.

Callum reproduces it, confirms it's a real defect rather than a training issue, and knows engineering needs to look at the pagination logic. He doesn't move JSM-914. Instead, he creates PLAT-3301 in the Jira Software project:

PLAT-3301: "Dispatch board fails to render routes over 200 stops. Repro: create a route with 200+ stops, open dispatch board, page hangs on load. Reported via JSM-914."

He links PLAT-3301 to JSM-914 as relates to, and drops a comment on JSM-914 noting the linked issue number. The customer, watching the portal, still sees their original ticket move through statuses; they never see PLAT-3301 and don't need to. When Ines Marsh, the engineering lead, ships the fix two weeks later and closes PLAT-3301, Callum gets a mention on the linked issue, checks the fix, and replies to the customer from the original thread: "This shipped in today's release, the board should handle any stop count now."

The customer's whole interaction happened inside JSM-914. Nothing about their request lived, even briefly, inside a ticket they couldn't see.

Where the manual link habit stops working

The two-issue, one-link pattern is genuinely sufficient for a team where a handful of people file the development issues and everyone remembers to link back before moving on. It runs into three predictable limits as volume grows:

• The comment gets skipped. Under deadline pressure, someone creates the dev issue and forgets the "reported via JSM-XXX" comment, and the link only exists in one direction if the Link work items step gets skipped too.
• One request, several linked issues. A single customer complaint sometimes turns into two or three development issues once engineering scopes it, and keeping all of them attached to the original ticket by hand gets easy to lose track of.
• The requester disappears from the dev side. The linked issue shows "relates to JSM-914," not who's waiting on it or what company they're from. An engineer picking up PLAT-3301 six months later, after a re-prioritization, has to click through to the service ticket just to find out who asked.

That third one is the same gap we cover in how to see who actually asked for a Jira epic or story: Jira's fields track who filed a ticket, not who the request came from, and a linked-issue comment is exactly the kind of free text that erodes over time.

Where Modem fits

This is the point where a link-and-hope process stops scaling, once support and engineering are both moving fast enough that "did we link that one back" is a real question. Modem watches your connected Jira Service Management project alongside Slack, email, and your other support channels, and keeps every request, reply, and internal note attached to a topic in a context graph rather than to a single ticket field. When that topic produces development work, Modem can file the Jira Software issue itself, and the requester, their company, and the original thread stay attached to it, so an engineer working the dev issue can see who's waiting without leaving Jira or digging through comments for a ticket number. We build Modem, so weigh that against your own evaluation, but the underlying problem, connecting a customer request to the work that answers it without either side losing context, is the same one this guide has been describing by hand.

If your team is still small enough that one or two people are doing all the linking, the create-and-link habit above is the right starting point; it's genuinely enough for a service desk with modest volume. It's also worth pairing with a clear intake process on the way in, covered in best tools to turn customer feedback into Jira tickets, so what lands in JSM in the first place is already worth linking.

The first move

Pick one status on your JSM workflow, something like "Needs Engineering", and write a one-line rule for what happens when a ticket enters it: create the dev issue, link it with relates to, comment the issue number back on the service ticket. If your automation access allows it, build it as a Create work item plus Link work items rule so the habit can't be skipped under deadline pressure. Either way, the ticket that started in the customer's portal should still be sitting there when they check back, with a link attached that most of them will never need to click.