Migrate from Jira Service Management to Salesforce Service Cloud

Jira Service Management Requests map to Salesforce Case as the primary ticket object. Summary maps to Case Subject; description maps to Case Description (preserving Jira markup as plain text); priority maps to Case Priority using the standard Jira-to-Salesforce priority mapping table; status maps to Case Status with the JSM workflow state translated to an equivalent Salesforce Business Process value. Created and Updated timestamps migrate as Case.CreatedDate and Case.LastModifiedDate via the Bulk API to avoid timezone-offset issues from Jira's epoch-based storage.

Each JSM Service Project maps to a Salesforce Case Record Type. The project name becomes the Record Type label; request types within the project map to separate Case Record Types if the customer requires intake-form differentiation, or remain as a single Record Type with a Request Type custom field. Service project portal settings (branding, allowed domains) map to the Salesforce Customer Portal or Experience Cloud site configuration, which requires re-application post-migration.

JSM request types define the intake form presented to customers. Where the customer has many request types per project (IT, HR, Facilities), we map these to Salesforce Case Record Types with separate Page Layouts so that fields presented to agents differ by request category. If the customer has fewer than five request types, we map to a Case custom picklist field (jsm_request_type__c) to reduce the number of Record Types. Custom fields on the request type schema migrate as Salesforce custom fields on Case.

JSM SLA goals with starting conditions and pause conditions map to Salesforce Entitlement records and Milestone child records. The SLA goal duration migrates as a Salesforce Entitlement with First Response Time and Resolution Time milestones. Note that JSM Standard-tier SLA features migrate directly; if the source JSM instance is on the Free tier with no SLA data, no Milestone migration is possible. Salesforce Business Hours on the Entitlement must be configured to match the SLA calendar.

JSM custom fields (project-specific and global) are discovered via the Jira REST API metadata endpoint. Each field is typed — text, number, date, select, multi-select, user picker, group picker — and mapped to an equivalent Salesforce custom field type. Project-specific fields that appear in multiple JSM projects require separate Salesforce custom fields per Record Type if the field semantics differ per project. Multi-select fields map to Salesforce multi-select picklists; user picker fields map to Salesforce User Lookup fields with email-based resolution.

JSM Assets object schema data exports via CSV but the export omits ticket-to-asset linkages and import configuration references. We query the Jira issue-to-asset relationship API to reconstruct those linkages before migration, then import the Assets data into Salesforce Service Cloud Assets (CIs) via the SFDC REST API. If the destination org does not have Service Cloud licensed, we import to a custom object (jsm_asset__c) with a lookup to Case. Asset attributes (type, status, location, owner) map to equivalent custom fields on the destination asset record.

JSM customers (portal-only users who submit requests) map to Salesforce Contacts with portal-access enabled, or to Experience Cloud Contact records tied to an Experience Cloud site. Jira's customer portal users do not require Jira licenses; we preserve this by setting the Salesforce Contact as a Customer Portal user without a full Service Cloud seat. Jira agents map to Salesforce internal Users with a Service Cloud Agent license.

Jira agents (licensed resolvers) map to Salesforce Users. We resolve by email match against the Salesforce org's User table. Jira's agent vs. customer user type distinction is enforced by setting the Salesforce user's profile: agents become Users with the appropriate Service Cloud profile; customers become Contacts with portal access only. Owners without a matching Salesforce User are held in a reconciliation queue for the customer's admin to provision before Case import resumes.

Jira Request comments migrate to Salesforce CaseComment records with the author, timestamp, and body preserved. Internal Jira notes (comments visible only to agents) migrate as CaseComment with IsPublished = false. If the customer uses Jira's messaging or conversation feature, those entries migrate as Salesforce Chatter posts on the Case or as EmailMessage records linked to the Case. Attachments embedded in comments are handled separately in the attachment migration phase.

File attachments on Jira Requests are downloaded from Atlassian's CDN and re-uploaded to Salesforce as ContentVersion records, then linked to the parent Case via ContentDocumentLink. Large attachment batches are chunked to avoid timeout. We preserve the original filename, file extension, and ContentSize. Attachments over 25 MB use Salesforce's chunked upload endpoint. Jira comment-inline image attachments migrate as separate ContentDocument records linked to the Case.

JSM Knowledge Base articles live in Confluence spaces linked to a JSM project. We export articles via the Confluence REST API and import them as Salesforce Knowledge articles using the Salesforce Knowledge API. Space permissions in Confluence do not map directly to Salesforce article visibility settings; we configure Article Type visibility per Salesforce profile during import. Internal links within articles that reference Jira request IDs require manual updating post-migration.

The full Jira change history — field changes, status transitions, assignee updates — is exported via the issue changelog API and re-imported to Salesforce as CaseHistory records if Feed Tracking is enabled on the Case object. For destinations where full changelog is not required, we preserve the last-assigned values (last assignee, last status, last priority) as custom fields on the Case record to maintain audit trail without enabling Feed Tracking across all fields.