Migrating from Jira Service Management without breaking engineering

Jira Service Management migrations have a property the others do not: Jira is not going away. Engineering will keep planning sprints and tracking issues there, and it should. What is moving is the service desk — the intake, triage, and resolution of requests — which lives better in a tool built for queues than in one built for projects.

That makes the first step a boundary decision, not an export. Write down what stays (engineering issues, sprint boards, the backlog) and what moves (request intake, the support queue, SLAs, on-call-adjacent triage). Every later question — what to export, what to integrate, what to retire — resolves against that line.

Preserve the escalation link across the boundary

The reason teams put their service desk in JSM was one feature: a support request could link to an engineering issue in the same system. If the migration severs that, you have made the queue nicer and the escalation path worse — a bad trade.

So the non-negotiable requirement for the destination is a real Jira integration: a support ticket escalates into a linked Jira issue, status flows back, and the requester-facing ticket closes when the engineering fix lands. Test this path with real tickets during the parallel run before cutover, not after. FlowTux treats this as a first-class flow — tickets link to the repo and to Jira issues, and for the engineering-adjacent share of the queue, triage grounded in the codebase often resolves or diagnoses the issue before it needs a Jira escalation at all.

The export, and what to do with configuration

Pull moving tickets via JQL over the REST API: issues with comments, custom fields, request types, and SLA data for the projects crossing the boundary. Same history rule as any migration — import the recent window that grounds triage and duplicate detection, archive the rest read-only.

JSM configuration — request types, portal forms, automation rules, workflow schemes — exports as documentation of intent only. The request-type list tells you what your intake actually needs to ask; the automation rules tell you what your team wished were automatic. Neither should be rebuilt mechanically: routing and priority rules are superseded by AI triage, and the twelve-status workflows that accumulated in Jira are usually the first thing teams are relieved to leave behind.

The portal problem

JSM intake usually runs through the customer portal, and portals have a compliance problem: people do not use them. The migration is a chance to move intake to where requesters already are — Slack, Teams, email — with the portal surviving as one channel among several rather than the front door.

Expect intake volume to rise slightly after this change. That is not new demand; it is previously-invisible demand that portal friction was suppressing into DMs and shoulder-taps. Rising filed volume with falling side-channel requests is the migration working.

Cutover, and the underconfiguration feeling

The mechanics are standard: two-week parallel run, new requests to the new tool, open JSM tickets drain in place, intake redirected at the source. One JSM-specific addition: leave a signpost automation in the old portal pointing to the new intake, because bookmarked portal URLs live for years.

And a warning worth writing down: after JSM, a purpose-built queue tool feels underconfigured for about a week. There is no workflow scheme to design, no screen configuration, no field context matrix. The instinct is to rebuild the apparatus; resist it. Give the default flow — intake, AI triage, resolve or escalate — two weeks of real volume, and add configuration only where the queue demonstrably needs it. Most of the JSM apparatus turns out to have been load-bearing for Jira, not for the queue.