Migrate from Jira Service Management to Freshdesk

JSM Requests map to Freshdesk Tickets on a per-project basis. Summary maps to Freshdesk subject, description maps to ticket body as HTML, priority maps to Freshdesk priority (urgent/high/medium/low), and status maps to Ticket status (open/pending/resolved/closed). We use JSM's issue key as a custom field ticket_reference__c for cross-system audit. Custom fields on the Request Type translate to Freshdesk Ticket Fields of equivalent type. The JSM issue key becomes a custom reference field on the Freshdesk Ticket for audit trail continuity.

JSM Service Projects map to Freshdesk Products, which organize Tickets by product or service line. Each JSM project portal URL is preserved as a Product external_url__c custom field for reference. Portal branding, email request channels, and chat configuration from the JSM project are noted as manual reconfiguration items post-migration since Freshdesk's product-level settings include portal page configuration that differs structurally from JSM's portal editor.

JSM Request Types define the intake form shown to portal customers. Each Request Type's field schema maps to a Freshdesk Ticket Field group. We translate JSM custom field types (text, dropdown, multi-select, date, user picker) to Freshdesk field types. Request Type visibility flags on the JSM portal do not have a direct Freshdesk equivalent; we set visibility on the Freshdesk portal section level instead. This is a manual configuration step after import with the customer admin.

JSM Agents (billed users who resolve tickets) map to Freshdesk Agents by email. JSM's agent permission levels (admin, user, jira-software-user) map to Freshdesk's agent permission groups (agent/admin). JSM Customers (portal-only users who submit but cannot resolve) map to Freshdesk Contacts if they need agent-level access or remain as unauthenticated requesters on the Freshdesk portal if not. We set agent_type on every imported user based on the JSM user type to prevent unintended Freshdesk agent seat expansion.

JSM SLA definitions with goal minutes, starting conditions, and pause conditions map to Freshdesk SLA policies on Growth tier and above. We reconstruct the SLA calendar from JSM's business hours configuration and create Freshdesk SLA policies with first-response and resolution goals matching the JSM source. JSM's SLA breach actions (notify, escalate) translate to Freshdesk SLA violation actions. If the destination Freshdesk plan is lower than Growth, SLA policies are not available and SLA goals are logged as custom ticket fields for reference rather than enforced.

JSM Request comments (public portal replies and internal notes) map to Freshdesk Conversations. Public comments from customers map to Freshdesk incoming conversations; agent comments map to outgoing conversations. Internal JSM notes require Freshdesk's private note feature which is available from Pro tier. If the destination is on Growth, internal notes migrate as ticket_field_value entries on a dedicated internal_note__c custom field rather than as native private notes. Author, timestamp, and HTML body are preserved.

File attachments on JSM Requests and comments are downloaded from Atlassian's CDN and re-uploaded to Freshdesk via the attachments API. We preserve original filenames and attach each file to the corresponding Ticket conversation or reply. Large attachment batches are chunked to avoid timeout. Attachments embedded in comments migrate as inline references where the Freshdesk rendering supports it, or as downloadable attachments at the ticket level otherwise.

JSM Knowledge Base articles live in Confluence spaces linked to each Service Project. We export articles via the Confluence REST API, stripping Confluence-specific markup and converting to Freshdesk-compatible HTML. We explicitly check each article's Confluence space permission before migration and set the Freshdesk article visibility to match: internal-only articles are set to draft or restricted section in Freshdesk. We flag any Confluence articles with no explicit visibility restriction for the customer admin to review before publishing. Article-to-section and article-to-category mapping is configured during import.

JSM portal users who submitted Requests but were not assigned as agents map to Freshdesk Contacts. We use email as the dedupe key. JSM customer_type = customer maps to Freshdesk Contact. Any JSM portal user with a role assignment (portal admin) maps to a Freshdesk Agent with the appropriate permission group. The JSM portal user's company affiliation maps to Freshdesk company_id if the customer uses Freshdesk's company module.

JSM's full change history (field changes, status transitions, assignee updates, SLA breach events) is exported via the issue changelog API and re-imported to Freshdesk as a chronological internal note log appended to each Ticket. We preserve timestamp, field name, old value, and new value in a structured format readable by support managers. Freshdesk's native ticket history tracks current field values only; the change log as structured audit trail is a custom migration artifact stored in a dedicated internal ticket field.