Jira Service Management to Freshdesk Migration: Technical Guide

What Is a Jira Service Management to Freshdesk Migration?

A Jira Service Management to Freshdesk migration is the process of extracting tickets (issues), conversations (comments), contacts (customers/reporters), agents, groups, attachments, custom fields, and tags from Atlassian's ITSM platform and loading them into Freshworks' Freshdesk helpdesk — while preserving relationships, history, and operational continuity.

The move is non-trivial because JSM request types are a customer-facing view over Jira issue fields, while Freshdesk centers on tickets plus a simpler conversation model. (developer.atlassian.com)

Why Teams Move from JSM to Freshdesk

• Cost. JSM's per-agent pricing on Premium/Enterprise tiers exceeds Freshdesk's Growth or Pro plans for most mid-market support teams.
• Complexity mismatch. JSM is built for ITSM workflows — change management, asset management, incident queues. Teams doing pure customer support often find Freshdesk's UI faster to adopt.
• Atlassian ecosystem dependency. JSM works best alongside Confluence and Jira Software. Teams that don't use the full Atlassian stack pay for overhead they never touch.

Architectural Differences That Make This Non-Trivial

1. Issue vs. Ticket model. JSM issues inherit Jira's project → issue type → workflow hierarchy. Freshdesk tickets are flat: status, priority, type, group. JSM's multi-level workflow states must be compressed into Freshdesk's linear status pipeline (2=Open, 3=Pending, 4=Resolved, 5=Closed).
2. Identity model. JSM uses Atlassian account IDs (accountId). Freshdesk uses email as the primary contact identifier. Every comment author must be resolved from accountId to email, then matched or created in Freshdesk.
3. Rich text format. JSM stores descriptions and comments in Atlassian Document Format (ADF), a proprietary JSON structure. Freshdesk expects standard HTML. ADF must be parsed and converted during the transformation phase.
4. SLA architecture. JSM SLAs are calendar-based with per-request-type goals tied to JQL conditions. Freshdesk SLA policies use business-hour calendars with priority-based targets. There is no automatic conversion; each policy must be rebuilt manually.

JSM to Freshdesk Object Mapping

Before writing any extraction logic, establish a strict data dictionary. Do not assume fields map cleanly.

What Has No Clean Equivalent in Freshdesk?

• JSM Request Types — Freshdesk has no concept of request types with distinct portal forms per issue type. Workaround: use Freshdesk ticket forms (Enterprise plan only) or flatten into a custom dropdown.
• Linked Issues — JSM supports parent/child and "blocks/is blocked by" relationships. Freshdesk has parent-child tickets but no arbitrary link types. Preserve other link references as private notes.
• Approvals — JSM's built-in approval workflows have no Freshdesk equivalent. Archive approval history as notes.

Field-Level Mapping and Transformations

JSM custom fields require specific data type transformations before loading into Freshdesk:

• Picklists/Enums: Jira dropdown values must match the exact string values pre-configured in Freshdesk. If a Jira value doesn't exist in Freshdesk, the API rejects the ticket creation. Pre-create every destination enum before loading. (developer.atlassian.com)
• Dates: Jira exports timestamps in ISO 8601 format with timezone offsets. Freshdesk expects UTC timestamps. Normalize all dates during the transformation phase.
• Rich Text: JSM ADF JSON must be parsed and converted to HTML tags (<p>, <ul>, <strong>) to render correctly in Freshdesk.
• Tags: Truncate or remap any JSM labels exceeding 32 characters before loading.
• Statuses: Convert JSM workflow states to Freshdesk integer status codes: 2=Open, 3=Pending, 4=Resolved, 5=Closed.

Idempotency tip: Create a Freshdesk custom ticket field such as cf_jsm_key and maintain a local crosswalk table mapping JSM issue keys to Freshdesk ticket IDs. Freshdesk documents unique_external_id for contacts, not for tickets, so do not assume a built-in ticket external ID for replay-safe upserts. (developers.freshdesk.com)

The 10,000-Issue Limit: Exporting Data from JSM

Jira Cloud's Issue Navigator CSV export supports a maximum of 10,000 work items. Atlassian recommends splitting large result sets with JQL batches for anything larger. (support.atlassian.com)

CSV exports are useful for discovery and mapping workshops but fail for production migrations. They break ticket threading, drop inline attachments, and don't include comment history. For anything beyond a small partial backfill, read Using CSVs for SaaS Data Migrations first.

On the Freshdesk side, the documented native import flows cover contacts and companies. Tickets, notes, replies, and attachments are API-only objects. A practical hybrid is CSV import for contacts and companies, then API load for tickets and history. (support.freshdesk.com)

To extract the full dataset from JSM, use the Jira REST API. The enhanced JQL search endpoint (/rest/api/3/search/jql) returns a maximum of 100 issues per page and uses nextPageToken for sequential pagination. You cannot parallelize page requests — each page depends on the token from the previous response.

Comments and attachments require separate API calls per issue:

# Fetch issue with rendered fields
GET /rest/api/3/issue/{issueKey}?expand=renderedFields
 
# Fetch comments separately (paginated)
GET /rest/api/3/issue/{issueKey}/comment?startAt=0&maxResults=100
 
# Download attachment binary
GET /rest/api/3/attachment/content/{attachmentId}

Use stable JQL filters with date windows so runs are restartable:

project = SUPPORT
AND updated >= startOfDay(-30d)
ORDER BY updated ASC

This pattern works for both historical batching and final delta sync. Atlassian's own guidance for oversize exports is to split by date or another filter until each batch is small enough to process safely. (support.atlassian.com)

Freshdesk API Rate Limits and Throughput

Freshdesk enforces per-minute rate limits tied to your subscription plan. These limits are account-wide — shared across all API keys, marketplace apps, and integrations. (support.freshdesk.com)

The per-endpoint sub-limits are the real bottleneck during migration. Even on a Pro plan (400 calls/min total), you can only create 160 tickets per minute — and that's before accounting for contact creation, note creation, and attachment uploads.

Every Freshdesk API response includes X-RateLimit-Total, X-RateLimit-Remaining, and X-RateLimit-Used-CurrentRequest headers. When the limit is exceeded, Freshdesk returns HTTP 429 with a Retry-After header. Implement exponential backoff, not fixed-interval retries. (developers.freshdesk.com)

Throughput Math

A history-preserving migration consumes far more API calls than just creating ticket shells. If a single historical ticket requires 1 API call to create the ticket, 3 calls to add historical comments, and 1 call to upload an attachment, that's 5 API calls per ticket.

On the Growth plan (200 total calls/min, 80 ticket creates/min), the total budget is the binding constraint for history-heavy loads: roughly 40 complete tickets per minute, or about 2,400 tickets per hour. Migrating 100,000 tickets at that rate takes a minimum of ~42 hours of continuous, error-free execution.

On the Pro plan (400 total calls/min), throughput roughly doubles — but retries, contact lookups, and oversized attachments always erode the ceiling. Treat these numbers as upper bounds, not promises. Plan your cutover window accordingly.

Preserving Ticket History in Freshdesk

Ticket history — comments, authors, attachments — is the single most important element to get right. CSV imports do not carry comment threads or attachments. Only API-based migration preserves full history.

Author Attribution

The most common failure mode is admin attribution: if your migration script creates comments using a single admin API key without specifying the original author's user_id, every comment in Freshdesk appears as written by the admin. To preserve authorship:

1. Extract all unique reporters and commenters from JSM. Resolve accountId to email via Jira's /rest/api/3/user?accountId={id}.
2. Create or match each user as a Freshdesk Contact (POST /api/v2/contacts). Deduplicate by email — duplicate submissions return HTTP 409.
3. When creating notes/replies, pass the contact's Freshdesk user_id to attribute the conversation entry correctly.
4. Use the incoming parameter on notes to distinguish customer-authored entries (incoming: true) from agent responses. This preserves the direction of conversation, not just visibility. (developers.freshdesk.com)

Comment Visibility Mapping

JSM comments expose a public boolean. Freshdesk notes use a private boolean. The mapping:

• JSM public comment → Freshdesk Reply or Note with private: false
• JSM internal comment → Freshdesk Note with private: true

Replay comments in chronological order per ticket to maintain readable thread history.

# Replay a single comment as a Freshdesk note
payload = {
    'body': '<div>Original JSM public comment</div>',
    'private': False,
    'incoming': True,
    'user_id': 12345,
}
requests.post(
    f'{base}/api/v2/tickets/{ticket_id}/notes',
    json=payload,
    auth=(api_key, 'X'),
)

This pattern preserves direction, visibility, and author identity instead of collapsing every legacy comment into a generic admin note. (developer.atlassian.com)

Handling Attachments

Migrating attachments from JSM to Freshdesk requires a download-then-upload workflow. Freshdesk does not accept remote URLs — files must be uploaded as local binaries using multipart/form-data encoding.

# Migrate a single ticket's attachments
for attachment in jsm_issue['fields']['attachment']:
    # 1. Download from Jira
    file_bytes = jira_client.get(
        attachment['content'],
        auth=(email, api_token)
    ).content
    # 2. Upload to Freshdesk as multipart
    requests.post(
        f'https://{domain}.freshdesk.com/api/v2/tickets/{fd_ticket_id}/notes',
        auth=(fd_api_key, 'X'),
        files={'attachments[]': (attachment['filename'], file_bytes)},
        data={
            'body': f'Migrated attachment: {attachment["filename"]}',
            'private': True
        }
    )

Rate Limit Retry Handler

Your load scripts must intercept the Retry-After header, pause execution, and retry. Keep the handler boring and predictable:

while True:
    r = session.send(req)
    if r.status_code != 429:
        break
    time.sleep(int(r.headers['Retry-After']) + jitter())

Log source ID, destination ID, request type, comment index, attachment name, HTTP status, and retry count for every write. When a migration fails, good logs are the difference between replaying one ticket and rerunning the entire weekend. (developers.freshdesk.com)

Migration Approaches Compared

If you have under 5K tickets with no custom fields, CSV may be sufficient — but read Using CSVs for SaaS Data Migrations first. For anything above 10K tickets with attachments and comment history, an API-based approach is the only viable path.

Step-by-Step JSM to Freshdesk Migration Process

Order of operations matters. Creating tickets before their assigned agents or contacts exist in Freshdesk causes broken references. Follow this sequence:

Step 1: Inventory Source and Destination Schema

Pull JSM request types and request-type field metadata from /rest/servicedeskapi/servicedesk/{serviceDeskId}/requesttype/{requestTypeId}/field. List all Freshdesk ticket, contact, company, group, and agent fields. Use JSM fieldId and jiraSchema — not the customer-facing label — as your source of truth. Freeze the data dictionary before the first dry run. (developer.atlassian.com)

Step 2: Pre-Create Reference Data in Freshdesk

Agents, contacts, companies, groups, tags, and custom field definitions must all exist before you write any ticket history. Freshdesk expects dropdown choices to exist before load, or validation will fail. Agents must be provisioned before ticket assignment works via the API.

Step 3: Extract and Cache from JSM

Do not map data on the fly. Extract all issues, comments, users, attachments, and request-type metadata using the Jira REST API. Store results in a local JSON cache or staging database (PostgreSQL, MongoDB) to avoid hitting Jira's rate limits repeatedly during testing.

Jira Cloud enforces a points-based rate limiting system with three independent layers: hourly quota, burst limits per second per endpoint, and per-issue write limits. When any limit is exceeded, Jira returns HTTP 429 with a Retry-After header.

Step 4: Transform and Map

Run a transformation script against your local cache:

• Convert all ADF JSON to HTML
• Normalize all timestamps to UTC
• Build a key-value mapping of Jira accountId to Freshdesk requester_id
• Map JSM statuses to Freshdesk integer codes (2=Open, 3=Pending, 4=Resolved, 5=Closed)
• Map custom fields to cf_ prefixed keys
• Truncate tags exceeding 32 characters

Step 5: Load Tickets

Create tickets using POST /api/v2/tickets with the mapped requester_id, responder_id, and field values. Store the JSM issue key in cf_jsm_key and record the JSM-to-Freshdesk ID crosswalk.

To preserve original timestamps, pass the created_at and updated_at parameters in your payload. If you omit these, Freshdesk stamps every historical ticket with today's date. Test this behavior in your sandbox — Freshdesk documentation does not always list these fields explicitly for all plans.

Step 6: Load Conversations and Attachments

For each ticket, create replies (public comments) and notes (internal comments) in chronological order. Set user_id for author attribution and incoming for conversation direction. Upload attachments via multipart/form-data on the note/reply endpoint.

Closed ticket ordering: Freshdesk prevents updates to tickets in a "Closed" state by default. Load the ticket, add all historical comments and attachments, and then update the status to Closed. If you close first, the API rejects subsequent comment additions.

Step 7: Delta Sync and Cutover

Run a delta sync to capture tickets created or updated in JSM during the migration window. Query only records updated after the last watermark. Reconcile source and target counts. Switch email routing to Freshdesk only after the delta sync confirms parity.

Timeline and Resourcing

A standard Jira Service Management to Freshdesk migration takes 10–18 business days. For a detailed planning model, see the migration timeline guide.

Volume, custom field complexity, and attachment count are the primary variables. Small environments with under 10K tickets and no custom fields can compress this to 5–7 days. Enterprise environments with 100K+ tickets, deep comment history, and multi-project structures should budget 3–6 weeks.

Risk Register

Customer and Operational Impact

With a properly planned zero-downtime migration, customers notice nothing. Support continues on JSM during the bulk migration. After cutover, customers see their full ticket history in the Freshdesk portal — provided conversations were migrated with correct author attribution.

What customers will notice if you get it wrong:

• Broken history. All comments showing as "Admin" destroys trust and makes searching past conversations useless.
• Missing attachments. Customers who reference previously shared files will open new tickets.
• SLA resets. If SLA policies aren't rebuilt in Freshdesk before go-live, response time guarantees reset and first-response violations spike.

Critical pre-cutover step: Disable all auto-responders, triggers, and observer rules in Freshdesk before loading historical data. If you load 100,000 historical tickets and Freshdesk fires a "Ticket Received" automation for each one, you will spam your entire customer base.

Plan communications: send a brief notice 48 hours before cutover with the new portal URL. Many teams surface the old JSM key on the Freshdesk ticket so agents can search legacy references. Keep JSM as the system of record until the final delta sync, reconciliation, and UAT all pass. Run 48–72 hours of hypercare after cutover.

What Cannot Be Migrated from JSM to Freshdesk

Be honest about what will not survive the move:

• Automation rules — JSM automations (e.g., "If issue transitions to X, ping Slack and update field Y") have no migration path. Rebuild manually using Freshdesk Dispatch'r, Observer, and Supervisor rules.
• SLA policies — JSM uses JQL-based conditions; Freshdesk uses UI-based condition matching. Must be recreated manually with matching business-hour calendars.
• Approval workflows — JSM's built-in approval system has no Freshdesk equivalent. Archive approval history as private notes.
• Linked issue relationships — JSM supports "blocks/is blocked by" and arbitrary link types. Freshdesk supports parent-child tickets only. Preserve other link references as private notes.
• Request participants — No first-class participant collection in Freshdesk. Flatten into cc_emails, requester, or archive. (developer.atlassian.com)
• Multi-cycle SLA records — Freshdesk SLA tracking doesn't preserve JSM's granular SLA cycle history. Store in custom fields or archive to JSON/S3 for compliance.
• Audit logs and field change history — No Freshdesk equivalent. Archive externally if needed for compliance.
• Confluence knowledge base articles — Require a separate migration pipeline into Freshdesk Solutions.

Validation and Testing

Post-migration QA determines success. Follow the Freshdesk Migration Checklist for a comprehensive QA process. At minimum:

1. Record-count reconciliation. Total tickets in JSM (via JQL count) vs. total tickets in Freshdesk. The numbers must match exactly.
2. Field-level spot check. Sample 5–10% of tickets. Verify status, priority, type, custom fields, assignee, and requester match the source.
3. Conversation integrity. For sampled tickets, verify comment count, author attribution, chronological order, and public/private visibility.
4. Attachment integrity. Open 20+ historical attachments in Freshdesk. Confirm PDFs open correctly, images render inline, and files are attributed to the correct conversation entry.
5. SLA policy validation. Create a test ticket in Freshdesk and verify SLA timers activate correctly.
6. Automation smoke test. Trigger each rebuilt automation rule and confirm expected behavior.

Count checks are necessary but insufficient. A migration with perfect ticket counts can still be wrong if privacy flags, authors, companies, or attachments are broken. Validate by request type, not only by global totals. (developer.atlassian.com)

Build In-House vs. Use a Managed Service

Build in-house when: you have a dedicated engineer available for 2–3 weeks, your dataset is under 20K tickets, custom fields are minimal, and you can tolerate a weekend maintenance window.

Use a managed service when: your dataset exceeds 50K tickets, you have complex custom fields or multi-project structures, you need zero downtime, or your engineering team is already committed to product work.

The hidden cost of DIY is not the initial build — it's the 3–4 cycles of debugging edge cases (encoding errors, orphaned attachments, rate-limit stalls, admin attribution) that extend timelines by 2–3x. "No data loss" is a process outcome, not a default feature.

ClonePartner has completed 1,500+ data migrations including complex helpdesk moves with custom field mapping, threaded history preservation, and delta-sync cutover. Our team handles the API throttling, user mapping, and validation — so your engineers stay on product work.

The Practical Takeaway

Migrating from Jira Service Management to Freshdesk is an engineering project, not an export/import task. Success requires respecting API rate limits, properly transforming ADF to HTML, and executing a strict order of operations to preserve ticket threading and user attribution.

Treat the data dictionary as your source of truth. Implement robust error handling for HTTP 429 responses. Make every write idempotent. And never execute a production load without a comprehensive sandbox validation phase.