Jira Governance Suite

Moving regulated Jira to cloud: keep your change control

Atlassian ends Jira Data Center in March 2029. Regulated teams must move to Jira Cloud and keep the controls their auditors test: an approval that stays bound to what was approved, a Definition of Done that blocks the move to Done, and evidence for each change. This page states the dates, what you must replace, what our apps cover, and what they do not.

Status on 8 November 2026: the four apps are waiting for Atlassian Marketplace approval.

1. The Data Center timeline

Date	What happens	Source
16 December 2025	New Data Center apps can no longer be submitted to the Atlassian Marketplace.	Atlassian developer blog, 8 September 2025
30 March 2026	New customers can no longer buy Data Center subscriptions or new Marketplace Data Center apps.	Atlassian, Data Center end of life
30 March 2028	Existing customers can no longer buy new subscriptions, expansions or Marketplace Data Center apps.	Atlassian, Data Center end of life
28 March 2029	End of life. Data Center products and apps become read-only. Atlassian offers extended maintenance only by exception.	Atlassian, Data Center end of life

The cloud targets for regulated teams are Jira Cloud with data residency, Atlassian Isolated Cloud (single tenant) and Atlassian Government Cloud (FedRAMP Moderate, for US government). See Atlassian cloud deployment options. Dates checked on 8 November 2026.

2. What regulated teams must replace

Data Center apps do not run in cloud. A Data Center app is a Java plugin that runs on infrastructure you manage. Jira Cloud apps are a different build. When an app has no cloud version, the Jira Cloud Migration Assistant shows "This app is not available in cloud" and lets you choose an alternative.
Alternatives are not recommendations. Atlassian says the alternatives it shows "are not recommended by Atlassian, and are selected based on similarity in functionality" (Atlassian, Audit apps for your migration to cloud). Check each one against the control you need.
Cloud versions can differ. Some apps that have a cloud version list features as Data Center only. Read each vendor's own comparison page before you plan.
In-house plugins and scripts have no cloud version. A validator or condition that your team wrote must be rebuilt.
Old app data may not move. A migration path of "No path" means the app's data does not migrate. Plan how to keep old approval records available after Data Center becomes read-only.

3. What the suite covers

Our apps support compliance; they do not make a team compliant. Your auditor decides. The full mapping is on the compliance and security mapping page.

Control	App	What it does in Jira Cloud
SOC 2 CC8.1: change authorization	LedgerSeal	Records the approver, the time, the meaning of the approval and a SHA-256 snapshot of the issue at approval. A Jira workflow validator blocks the release transition for issues that are not sealed.
SOC 2 CC8.1: post-approval integrity	LedgerSeal	Detects changes to covered fields, comments and attachments after approval. The validator blocks the release transition until an approver approves the changes.
SOC 2 CC8.1: separation of duties	LedgerSeal & DefinitionGuard	LedgerSeal refuses an approval or a revoke from anyone who changed a covered field, a comment, a work log or an attachment since the last seal. DefinitionGuard lets admins mark items that the assignee may not tick or waive.
SOC 2 CC8.1: testing evidence	DefinitionGuard	On Definition of Done items an admin marks "Evidence required", an item is ticked only with evidence (a link or a note). Once a Jira admin adds the DefinitionGuard validator to the transitions into Done, an issue with an open mandatory item cannot move into Done. It checks the link format, not the content behind the link.
ISO/IEC 27001:2022 A.8.32: formal approval	LedgerSeal & DefinitionGuard	Workflow validators enforce approval seals and completed Definition of Done items before release transitions. A Jira admin adds each validator to each transition.
ISO/IEC 27001:2022 A.8.32: record of changes	All four	Seals, detected changes, approvals of changes, revokes, Definition of Done ticks and waivers are recorded with timestamps. FourRealities shows, per issue, which evidence exists. CascadePlan writes to Jira only as the signed-in user, so Jira's own history records each change.
21 CFR 11.10(e): audit trails	LedgerSeal	Supported. Tamper-evident, hash-chained records of seals, detected changes, reasons, approvals of changes and revokes, which can be checked with the offline verifier. The chain does not stop someone who can rewrite the app storage (including the vendor) from writing a new consistent chain.
21 CFR 11.50: signature manifestations	LedgerSeal	Partly met. Each seal records the date, time and meaning of the signature. The signer's name is shown from their Atlassian account while it exists; after the account is closed, it is shown as a deleted user, so a printed name is not kept in the record.
21 CFR 11.70: signature linking	LedgerSeal	The attestation, with the snapshot hash and certificate ID, is signed with Ed25519 by the app, not by the approver. Your auditor decides whether this meets 11.70.
21 CFR 11.200 / 11.300: signature components and controls	LedgerSeal	Not met. LedgerSeal does not re-authenticate the signer and does not perform two-component signing. Use your own controls if your predicate rules need Part 11 signatures.

What the suite does not do

It does not certify your team or make it compliant.
It does not provide 21 CFR Part 11 electronic signatures by itself.
It has no approval routing with several steps or parallel approvers.
It does not approve or control Confluence pages or documents.
It is not a general Jira audit log of admin and configuration events.
It does not import approval records from Data Center apps.
Asymm Systems holds the signing keys, so the signatures do not protect against the vendor.

4. Data residency and Runs on Atlassian

Forge only. All four apps run on Atlassian Forge compute. Asymm Systems operates no servers for them.
No egress. No app manifest declares an external egress endpoint. The apps call only Atlassian APIs of your own site.
Data stays in Atlassian. App data is kept in Atlassian Forge storage for your installation and as Jira issue properties on your own issues, under Atlassian's data residency rules for Forge apps. Jira Cloud data residency regions include the US, the EU, Germany, Switzerland, the UK, Canada, Australia, Japan, Singapore, India and South Korea (Atlassian, Data residency).
Runs on Atlassian. All four apps are eligible for Runs on Atlassian (Forge eligibility check, 8 November 2026): Atlassian-hosted compute and storage only, and no egress. Atlassian shows the badge itself on each listing once the app is listed (Forge docs, Runs on Atlassian).
Personal data. The privacy policy states what each app stores and how it is deleted.

5. Isolated Cloud and Government Cloud

Atlassian cloud	Status of our apps on 8 November 2026	What it needs
Jira Cloud (Standard, Premium, Enterprise, with data residency)	Waiting for Atlassian Marketplace approval.	Atlassian's review of each app.
Atlassian Isolated Cloud	Planned. Not available yet.	Isolated Cloud supports Forge apps only, and blocks egress by default. Our apps are Forge only with no egress. Atlassian also needs a live cloud listing first, then a separate app id and a separate Isolated Cloud listing (Atlassian, Publish and list Isolated Cloud apps).
Atlassian Government Cloud	Planned. Onboarding has not started.	A developer licence from Atlassian, a separate app id and listing, and Atlassian's 16 security requirements for Government Cloud apps (Atlassian, AGC security requirements). In Government Cloud, Atlassian support installs apps, and each customer runs its own security assessment of each app.

6. Migration checklist for change control

List every workflow transition that a control depends on: approval, release, move to Done.
For each, name the app, plugin or script that enforces it, and the rule it supports (SOC 2 CC8.1, ISO 27001 A.8.32, 21 CFR Part 11).
Run the app assessment in the Jira Cloud Migration Assistant. Note every app that is not available in cloud.
For apps with a cloud version, read the vendor's own feature comparison. Look for the row your control depends on.
Choose the cloud target: data residency region, Isolated Cloud or Government Cloud. Check that each app is available there.
Rebuild each control in cloud. Check who adds each validator to each transition.
If your predicate rules need Part 11 electronic signatures, choose the control that re-authenticates the signer.
Decide how Data Center records stay available after 28 March 2029.
Run the security review of each app: scopes, egress, data storage, privacy policy, security policy.
For GxP work, validate the cloud system and its apps for their intended use, and keep the test evidence.
Update the procedures and train approvers and admins. The auditor tests the procedure, not only the tool.