JSM Data Center to Cloud: the service desk parts the migration assistant misses
Short answer
Atlassian will end Data Center on March 28, 2029, when Jira Service Management Data Center licences expire and become read-only (per the Atlassian Ascend migration page, checked Oct 30, 2026). The Jira Cloud Migration Assistant (JCMA) moves most JSM project data, including request types, queues, SLAs, portal settings and customers, but its own documentation lists items it does not migrate that matter to service desks: canned responses, knowledge base articles linked to service projects, mail handlers, workflow functions, properties and triggers, user-defined custom notifications and custom events, issue collectors, and project avatars. Marketplace apps only move if the vendor provides a migration path. Plan the service desk layer separately: email channels, notifications, automation, knowledge, Assets, apps and the portal experience. Test on a staging cloud site and treat cutover as a service desk go-live, not an infrastructure task.
Contents
- The deadline and what it means for service desks
- What JCMA does not migrate for service desks
- Marketplace apps: the biggest unknown
- Assets, email, automation and the portal
- What changes for admins and agents in Cloud
- Clean up before you migrate
- Licensing and cost planning
- Who owns what during the migration
- A service-desk-focused migration plan
- Common failure points
- Frequently asked questions
The deadline and what it means for service desks
In September 2025 Atlassian announced the end of life of its Data Center products under a programme it calls Atlassian Ascend. The dates on the Atlassian Ascend migration page (checked Oct 30, 2026) are:
| Date | What happens |
|---|---|
| Mar 30, 2026 | End of Data Center licence sales to new customers. |
| Mar 30, 2028 | End of sales to existing customers, including new licences, Marketplace apps and licence expansions. |
| Mar 28, 2029 | End of life. Data Center licences and associated app licences expire and the products become read-only. |
Jira Service Management Data Center and Atlassian and third-party Data Center Marketplace apps are in scope. Atlassian says extended maintenance may be offered by exception, at extra cost. Renewals after March 2026 are prorated so they do not run past March 28, 2029.
For a service desk, "read-only" is not an inconvenience; it is an outage. Employees cannot raise requests, agents cannot update incidents and SLAs stop counting. The practical deadline is earlier than March 2029: you need time for testing, a cutover window outside your busy periods, and a buffer for problems. The March 30, 2028 cut-off also matters: after it you cannot add users to a Data Center licence or buy apps you discover you need.
There is a decision before the migration: Cloud, or a different tool. Most JSM teams will move to JSM Cloud. Some will use the deadline to re-evaluate; our Freshservice vs JSM vs ServiceNow comparison can help with that conversation.
What JCMA does not migrate for service desks
JCMA is Atlassian's free tool for moving Jira Data Center data to Cloud, and it supports JSM projects. According to Atlassian's "What gets migrated with the Jira Cloud Migration Assistant" (checked Oct 30, 2026), JSM project data that migrates includes projects, users including agents, groups, customers, request types and groups, custom fields, customer organisations, approvals, SLAs, project settings, legacy automation, customer notification templates, portal settings, calendars, workflows, language settings, customer satisfaction settings, reports and queues.
The same page lists what is not migrated. These are the items that hit service desks hardest:
| Not migrated by JCMA | Why it matters for a service desk | What to do |
|---|---|---|
| Canned responses | Agents lose the saved replies they use many times a day. | Export them before migration and recreate them in Cloud, or replace with automation or AI-assisted replies. |
| Knowledge base articles linked to service projects | The portal stops suggesting articles if the Confluence link is not re-established. | Migrate Confluence separately (Confluence Cloud Migration Assistant) and relink knowledge bases to service projects. |
| Mail handlers | Email is often the biggest channel. Without the handler, emails to support@ do not create requests. | Reconfigure email channels in JSM Cloud and update mail forwarding at cutover. |
| Workflow functions, properties and triggers | Post functions that set fields, validators and conditions may be skipped, changing how requests behave. | Run the pre-migration report, list affected workflows and rebuild logic with Cloud workflow rules or automation. |
| User-defined custom notifications and custom events | Only system events with default notifications migrate. Custom alerts to teams or managers disappear. | Recreate with notification schemes or automation rules. |
| Issue collectors | Embedded feedback or bug-report forms stop creating tickets. | Replace with portal links, the JSM widget or forms. |
| Project avatars, standard issue type icons, project shortcuts | Cosmetic, but agents notice. | Re-apply after migration. |
| Links to issues or entities that are not migrated | Links break when the target is out of scope. | Migrate related projects together or accept and document broken links. |
The page also notes that users' passwords do not migrate unless SSO is in place, per-user time zones are lost, the activity stream is not migrated, and services from Data Center are not migrated. Always generate the pre-migration report for your own instance; it shows exactly what will be skipped.
Marketplace apps: the biggest unknown
Service desks on Data Center often depend on apps for forms, SLAs, email handling, approvals, reporting or Assets-like functions. JCMA can only migrate app data when the app vendor provides an automated migration path. Some apps exist in Cloud with a migration path, some exist in Cloud without one, and some have no Cloud version at all.
- Inventory every app and record who uses it and for what. Remove apps nobody uses before you plan.
- Check each vendor's Cloud version and migration path on the Atlassian Marketplace and in the JCMA app assessment.
- Check whether Cloud makes the app unnecessary. Some capabilities, such as forms and automation, are built into JSM Cloud.
- For apps without a migration path, decide between manual data export and import, rebuilding with native features, or dropping the capability.
- Budget for Cloud app licences. Cloud apps are priced separately from Data Center apps.
Assets, email, automation and the portal
Assets
JCMA has a dedicated process for Assets (formerly Insight), but Atlassian lists some Assets items it does not migrate, including the Assets project attribute, issue history related to Assets custom fields and Assets multi-value variant custom fields. Check Assets object limits for your Cloud plan on the JSM pricing page. Reconfigure discovery and imports in Cloud; Data Center import schedules and scripts do not carry over automatically.
Email channels
Plan the email cutover in detail: which addresses forward to which projects, how replies thread onto existing requests, and what happens to mail that arrives during the migration window. Test with real mail, including replies from external addresses and attachments.
Automation
Atlassian publishes a separate list of which automation rules migrate. Cloud automation also has usage limits based on plan. Inventory rules, retire unused ones, and test the ones that route, escalate or close tickets, because silent automation failures show up as SLA breaches days later.
Portal and customers
Customers migrate, but their experience changes: a new URL, a new login (unless SSO is configured for customers), and a refreshed portal design. Redirect old portal URLs and tell employees what to expect.
Integrations
Monitoring tools, identity providers, HR systems and chat integrations that call Data Center APIs need new endpoints, credentials and often different authentication. List every inbound and outbound integration and test each in staging.
What changes for admins and agents in Cloud
Even when data migrates cleanly, Cloud is a different operating model from Data Center. Service desk owners should plan for these changes rather than discover them after cutover.
- No server access. Database queries, file-system scripts, custom listeners and direct database reporting are not available. Anything that relied on them must move to REST APIs, automation or a Marketplace app.
- Atlassian controls the release cadence. Features and interface changes arrive continuously rather than when you choose to upgrade. Assign someone to read release notes and test changes that affect agents.
- Automation has usage limits. Cloud automation executions are counted against plan limits. High-volume rules (for example, ones that run on every comment) need review.
- Identity is managed differently. Users have Atlassian accounts, and SSO and user provisioning are configured through Atlassian administration. Plan how agents and customers will authenticate.
- Admin roles split. Organisation administration, site administration and project administration are separate. Decide who holds each role.
- Data residency and compliance. If you have residency requirements, confirm the Cloud plan supports them before you migrate.
None of these is a reason to stay on Data Center, which is not an option after March 28, 2029. They are reasons to train admins before cutover and to rewrite the runbooks your team uses for daily administration.
Clean up before you migrate
Every object you migrate has to be tested, and every unused object adds risk. A Data Center instance that has run for years usually carries a lot of clutter. Use the months before migration to reduce it.
- Archive inactive service projects. Old projects for retired teams or one-off events can be archived or exported rather than migrated.
- Remove unused custom fields. Fields with no values, or used in only a handful of old tickets, slow down configuration and may not migrate cleanly. Unsupported custom field types are skipped by JCMA anyway.
- Consolidate request types. Look at which request types were used in the last year. Merge near-duplicates and retire the rest.
- Retire dead automation. Rules that have not fired in months, or that fail regularly, should be removed before inventory, not rebuilt.
- Fix user data. JCMA includes checks for invalid and duplicate email addresses. Fix these early; duplicate users cause attribution problems for comments and assignees.
- Remove unused apps. Each app removed is one fewer vendor to assess and one fewer Cloud licence to buy.
- Decide on attachment and history retention. Large attachment volumes lengthen migration time. Agree a retention position with legal and audit before deciding what to move.
Clean-up also produces the inventory you need for the rest of the plan. By the time you finish, you will know exactly which canned responses, notifications, workflows and apps need rebuilding.
Licensing and cost planning
Moving to Cloud changes how you pay: subscription per agent instead of a Data Center user-tier licence. Published Cloud prices on the JSM pricing page (checked on Oct 30, 2026) at the page's default team size were $21.50 per agent per month for Standard and $55.28 per agent per month for Premium, with Enterprise priced through sales and a free plan for up to 3 agents. The per-agent rate varies by agent count, so price your own numbers on the page. Requesters do not need agent licences.
Beyond licences, budget for:
- Cloud versions of Marketplace apps, which are priced separately.
- A staging or sandbox site for testing, depending on plan.
- Partner or contractor time for assessment, rebuild of skipped items and testing.
- Overlap: Data Center renewals are prorated to the end-of-life date, so align the renewal with your migration timeline.
- Training for admins and agents.
Atlassian has published migration support and offers under the Ascend programme; check the Atlassian Ascend migration page for what is currently available rather than relying on older offers.
Who owns what during the migration
| Workstream | Typical owner | Key output |
|---|---|---|
| Assessment and JCMA runs | Jira platform admin | Pre-migration report and skipped-items list |
| Service desk rebuild items | Service desk lead with Jira admin | Canned responses, notifications, email channels, automation rebuilt |
| Knowledge base | Knowledge owner / Confluence admin | Confluence Cloud spaces linked to service projects |
| Apps | Jira admin with app owners | App decision log and Cloud licences |
| Assets | CMDB or asset owner | Cloud schema, imports and discovery |
| Identity and security | IT security / identity team | SSO, provisioning, admin roles |
| Integrations | Integration owners | Re-pointed and tested integrations |
| Communication and training | Service desk lead | Agent training, employee announcements, redirect plan |
Small teams combine roles, but every row needs a named person. Unowned rows are where migrations stall.
A service-desk-focused migration plan
1. Assess
Run JCMA's pre-migration checks and app assessment. Inventory canned responses, mail handlers, custom notifications, workflow post functions, automation rules, apps, Assets schemas and integrations. Clean up unused projects, fields and apps.
2. Decide the approach
Single cutover or phased by project. Service desks usually prefer one cutover for all service projects so agents do not work in two places. Decide whether history moves in full.
3. Prepare Cloud
Configure SSO and user provisioning, the Cloud plan, and the Cloud app equivalents. Migrate Confluence knowledge spaces first if possible.
4. Test migration
Migrate to a staging or sandbox site. Rebuild the items JCMA misses. Run real scenarios: email-created requests, portal requests with approvals, SLA timers, escalations, Assets lookups and integrations.
5. Rehearse
Repeat the test migration with the final runbook and time it. Measure how long the freeze window must be.
6. Cut over
Freeze changes on Data Center, run the production migration, apply the rebuild items, switch email routing and portal redirects, and validate with a short checklist before announcing.
7. Hypercare
Monitor queues, SLAs, email intake and automation logs daily. Keep Data Center read-only for reference until you are confident, within your licence dates.
Common failure points
1. Treating JCMA success as migration success
JCMA can report a successful migration while canned responses, mail handlers and custom notifications are missing. Measure success by service desk scenarios working, not by the migration log.
2. Leaving apps until last
App gaps are discovered late and become blockers. Assess apps in the first phase.
3. Forgetting email
A migration that leaves support@ pointing at Data Center creates a silent backlog. Make email routing a named cutover step with an owner.
4. Waiting for 2028 or 2029
Partners and Atlassian support will be busier as the deadline approaches, and the March 30, 2028 sales cut-off limits your options. Start assessment now.
5. Skipping the rehearsal
Without a timed rehearsal, the cutover window is a guess. Service desks cannot be down for long.
Service desk checklist for JSM DC to Cloud
- Pre-migration report reviewed for skipped items
- Canned responses exported
- Mail handlers documented and Cloud email channels configured
- Custom notifications and events listed and rebuilt
- Workflow post functions, validators and conditions reviewed
- Automation rules inventoried and tested
- Knowledge base linked to Confluence Cloud
- Apps assessed with Cloud equivalents and licences
- Assets schema, imports and discovery reconfigured
- Integrations re-pointed and tested
- SSO for agents and customers
- Portal URL redirects and employee communications
- Rehearsal completed and timed
Frequently asked questions
When does Jira Service Management Data Center reach end of life?
On March 28, 2029, according to Atlassian. Data Center licences and associated Marketplace app licences expire on that date and the products become read-only. Existing customers can buy new licences, apps and expansions until March 30, 2028.
Does the Jira Cloud Migration Assistant migrate JSM projects?
Yes. Atlassian documents that JCMA migrates JSM projects, including request types, queues, SLAs, approvals, portal settings and customers. It does not migrate items such as canned responses, knowledge base articles linked to service projects, mail handlers, workflow functions and custom notifications.
What happens to our email channels in a JSM cloud migration?
Mail handlers are not migrated by JCMA. You need to set up email channels in JSM Cloud and change mail forwarding at cutover, then test that new emails and replies create and update requests correctly.
Do Marketplace apps migrate to Cloud?
Only if the app vendor provides an automated migration path for JCMA. Assess every app early, check for Cloud versions and migration paths, and plan to rebuild or replace the rest.
How long does a JSM Data Center to Cloud migration take?
It depends on data volume, the number of apps without Cloud migration paths, the amount of workflow and notification logic JCMA skips, and integrations. Run JCMA assessment and a timed test migration first; the rehearsal tells you the real cutover window, and the skipped-items list tells you the rebuild effort.
Can we stay on Data Center after March 2029?
Atlassian says extended maintenance may be available by exception and at additional cost. Plan on the assumption that it will not be available to you, and talk to Atlassian early if you think you qualify.
Moving JSM Data Center to Cloud?
We plan and run the service desk side of Atlassian cloud migrations: gap analysis against JCMA, email channel and notification rebuild, automation and Assets, app replacement, testing and cutover.