Read-Only Is Not an Archive: Jira Service Management Data Center After EOL
Quick answer
At end of life, Atlassian says affected Jira Service Management Data Center subscriptions and Marketplace apps become read-only. Your data does not disappear, but the environment still depends on infrastructure, backups, administrators, compatible apps, and unsupported software. A real archive separates historical access from the retired production stack and is validated against the fields, permissions, Assets data, and audit history your organization actually uses.
What Atlassian’s EOL announcement actually says
Atlassian lists Jira Service Management Data Center and Jira Software Data Center as separate affected products. This article is specifically about Jira Service Management Data Center, abbreviated below as JSM Data Center.
The official Data Center EOL page sets three milestones:
- March 30, 2026: new customers can no longer purchase affected Data Center subscriptions or new Marketplace Data Center apps. Existing customers continue to receive technical support, critical security fixes, and migration connectors through the EOL period.
- 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 also says some customers may receive extended maintenance by exception. That is a conversation to start with your account representative, not a general continuation plan.
Why the read-only wording is confusing
Atlassian’s EOL page says affected Data Center products become read-only and users cannot add new data or perform new actions. A separate Jira license-expiry knowledge-base article describes ordinary license expiry more narrowly: users may still work on existing issues, but cannot create new ones. It also says that if JSM and Jira Software share an instance and one license expires, the whole instance enters read-only mode.
Those statements describe different contexts, and app behavior can add more variation. Do not design a long-term retention strategy around a guessed list of buttons that will or will not work. Test your exact product mix and treat Atlassian’s EOL statement as the controlling planning assumption.
Read-only still means running the old system
A read-only JSM Data Center instance can preserve access for a time, but it is not independent of the application. You still own the operational stack:
- Servers, storage, database, networking, certificates, backups, monitoring, and disaster recovery.
- Administrators who understand the version, plugins, indexing, and recovery procedures.
- Marketplace apps and integrations that may expire, stop receiving fixes, or become incompatible.
- An internet-exposure decision for software that will no longer receive security fixes after EOL.
- A tested recovery path when hardware, a database, an index, or an app fails.
The license cost may fall away. The infrastructure, labor, security, and recovery obligations do not.
Testing is getting harder, but it is not impossible
Atlassian no longer offers Data Center purchases to net-new customers. Its current Data Center licensing guidance says existing customers can request trial licenses through their account representative, and existing commercial or academic self-managed license holders can generate developer licenses.
For vendors or teams without those entitlements, representative test environments are harder to obtain. A PostgreSQL test database can cover standard browse and search behavior, but it cannot represent every customer configuration. That makes customer-specific discovery and acceptance testing more important, especially in highly customized or regulated deployments.
What a real archive changes
An independent archive separates historical access from the production application. The aim is not to recreate workflows, automation, or live service delivery. It is to preserve a defined retention scope and make that scope searchable and readable without depending on the retired JSM Data Center runtime.
That separation can remove application nodes, Marketplace dependencies, and operational complexity from the access path. It does not remove the need to validate the source data, access model, audit evidence, and recovery process.
What Cortex Archive supports today
Cortex Archive currently supports Jira Service Management Data Center databases on PostgreSQL. It discovers available columns and maps core supported record structures for browsing and search. Before decommissioning, use the Jira data preparation guide and validate the customer’s configuration against the current product build.
The following areas require explicit scoping and testing today:
- Custom field values. Atlassian documents issue-level custom field instances in the
customfieldvaluetable. Current Cortex mapping should not be described as complete until those values are supported and verified. - Complex custom fields. Cascading selects, Assets references, and some app-defined values may render as raw text or JSON instead of a fully reconstructed field experience.
- JSM Assets. Assets data is stored in tables with the
AO_8542F1_*prefix. Those tables are not currently mapped into the archive UI. - Issue security. Application authentication can control who enters Cortex, but JSM issue security levels are not currently enforced row by row. Restricted source data needs a separate archive access design.
- Large change histories. High-volume changelogs should be performance-tested because current loading is not paged and can consume significant memory on audit-heavy records.
These are validation boundaries, not reasons to wait. They are the reasons to inventory the real configuration early, preserve the source backup, and test with representative data before the production system is retired.
A practical decision framework
- Define the retention scope. Identify projects, issue types, attachments, comments, history, custom fields, Assets data, and app-managed records that must remain available.
- Separate access from fidelity. Single sign-on can authenticate a user, but it does not prove parity with source permissions or issue security.
- Test the real schema. Use a sanitized or controlled copy of the customer database and include unusual fields, large audit trails, and restricted records.
- Set acceptance criteria. Agree on record counts, search behavior, attachment access, field rendering, security treatment, and performance before cutover.
- Preserve evidence. Keep an untouched source backup, document validation results, and record the archive version and configuration used.
- Plan both failure paths. Test restore from backup and test what happens if the archive application is unavailable.
Frequently Asked Questions
Does Jira Service Management Data Center stop working at EOL?
Atlassian says affected subscriptions and associated Marketplace apps become read-only. Data remains available, but product updates and support end, and Atlassian advises against leaving the environment internet-connected without future security fixes.
Can we keep a read-only JSM Data Center instance forever?
You can keep infrastructure running, but long-term access still depends on the database, application, apps, administrators, backups, and recovery procedures. That dependency is the core difference between read-only operation and an independent archive.
Does Cortex Archive support Jira Service Management Data Center?
Yes, for PostgreSQL-based databases and supported core record structures. Customer-specific validation is required for custom field values, complex fields, Assets, issue security, app data, and large change histories.
Is SAML or OpenID Connect enough to preserve Jira permissions?
No. Identity-provider authentication controls entry to the archive. It does not automatically reproduce JSM project permissions or issue-level security. Authorization requirements must be designed and tested separately.
Next: Review the related JSM Data Center migration article or open the Cortex Archive demo.