JSM Data Center End of Life: A Planning Checklist for US Financial Firms
If you’re a bank, insurer or other financial company licensed in New York, your asset inventory already has a column for this. Since November 2025, NYDFS has required covered entities to track each system’s support expiration date. Jira Service Management Data Center has one: March 28, 2029.
That date will end up on a slide in your migration kickoff. What usually doesn’t make the slide is the history: years of incidents, change approvals and service requests that won’t move to the new platform, but that an examiner or auditor may still ask to see.
The dates
Atlassian’s timeline for Data Center products, including JSM:
- March 30, 2026: new customers can no longer buy Data Center subscriptions or Marketplace apps.
- March 30, 2028: existing customers can no longer buy new subscriptions, apps or expansions.
- March 28, 2029, 23:59 PST: subscriptions and apps expire and go read-only. Support and critical security fixes stop.
Extended maintenance may be available by exception. Don’t build your plan around it.
The NYDFS angle
Section 500.13(a) of NYDFS Part 500 requires a documented inventory of your information systems, tracking for each one the owner, location, classification or sensitivity, support expiration date and recovery time objectives. It’s been in force since November 1, 2025.
For JSM, that means the end date belongs in the inventory now, with an owner and a plan attached. Supporting a system past its support date is a decision someone should be able to explain.
If you’re not NYDFS-regulated, the same logic still applies. Unsupported systems holding control evidence are a standard audit and exam question, and the answer is much easier when the date, owner and exit plan are already written down.
Read-only JSM is still a system to run
Come March 2029, JSM Data Center turns read-only. Some teams plan to leave it there as an archive. That means hosting, patching, backups and an owner for a system that no longer gets vendor security fixes.
It also has blind spots. Atlassian says Assets data can’t be browsed in the interface after the JSM license expires, even though it’s still in the database. If people will need those records, test how they’ll get to them before the license lapses.
Plan your test environment early
Self-service Data Center trial licenses ended on March 30, 2026. Existing customers can still ask Atlassian support or their account rep for a trial, and eligible license holders can get developer licenses. Either way, the safest test is a non-production copy of your own JSM database.
Archive readiness checklist
Test on a copy of your real configuration and record the archive version you used. Confirm that:
- Every issue field, comment, attachment, link and request type in scope is there.
- Custom field values read the same as they do in JSM, including ones stored outside the main issue record.
- Cascading selects and Assets references display proper labels.
- Assets objects and relationships come across wherever they’re part of a kept record.
- Access rules hold: permitted users can find and open records, and restricted users can’t reach them through search, record views or attachments.
- Heavy records with long change histories still open quickly.
Anything missing goes in the acceptance report, with an owner and a decision: fix it or formally accept it.
Where Cortex Archive for JSM fits in
Cortex Archive for JSM gives you a self-hosted, read-only way to search and read historical JSM data. It connects to the source database with read-only credentials, keeps its configuration separately and supports SAML and OpenID Connect sign-in. Record-level permissions still need to be set up and tested for your environment.
Test it with your own exported database, attachments and configuration on the release you plan to run. That’s the only way to confirm coverage of your custom fields, Assets and issue security.
Sign-off owners
- Service owner: the business services and control evidence that rely on JSM.
- Records owner: retention categories, periods, legal holds and disposal rules.
- Platform owner: the support end date in the asset inventory, the replacement and the timeline.
- Data lead: extraction, reconciliation and exception reporting.
- Security and business users: access testing, record context and performance.
- Accountable owner: final acceptance, handover and retirement approval.
Frequently Asked Questions
When does JSM Data Center reach end of life?
March 28, 2029 at 23:59 PST, when subscriptions and apps expire and go read-only.
Does NYDFS require us to track JSM’s end of support?
If you’re a covered entity, section 500.13(a) requires your asset inventory to track each system’s support expiration date, along with its owner and recovery time objectives.
Can we just keep JSM running read-only?
You can, but it’s still a system to host, secure and back up, without vendor security fixes. Compare that against a tested read-only archive.
Will an archive keep JSM’s issue security?
Only if you test it. Check allowed and denied access in search, records and attachments before you rely on it.
How do we validate custom fields and Assets?
Compare them against the source, test complex fields and linked Assets directly and document any gaps.
Should we migrate all JSM history to the new platform?
Move what the new platform needs. Archive what you’re required to keep. Dispose of what you aren’t.
Related reading
- JSM Data Center End of Life: A DORA Checklist for EU Financial Entities
- JSM Data Center End of Life for Healthcare and Public Sector
- Why DIY ITSM Archives Fail Audits
- Retire the Platform, Keep the History: Build vs Buy
- Cortex system requirements
Planning your JSM Data Center exit? Look at Cortex Archive for Jira Service Management and test it against your own records.