The problem: fragmented support operations
The customer was managing support and service operations across multiple tools. Users did not have one clear place to request help, service history was spread across platforms, and leadership could not easily see demand, SLA health, backlog, or workload across teams.
| Challenge | Business impact |
|---|---|
| Multiple ticketing tools | Users did not have one clear place to request help. |
| Fragmented history | Tickets, comments, attachments, and service context were spread across platforms. |
| Inconsistent workflows | Each tool had its own statuses, fields, categories, and routing logic. |
| Reporting gaps | Leadership could not see full service demand, SLA health, backlog, or channel trends in one model. |
| Manual triage | Agents spent avoidable time classifying, assigning, and routing requests. |
| Limited AI readiness | Knowledge and ticket data were not structured for AI-assisted search, summarization, or self-service. |
The target: service transformation, not just data import
AtlasOptima designed the migration around the future-state service model. The goal was to consolidate support tools into Jira Service Management while improving intake, workflow consistency, knowledge quality, automation, and reporting.
Centralized portal
One front door for employees and support requesters.
Clean request catalog
Standardized request types across IT and business service teams.
Migrated history
Relevant tickets, users, comments, attachments, and metadata moved where required and feasible.
Workflow standardization
Legacy status patterns consolidated into fewer, clearer Jira Service Management workflows.
Knowledge integration
High-value support knowledge moved or rewritten for Confluence and JSM self-service.
Automation
Routing, priority setting, notifications, escalations, and SLA handling rebuilt in JSM.
Reporting
Dashboards for ticket volume, backlog, SLA performance, workload, and channel trends.
Migration mapping model
Freshdesk and Zendesk data was mapped into JSM before migration execution. The mapping separated fields that should become operational workflow data from fields that should become labels, custom fields, comments, or preserved attachments.
| Source field | JSM target |
|---|---|
| Ticket subject | Summary |
| Ticket description | Description |
| Requester | Reporter or customer |
| Agent | Assignee |
| Group or team | Component or team field |
| Status | Workflow status |
| Priority | JSM priority |
| Category or type | Request type or custom field |
| Tags | Labels |
| Internal notes | Internal comments |
| Public replies | Customer-visible comments |
| Attachments | Attachments where technically feasible |
Implementation phases
Discovery and migration assessment
- Reviewed Freshdesk, Zendesk, and internal support channels for ticket types, statuses, fields, automations, users, comments, attachments, and articles.
- Separated historical archive needs from records that still carried operational value.
- Confirmed which support teams and requester groups needed to use JSM at go-live.
Future-state JSM design
- Designed JSM project structure, request types, forms, workflows, queues, permissions, SLAs, and reporting.
- Mapped incident, service request, access, change, and problem flows into a smaller set of standardized workflows.
- Aligned portal intake with service ownership instead of copying legacy ticket categories as-is.
Data mapping and migration
- Mapped source fields into JSM targets before migration execution.
- Standardized priorities, statuses, tags, categories, and requester identity where direct copying would preserve legacy noise.
- Moved comments and attachments where export/API method and business value supported the effort.
AI-ready ITSM enablement
- Reworked high-value knowledge articles for Confluence/JSM knowledge use.
- Structured request types and categories to support AI-assisted search, summarization, and request classification.
- Created a cleaner foundation for Atlassian Intelligence and Rovo-assisted service operations.
Before and after
| Area | Before | After |
|---|---|---|
| Tools | Freshdesk, Zendesk, and fragmented support channels. | Centralized Jira Service Management model. |
| Ticket history | 45,000 legacy tickets spread across tools. | Around 28,000 relevant tickets migrated into JSM. |
| Request intake | Inconsistent ticket forms and categories. | Approximately 40 standardized request types. |
| Workflows | 18 inconsistent legacy status/workflow patterns. | 6 cleaner JSM workflows. |
| Knowledge | 120 articles reviewed across legacy sources. | 75 high-value articles migrated or rewritten. |
| Routing | Manual triage and assignment. | 25+ automation rules for routing and escalation. |
| SLAs | Tool-specific or inconsistent SLA logic. | 12-15 standardized SLA policies. |
| Reporting | Fragmented reporting across systems. | Unified dashboards for service performance. |
| AI readiness | Data not structured for AI or self-service. | AI-ready portal, request catalog, and knowledge base. |
AI-ready ITSM enablement
Once JSM and Confluence were structured properly, the customer had a stronger foundation for AI-assisted knowledge search, ticket summarization, request classification, knowledge gap detection, and agent support. This depended on better request taxonomy and cleaner knowledge content, not only enabling AI features.
AI-assisted knowledge search
Help users find answers before submitting tickets.
Ticket summarization
Help agents understand longer issue histories faster.
Suggested responses
Improve reply consistency and response speed.
Request classification
Reduce manual triage and routing effort.
Knowledge gap detection
Identify repeated issues that need better documentation.
Rovo and Atlassian Intelligence readiness
Make service data easier to discover across Jira and Confluence.
What similar teams should validate before migrating
Helpdesk migration planning should clarify operating-model decisions before data movement. If those decisions are skipped, the new JSM environment can inherit the same fragmentation under a different tool name.
Which tickets actually need to migrate, and which records should remain as historical archive only?
Which requester identities, organizations, groups, and teams need to map into the JSM operating model?
Which legacy statuses should become workflow statuses, and which should become labels, categories, or reporting fields?
Which comments and attachments have enough operational value to justify migration effort?
Which knowledge articles should be rewritten before they become AI-searchable self-service content?
Which SLAs and automation rules should be rebuilt natively instead of copied from legacy tools?
Which dashboards must be available at go-live for volume, backlog, SLA performance, workload, and channel trends?