Jira Service Management migration checklist

Prepared by StrataCom · Reviewed October 28, 2026

Before choosing what comes after Jira Service Management Data Center, make the current service environment visible. Use this checklist to identify what your team must preserve, redesign, archive, or retire, and which questions a demonstration or pilot must answer.

This checklist is for an ITSM transition. Record Jira Service Management Data Center, Jira Service Management Cloud, Jira Software, and Confluence separately. A Jira Software or Confluence deployment on its own does not establish that your organization runs JSM Data Center.

1. Write down the actual estate and decision

List each product, edition, deployment model, version, environment, owner, and contractual milestone. Record a dated source for each item.
Describe why the organization is reviewing ITSM now and what happens if the current approach continues.
Name the executive sponsor, service owner, Jira/JSM administrator, security reviewer, procurement owner, and delivery stakeholders.
Set the next decision and its date: requirements approval, shortlist, pilot, budget decision, or implementation authorization.
Separate mandatory self-hosting from the underlying requirements for data location, security, operational control, and cost.

2. Identify the workflows people depend on

Inventory request types, portals, forms, queues, field contexts, approval rules, statuses, and transitions.
Document automation, scripts, scheduled jobs, notifications, escalations, and who maintains them.
Choose one representative service request and one difficult exception for a shared platform demonstration.
Record working calendars, SLA start/pause/stop conditions, and behavior when a request reopens.
Distinguish the business rule that must survive from the screen or implementation detail that may change.

3. Map Assets and relationships

List object schemas/types, identifiers, attributes, cardinalities, references, people and location links, and ticket associations.
Identify authoritative sources, imports, discovery jobs, normalization rules, duplicate handling, and update ownership.
Record scripts, forms, filters, automation and reports that depend on Assets objects or identifiers.
Choose representative relationships for testing, including a missing object and a deleted or inactive user.
Agree how to reconcile objects and relationships separately; matching ticket counts alone is insufficient.

4. Classify history, comments and attachments

Separate open operational work from closed history and records that must be retained for audit or contractual reasons.
Decide for each record group: migrate, transform, rebuild, archive externally, exclude, or leave unverified until tested.
Check internal versus public comment visibility, authorship, original timestamps, time zones, attachments, embedded links, and deleted-user references.
Record attachment size/type limits, source availability, checksum or equivalent verification, and archive retrieval permissions.
Define how legacy IDs will remain searchable and how users can find any approved archive.
Set retention, deletion and legal-hold rules with the accountable business owner before extracting data.

5. Inspect identity and permissions

Inventory customers, agents, administrators, groups, organizations, service accounts and external participants.
Map active and inactive identities without assigning a departed user’s actions to the wrong person.
Record authentication, provisioning, access reviews, customer/organization boundaries, and privileged administration.
Test with a requester, agent, administrator and unauthorized user; include internal comments and restricted attachments.
Keep sensitive data out of demonstration environments unless its use is explicitly approved.

6. Inventory Marketplace apps and integrations

List app name/vendor, deployment edition, version, owner, purpose, data stored, dependencies and renewal.
For each customization, decide whether a target feature, replacement app, rebuilt process, integration or archive is appropriate.
Document APIs, authentication, rate/size limits, polling/webhook behavior, error handling and maintenance ownership.
Identify systems that create or update tickets, assets, identities, approvals, notifications or reporting data.
Test retries, duplicate prevention, reconciliation after outages, and which system owns status and closure.
Do not assume a Cloud app or cross-platform marketing statement proves JSM Data Center extraction support.

7. Plan knowledge and Jira development coexistence

Identify Confluence spaces, article permissions, links, embedded content, ownership, review dates and customer access.
Decide whether knowledge remains, moves, is rewritten or is retired; test links and search in the selected design.
Record which Jira Software development workflows must remain and each product’s own deployment and lifecycle plan.
Test service-ticket escalation to a development issue with identity mapping, cross-system IDs, selective comment sharing, status ownership, retries and closure.
A coexistence design must name the actual Jira edition and integration mechanism it has tested.

8. Make reports and costs comparable

List operational dashboards, scheduled extracts, audit evidence, SLA measures and business definitions that matter.
Identify historical reports that require a retained source or archive rather than a recreated target calculation.
Apply hard requirements before weighted scoring. Record verified, needs testing or unavailable evidence for each option.
Use current quotes for equivalent scope: subscriptions, modules/add-ons, integration, security, environments, storage/usage, implementation, migration, training, internal administration, transition overlap, archive and support.
Mark unknown costs explicitly and test reasonable sensitivity ranges. Avoid a savings conclusion while material inputs remain unknown.
Include future data export and exit requirements in the new platform decision.

9. Agree a bounded proof and cutover plan

Name the source/target product, edition, version, method and test environments.
Define representative records and acceptance criteria before loading data. Include one restricted comment, an attachment, a relationship and an exception.
Reconcile selected source records to imported, archived, excluded and failed records. Track any split or merged records explicitly.
Inspect permissions and relationships as well as counts, and log unresolved exceptions with owners.
Agree freeze/delta handling, backup, rollback criteria, user communication, service desk training and the accountable go/no-go decision.
Keep a tested pilot’s limits visible. Additional workflows, data types and production scale require further validation.

A simple worksheet to take to the next discussion

Item	Decision or evidence to capture	Owner / next action
Current estate	Actual products, editions, deployment and versions; dated source	Product administrator
Hard requirement	Pass/fail gate and evidence needed from each option	Security/business owner
Critical dependency	Workflow, app, Assets relationship, knowledge or integration that changes the decision	Service/technical owner
Data disposition	Migrate, transform, rebuild, archive, exclude or unverified	Business and retention owner
Feasibility question	Representative sample, expected behavior and acceptance test	Technical reviewer
Next decision	Question to resolve, required inputs and decision date	Customer sponsor

Talk through the next decision

Bring the known facts and the gaps. Request a JSM Data Center options call to discuss your ITSM options and the scope of a practical assessment. A complete recommendation or migration quote needs the requirements and evidence behind your particular environment.

Use Atlassian’s current policy for Jira and JSM Data Center for lifecycle details and customer-specific exceptions. If Atlassian Cloud is a suitable path, StrataCom’s existing Cloud migration assessment remains a relevant starting point.

Contact