Jira Service Management Data Center EOL When Cloud Is Not an Option
First, use the official product name and scope
Atlassian lists Jira Service Management Data Center and Jira Software Data Center as separate products in its Data Center EOL announcement. This article is about Jira Service Management Data Center, abbreviated below as JSM Data Center. It is not about Jira Software Data Center or either cloud product.
The deadline and purchasing milestones
- March 30, 2026: new customers can no longer purchase affected Data Center subscriptions or new Marketplace Data Center apps.
- March 30, 2028: existing customers can no longer buy new affected subscriptions, Marketplace apps, or subscription expansions.
- March 28, 2029 at 23:59 PST: affected subscriptions and associated Marketplace apps expire and become read-only.
Atlassian says extended maintenance may be available to certain customers by exception. If your organization expects to need it, open that discussion early and treat it as a specific commercial arrangement, not a general fallback.
“Cloud is not an option” needs a precise reason
Some constraints are absolute today. Others depend on product scope, plan, geography, configuration, or an authorization that is still in progress. Write down the actual requirement and the evidence behind it.
- Government and classified workloads. Atlassian says it intends to have FedRAMP High and Impact Level 5 environments built and ready to submit for authorization before EOL, while also noting that it does not control authorization timing. Check the current roadmap and authorization status with Atlassian rather than assuming either availability or impossibility.
- Data sovereignty and isolation. Identify the required jurisdiction, tenancy model, operator access, encryption control, backup location, and incident-response boundary. “No cloud” is often shorthand for a more specific set of conditions.
- Healthcare. HIPAA is not a blanket cloud prohibition. Atlassian’s HIPAA guidance ties coverage to eligible products and plans, the applicable agreement, and required customer configuration.
- Regulated financial entities. The DORA regulation requires ICT third-party risk and concentration-risk management; it does not simply prohibit cloud. UK firms also retain accountability under operational-resilience and outsourcing guidance.
A constraint that is real should be documented. A constraint that has not been reassessed should be tested against Atlassian’s current cloud, government, isolated-deployment, and extended-maintenance options.
Split one impossible decision into two manageable ones
Decision one: the live service-management platform. This platform must run current workflows, integrations, automation, portals, SLAs, and support operations. It may require another vendor, a different operating model, or an exception from Atlassian.
Decision two: access to historical JSM Data Center records. Historical data does not need to run the old workflows. It needs a defined retention scope, reliable search and retrieval, appropriate access control, preserved source evidence, and a tested recovery path.
Do not force the historical-record decision to inherit every integration and timeline constraint of the live migration. Solving retention separately can reduce the amount of legacy infrastructure that must remain operational while the harder platform decision continues.
What a self-hosted archive can and cannot solve
A self-hosted archive can keep the database and application inside infrastructure and jurisdictions you control. It can remove JSM Data Center application nodes and Marketplace apps from the historical access path. It can also make the archive database connection read-only.
It does not automatically reproduce the source application’s authorization model, every custom field, every Assets object, or every app-defined record. Those are acceptance-test questions.
Cortex Archive: current Jira Service Management scope
Cortex Archive is self-hosted and currently supports Jira Service Management Data Center databases on PostgreSQL. Synapse does not host the archived database. The application can authenticate users through SAML, OpenID Connect, or Windows Authentication and can connect to the archive database with a no-write account. Review the Jira data preparation guide for the current source requirements.
Authentication is not the same as source authorization. Current customer-specific validation must include:
- Custom field values. Jira stores issue-level custom field instances in
customfieldvalue. Do not claim complete field fidelity until the required fields are mapped and tested. - Complex fields. Cascading selects, Assets references, and some app-defined values may appear as raw text or JSON.
- JSM Assets. Assets tables use the AO_8542F1_* prefix and are not currently mapped into the archive UI.
- Issue security. JSM issue security levels are not currently enforced row by row in Cortex. Restricted records need a deliberate archive access model or segmentation strategy.
- Large change histories. Audit-heavy records should be performance-tested because changelog loading is not currently paged and can use significant memory.
- Marketplace and custom-app data. Inventory each app’s database tables and decide whether the data is in scope, exported separately, or retained with the source backup only.
These boundaries should appear in the proof-of-concept acceptance criteria and the migration statement of work.
Build test evidence early
Atlassian’s current Data Center licensing guidance says existing customers can request trial licenses and existing eligible self-managed customers can generate developer licenses. Teams without those entitlements may not be able to create representative test systems.
That matters because a generic PostgreSQL database cannot reveal every high-compliance configuration. Preserve a controlled production-derived copy where policy allows, or build a representative sanitized dataset containing the customer’s custom fields, Assets usage, restricted issues, largest change histories, and critical Marketplace-app records.
A practical plan for organizations that cannot move to cloud
- Revalidate the constraint. Record the exact regulatory, contractual, security, or sovereignty requirement and check Atlassian’s current options.
- Engage Atlassian. Discuss roadmap timing, government or isolated-cloud eligibility, and any extended-maintenance exception.
- Inventory the source. List products, projects, issue types, custom fields, Assets schemas, issue-security schemes, apps, integrations, attachments, and data volumes.
- Define retention outcomes. Specify how long records are kept, who can retrieve them, which fields must be readable, and what evidence auditors need.
- Preserve the database. Take a restorable backup, protect an untouched master, and document custody, checksums, restore tests, and change control.
- Run representative acceptance tests. Test fields, attachments, comments, links, history, restricted records, Assets, app data, search, performance, and recovery.
- Decommission only after sign-off. Retire the JSM Data Center runtime after the live-platform plan and historical-access plan have separate owners, evidence, and rollback paths.
Frequently Asked Questions
What happens if JSM Data Center cannot move to cloud before EOL?
Contact Atlassian about current cloud deployment options and any extended-maintenance exception. In parallel, separate historical retention from the live-platform decision so the old environment is not kept solely for record access.
Does DORA prohibit Jira Service Management Cloud?
No. DORA requires financial entities to manage ICT third-party and concentration risk and retain accountability. A firm must assess the specific service, controls, contracts, resilience, and exit strategy.
Can a self-hosted archive satisfy data-sovereignty requirements?
It can keep archived data on infrastructure and in jurisdictions the organization controls. Whether that satisfies a requirement depends on the exact storage, operator-access, encryption, backup, identity, authorization, audit, and recovery controls.
Does single sign-on preserve JSM issue security?
No. Single sign-on authenticates the user. It does not automatically reproduce project permissions or issue-level security. Current Cortex deployments must scope, segment, or otherwise control restricted source records explicitly.
What should be tested before JSM Data Center is decommissioned?
Test record counts, attachments, comments, links, custom field values, complex fields, Assets, restricted issues, app data, the largest change histories, search, performance, backup restore, and user access.
Where can I see the archive model?
Review the Jira Service Management archive overview, explore the Cortex Archive demo, and compare the regulatory planning pattern in the European Cherwell EOL article.