Methodology: Atlassian migration docs, knowledge base articles and licensing pages, plus two Atlassian partner pricing notes, checked on 6 Oct 2026. No vendor reviewed or paid for this article. We did not run hands-on tests.
A Jira Data Center to Cloud migration for a service desk runs mostly through Atlassian's free Jira Cloud Migration Assistant (JCMA). It moves issues, request types, queues, SLA configurations, customers and Assets. It leaves knowledge base links, mail handlers and canned responses behind, and migrated automation arrives switched off (Atlassian JCMA documentation, as of 6 Oct 2026).
If you run Jira Service Management (JSM) on Data Center and face the end-of-life dates, this guide covers the move itself: what JCMA carries, what you rebuild, where SLA and comment history can break, and a phased plan.
Key takeaways
- Data Center products, JSM included, become read-only on 28 Mar 2029 (Atlassian Data Center end-of-life page, as of 6 Oct 2026).
- JCMA migrates JSM request types, queues, SLAs, customers and portal settings, but not linked knowledge base articles, mail handlers or canned responses (Atlassian JCMA "what gets migrated" page, as of 6 Oct 2026).
- All migrated automation flows are disabled in Cloud by default (Atlassian automation migration doc, as of 6 Oct 2026).
- Atlassian's Assets migration doc requires JSM Premium or Enterprise to migrate Assets, while its Service Collection pricing page lists 5,000 Assets objects on Standard (both as of 6 Oct 2026).
- New cloud list prices apply to new purchases, renewals and upgrades from 13 Oct 2026, JSM included (Atlassian future pricing FAQ, as of 6 Oct 2026).
Why teams move from Jira Data Center to Cloud in 2026
The end-of-life schedule is the main trigger for an Atlassian cloud migration (our Jira Data Center end-of-life guide covers the options). These dates shape the timeline.
| Date | What happens | Source (as of 6 Oct 2026) |
|---|---|---|
| 30 Mar 2026 | Data Center no longer sold to new customers | Atlassian end-of-life page |
| 13 Oct 2026 | New cloud list prices for purchases, renewals and upgrades, JSM included | Atlassian future pricing FAQ |
| 3 Dec 2026 | Extra automation usage billed at $0.50 per 1,000 steps | Atlassian automation usage doc |
| June 2027 | Cloud Enterprise bought by then "may be eligible for a 10-20% discount for the first year" | Atlassian end-of-life page |
| 30 Mar 2028 | Existing customers can no longer buy or expand Data Center | Atlassian end-of-life page |
| 28 Mar 2029 | Data Center products, JSM included, become read-only | Atlassian end-of-life page |
The price change affects timing. Atlassian's table shows Service Collection Standard for 100 agents, billed annually, moving from $19,700 to $21,000 (Atlassian future pricing tables, as of 6 Oct 2026). Partners Eficode and Valiantys both put the JSM increase at 7.5% on Standard and Premium and 10% on Enterprise (Eficode, 7 Sep 2026; Valiantys; both as of 6 Oct 2026). Atlassian honors quotes generated before 13 Oct 2026 at the prior price until they expire.
The end-of-life page also lists cloud migration trials, step-up credits and dual licensing for larger customers. Ask which apply, since test migrations need a trial site.
What moves, what gets rebuilt and what's at risk in a Jira Data Center to Cloud migration
JCMA moves your service desk's records and most configuration objects, but not the behavior around them (Atlassian JCMA, automation, customer and Assets migration docs, as of 6 Oct 2026).
| Moves with JCMA | Rebuilt or re-enabled in Cloud | At risk (prove it in a test run) |
|---|---|---|
| Issues, comments, comments with security, attachments | Mail handlers, issue collectors | Internal vs public comment visibility |
| Request types and groups, portal settings, queues, calendars | Canned responses | SLA values on open issues after an SLA change in Cloud |
| SLA configurations, approvals, workflows, notification templates, CSAT settings | Automation flows (arrive disabled); workflow functions, properties and triggers | SLAs referencing deleted statuses or projects outside the plan |
| Users, groups, customers, customer organizations | Global permissions, avatars, per-user time zones, passwords (unless SSO) | Re-migrated groups, duplicate accounts |
| Assets schemas, objects, object history, references | Assets automation, import configurations, reports | Attributes over Cloud limits; archived objects return as active |
| App data, only with a vendor migration path | Apps without a path, and their fields | Locked or unsupported custom fields |
| Dashboards, filters, boards of migrated projects | Knowledge base links to Confluence | Per-project priorities |
Even inside one vendor's product family, behavior does not travel. Workflow functions, automation, app logic and running SLA timers are rebuilt and retested on the target, not trusted to arrive working.
Field mapping for a Jira Service Management migration
The object model stays the same, so mapping is mostly about identity, visibility and limits.
Users, agents and customers
Cloud matches accounts by unique email, linking data to any existing account (Atlassian users and groups migration doc, as of 6 Oct 2026). A licensed Data Center user who already has a cloud customer account ends up with two accounts (Atlassian JSM customers migration doc, as of 6 Oct 2026). Disabled users arrive active without app access, and JCMA sends no invitations or customer notifications.
Request types, portal and priorities
Request types and portal settings migrate. Priorities need a check. Atlassian's differences page says JSM Data Center's per-project priorities are "not available in Cloud". Yet Jira Cloud admin docs describe priority schemes, and the Cloud guardrails page caps priorities at 100 per space (all as of 6 Oct 2026). Test your priority matrix in the trial site.
Internal and public comments
In Data Center, an internal comment carries the property sd.comment.property with the value {"internal":true} (Atlassian Data Center KB, as of 6 Oct 2026). JCMA lists comments and comments with security as migrated, but does not say how internal visibility is handled. Check internal notes in the portal after every test run. With CSV, Atlassian says all imported comments become public in JSM spaces (Atlassian CSV import doc, as of 6 Oct 2026).
SLAs and SLA history
JCMA migrates SLA configurations; the risk is recalculation. In JSM Cloud, a non-destructive SLA recalculation is "triggered automatically whenever the SLA configuration is changed, applied to all open issues". Destructive recalculation can replace old SLA values (Atlassian JSM Cloud SLA KB, updated 25 Jun 2026, as of 6 Oct 2026). Freeze SLA goal changes until your post-cutover reporting baseline is captured.
Attachments
Jira Cloud allows 1 GB per file by default and 2 GB at most (Atlassian attachment settings doc, as of 6 Oct 2026). Find any Data Center files above that before the first test run.
Assets and CIs
Schemas, objects and object history move, but archived objects arrive as non-archived (Atlassian Assets migration doc, as of 6 Oct 2026). Cloud limits apply: at most 20 objects per work item in one custom field, 2 unique constraints per object type and 255 characters for Name and Description. Migrate all object schemas before the projects that reference them.
Knowledge base links and custom fields
The Confluence spaces behind your knowledge base move with the separate Confluence Cloud Migration Assistant. In Cloud, you link those spaces or folders to each service project again (Atlassian JSM Cloud docs, as of 6 Oct 2026). Jira Cloud enforces 700 fields and 150 work types per space (Atlassian Cloud guardrails page, as of 6 Oct 2026). App-provided fields migrate only when the app is already installed in Cloud, and locked fields are skipped (Atlassian KB, updated 14 Aug 2026).
Export from Data Center, import into Cloud: JCMA vs CSV vs API
For a Jira cloud migration from Data Center, Atlassian calls JCMA "the easiest and most reliable way" and says CSV import "isn't a recommended migration method" (Atlassian cloud migration methods page, as of 6 Oct 2026).
| Method | What Atlassian says (as of 6 Oct 2026) | Limits that matter for JSM | Use it for |
|---|---|---|---|
| JCMA | Free; needs a supported Data Center version; migrates in phases | Blocks a project whose name or key exists in Cloud; automation arrives disabled | The main move |
| Jira Cloud CSV import | "Only use it when Jira Cloud Migration Assistant is not an option" | About 1,500 work items per file, roughly an hour each; existing statuses only; comments become public in JSM | Small gap-fills |
| Data Center filter export to CSV | Data Center KB | 1,000 issues per export by default (jira.search.views.default.max) | Reconciliation lists |
| Scripted REST API | Atlassian developer docs | Cloud returns HTTP 429 at limits; respect Retry-After | Targeted fixes after JCMA |
JCMA's delta is narrow. A user re-run migrates only the differences and already migrated attachments are skipped (Atlassian migration speed and downtime docs, as of 6 Oct 2026). But a project whose name or key already exists in Cloud is blocked. The documented fix is to delete the earlier copy or rename the source (Atlassian KB, last modified 21 Sep 2023). Plan each project's final issue migration as one full run inside the freeze.
CSV also breaks SLAs. JSM calculates SLAs from issue history, so CSV-imported closed issues keep counting unless you exclude them or bulk-transition them to Done (Atlassian SLA KB, as of 6 Oct 2026).
The Jira Data Center to Cloud migration plan in phases
Atlassian says it "can't provide an exact estimation of downtime" because it depends on internet speed, data and other variables (Atlassian downtime doc, as of 6 Oct 2026). Plan in phases rather than to a guessed date.
- Discover. Inventory service projects, SLAs, queues, automation flows, apps, Assets schemas and knowledge base spaces. Run JCMA's pre-migration checks; if the JSM check on "Cloud limits for queues, legacy automation rules, and SLAs" fails, activate JSM on the cloud site (Atlassian KB, as of 6 Oct 2026).
- Map. Decide on duplicate emails, groups, priorities, SLA goals, internal comments and app replacements. Edit SLAs that reference deleted statuses or projects outside the plan, since both have caused "Time Metric" migration errors (Atlassian MIG-894 and KB, as of 6 Oct 2026).
- Test migration. Run into a trial site. Check comment visibility, SLA panels, portal search, Assets references and automation one by one.
- Cutover with a freeze. Pre-migrate users, groups and attachments while agents still work, which Atlassian says causes no downtime. Then freeze with a permission scheme that allows only Browse, since Jira has no native read-only mode. Run the final project and Assets migration, re-link the knowledge base and switch on the email channel.
- Reconcile. Compare issue counts per request type, open SLA states, customer counts, Assets object counts and sample internal comments against Data Center exports. Then enable tested automation flows before agents return.
- Hypercare. Watch SLA breaches, email intake and portal traffic daily.
For speed, Atlassian recommends at least 16 CPUs per node and pausing antivirus scans, backups, full reindexing, automation and apps during the run (Atlassian migration speed doc, as of 6 Oct 2026).
JSM failure points in a Data Center to Cloud move
A Jira service desk migration from Data Center tends to fail on behavior, not records.
- Email requests go nowhere. Mail handlers don't migrate, so set up the JSM email channel in Cloud before cutover.
- Self-service drops quietly. Portal article suggestions stop until knowledge base spaces are re-linked.
- Nothing auto-assigns. With automation disabled, routing and escalation rules stay off until enabled and tested.
- Admin rights linger. Re-migrating a group keeps its first membership, which Atlassian says "can result in permission escalation".
- SLA numbers shift. Editing an SLA after go-live recalculates SLAs on every open issue.
Jira Data Center to Cloud migration checklist
Versions and limits below come from the Atlassian sources above, as of 6 Oct 2026.
- Confirm your cloud plan with Atlassian, including in writing whether Assets migration needs Premium or Enterprise.
- Check whether your cloud quote predates the 13 Oct 2026 list price change.
- Upgrade JCMA, Automation for Jira (7.2.6 or later) and your Data Center version to supported levels.
- Activate JSM on the cloud site and run all pre-migration checks.
- Fix SLAs that reference deleted statuses or projects outside the plan.
- Resolve duplicate emails across agents and customers.
- List Data Center attachments larger than 2 GB.
- Count custom fields and work types per project against the 700 and 150 per-space limits.
- Pre-migrate users, groups and attachments, then Assets object schemas.
- Run a test migration and check internal comments, SLAs, priorities and portal search.
- Freeze Data Center with a browse-only permission scheme, run the final migration, re-link the knowledge base and switch on the email channel.
- Reconcile counts and samples, then enable tested automation flows before agents return.
FAQ
Methodology
We read Atlassian's migration, admin and developer docs, knowledge base articles, licensing pages and pricing tables, checking each fact on 6 Oct 2026. Price-change percentages come from Atlassian Solution Partners Eficode and Valiantys and are attributed to them. Where Atlassian's pages disagree (Assets plan requirements, per-project priorities), we report both. We did not run hands-on tests.
Disclosure: MigrateX, the publisher of this article, runs ITSM data migrations, including between platforms named here. No vendor reviewed or paid for this article.