Fra Jira Service
Management til Zendesk
Ekstern kundeservice i Zendesk – og Jira, hvor udviklingen hører hjemme
Jira is built for the people who build. Not for your customers
Jira Service Management is strong for internal IT and ITSM. Change, incidents, problems, assets and a tight link to engineering make a lot of sense when your users are colleagues.
It gets harder when the same processes have to meet external customers. The portal is form-based, the tone turns technical, self-service and AI aren't built for a customer base, and reporting talks about issues rather than customer experience.
So the typical outcome isn't a switch but a split: external customer service moves to Zendesk while Jira keeps the internal and engineering-adjacent work. The two are connected so a customer ticket can hang off a development task without sending the customer into Jira.
Why move external support out of Jira?
The typical arguments
The customer experience in the portal
Customers want to send an email or a message – not fill in a request type with mandatory fields. Zendesk meets them where they are.
Self-service and AI
Zendesk Guide and AI agents are built to deflect contacts from a broad customer base. Confluence is built for internal knowledge.
Channels beyond forms
Chat, messaging, social and voice belong in a customer service platform, not in an issue tracker with a layer on top.
Customer service reporting
Response times, backlog, CSAT, channel mix and agent load are different questions from sprint velocity and issue statistics.
What can be migrated?
How JSM objects translate into Zendesk
Requests and issues
Tickets
Customer-facing requests move. Internal engineering work usually stays in Jira where it belongs.
Request types
Ticket forms and fields
Often a chance to cut back. Customers rarely fill in 12 fields voluntarily.
Customers and Organizations
Users and Organizations
Customers move to Zendesk where they don't consume Jira licences.
Queues
Views and routing
JQL-based queues become views with conditions plus routing rules.
SLA goals and calendars
SLA policies and business hours
The model is simpler in Zendesk. Complex calendar logic gets deliberately simplified.
Confluence knowledge base
Guide / Help Center
Customer-facing articles move. Internal articles can stay in Confluence and be surfaced to agents via integration.
How a migration works
Five phases where you know exactly what happens when
Mapping
We review your current setup: channels, volume, workflows, integrations and the habits that aren't written down anywhere.
Designing the Zendesk setup
We design fields, forms, groups, SLAs and automations around your processes – not around a standard template.
Test migration
We move a subset of the data first so you can see and approve the result before we touch production.
Full migration and go-live
We run the full move, switch the channels over and are on hand the day you go live.
Training and adjustment
The team is trained before go-live, and we adjust views, macros and rules in the weeks after, once daily use shows what is missing.
What usually causes trouble
What needs a decision rather than a configuration
The line between internal and external
Decide what is customer service and what is IT or engineering. Without a clear line you end up building the same thing twice.
ITSM features don't map one to one
Change management, problem management and CMDB don't exist in the same form in Zendesk. If you genuinely need them, Jira stays – for those processes.
The link to engineering has to work
Agents must be able to link a customer ticket to a Jira issue and see status without leaving Zendesk. That is integration work, and it belongs in the plan from the start.
Portal URLs and logins
Customers have bookmarks and logins for your JSM portal. Redirects and a clear message to customers before go-live save you a pile of confused tickets.
Why migrate with Available?
We have moved customer service departments between systems long enough to know that data is rarely what derails a project. It is the decisions nobody made along the way: who owns the customer, what should we stop doing, what do we do with the 400 macros nobody uses.
So we spend as much time on your processes and your team as on the move itself. A migration is the best opportunity you will get to clean up – and the worst one to waste copying old mess into a new system.
Connecting cables and hearts.
Frequently asked questions
Explore more
Related pages that can take you further
Should customer service move out of Jira?
We help draw the line between internal IT and external customer service – and build the link so both still hang together.
Contact usSee all migrations to Zendesk