Reign OpsAtlassian Data Center end of life

Choose and execute the path for your Atlassian Data Center estate before support ends.

iTmethods assesses the products, apps, integrations, data, workflows and operating requirements in the current estate, compares the viable paths, and can plan, migrate and operate the selected target. The recommendation follows the customer’s requirements.

Available today Discuss your Atlassian estate Deployment options →

The planning dates that affect the decision

Confirm the 2028 purchasing and renewal position before planning the path to 2029.

Most plans are built against the end-of-life date. The date that actually constrains an enterprise is the one before it, when new sales and expansion end.

01Expansion ends in 2028. Renewal continues to 2029

Atlassian says existing customers can keep renewing what they hold, at their existing user tier. After the 2028 cut-off, new subscriptions, expansions, upgrades and Data Center Marketplace apps are no longer sold, but you can renew or reduce what you hold. Standard renewals are prorated so every term ends by the end-of-life date. Atlassian also offers “extended maintenance for certain Data Center customers by exception” after that date, and says some may buy a multi-year extension, with no published criteria, price or application process. Have Atlassian confirm your position in writing before you plan on it.

02Marketplace apps expire on the same day

Data Center subscriptions and their Marketplace apps expire together and become read-only.

For most estates the apps are the migration, not the platform. Inventory them first.

03Read-only is not the same as gone

On expiry the instance becomes read-only. The data stays reachable; updates, patches and vendor support do not.

An unpatched, read-only system holding live business records is one for your risk function to evaluate before then.

04Bitbucket is mostly not in this

Atlassian says Bitbucket Data Center will not reach end of life. Its standalone license does.

Atlassian says existing Data Center and Server customers get a Bitbucket Hybrid License covering Data Center and Cloud; the table below dates the change. Confirm with Atlassian that it is available to you before you plan against it. Source control and work management are two decisions on two timetables. What we run for Bitbucket Data Center →

The sequence, as published

What closes, and when.

Date	What Atlassian published	What it closes
September 2025	End of life announced for the Data Center product line.	Nothing yet. It starts the planning clock.
16 December 2025	New Data Center apps can no longer be submitted to the Marketplace.	The app inventory: nothing unlisted is arriving.
30 March 2026	New customers can no longer purchase Data Center subscriptions or Marketplace apps.	The path in for new customers.
July 2026	Isolated Cloud, Atlassian’s single-tenant Cloud offering, became generally available.	Nothing on the Data Center clock. The Cloud path can now offer single-tenant, region-locked hosting.
Early 2027 (date to follow)	Atlassian says existing customers can upgrade to the Bitbucket Hybrid License in early 2027, with the exact date to follow.	Nothing on the Data Center clock. It opens the Hybrid path for Bitbucket; confirm with Atlassian that it is available to you.
30 March 2028	Existing customers can no longer purchase new subscriptions, expansions or Marketplace apps.	Growth ends here.
28 March 2029	Data Center subscriptions and any associated Marketplace apps expire and become read-only. Standalone Bitbucket Data Center licenses also stop being available, after which Bitbucket is sold exclusively through the Hybrid License.	Support, security patches and any vendor path back for Data Center; the data remains readable. Bitbucket stays a separate decision, but not one without a date.

Until the last date above, Atlassian continues technical support, critical security fixes and the connectors from Data Center products to Atlassian Cloud. The dates close the ability to buy, not to run.

How we sourced these dates. Every date is Atlassian’s, from atlassian.com/licensing/data-center-end-of-life and atlassian.com/migration/bitbucket-hybrid-license, first read on 25 August 2026 and re-read on 27 October 2026; Atlassian states times as 23:59 PST. Atlassian’s page states no price increase and partner sources report one, so we publish no price figure. Third-party timelines can change without reference to us, and nothing here represents the views of Atlassian Pty Ltd.

Options

Three options. iTmethods can help with each one.

Staying on Data Center, moving to Atlassian Cloud and moving to another platform are all real options. Use different paths for different products: evaluate a mixed target where the requirements justify it.

Stay

Operate the current estate for a defined period

Address lifecycle, upgrade, support and capacity work while the target decision and migration plan are completed.

Whose product. Atlassian’s. Atlassian controls the product, licensing, vendor support and end-of-life terms; staying put remains your choice.

Available today What Reign Ops runs →

Cloud

Move to Atlassian Cloud

Assess product fit, marketplace apps, integrations, identity, data residency, control requirements, migration tooling, operating change and cost.

Whose product. Atlassian’s. iTmethods’ Atlassian consulting practice handles Cloud migrations and Jira Service Management implementations; Atlassian controls the Cloud product, its pricing and its roadmap. Atlassian’s published limits on Isolated Cloud: an instance cannot be migrated between regions once provisioned, it is priced at a premium, and Atlassian states some features may be unavailable.

Discuss a Cloud move →

Move

Move to another platform

Assess migration feasibility for an alternative such as Plane: workflow and data mapping, feature gaps, integrations, validation, cutover, rollback and ongoing operation.

Whose product. Plane’s. Its Community edition is open source under AGPL-3.0; the Commercial and Airgapped editions are Plane’s commercial products. Reign Ops can deploy and operate an agreed dedicated self-hosted Plane environment, the same operating model every Reign Ops platform page describes.

Available today Managed Plane →

Plane’s own commercial boundary. Its supported SAML and OIDC implementations start at the Pro plan, and its audit log API is an Enterprise Grid feature. What we enforce at the platform edge does not depend on either, but anything you want inside Plane itself does.

The part the migration plan usually misses

Whichever tracker you land on, agents will be reading it.

The work tracker holds the backlog, the incident history and the change record. Atlassian Intelligence, Jira’s own agents, MCP servers and whatever your engineers add next all read and write it at machine pace. Reign Gateway governs them at the call layer.

What the boundary adds

For each call: who made it, which policy applied, what was decided, which model answered, and when. You author the sanctioned tool catalog; the boundary enforces it.

The part worth being precise about. This governs the calls, not the tracker. It does not make a vendor’s AI feature safe, it does not change what that vendor does with the request once it leaves your boundary, and it is not a reason to choose one of the three paths over another. It means a reviewer can reconstruct what an agent asked for, what it was allowed, and what came back. How the boundary works →

Shared responsibility

Who holds what, on the way across.

Written down before anything moves.

Who	What they hold	Examples
Reign Ops (iTmethods engineers, 24×7)	Routine operating decisions, handled by the Reign Ops service once the estate is live.	Operate the instance inside your authorization boundary, enforce your identity provider at the platform edge, stream audit logs to your SIEM, patch on an upstream-matched cadence.
Your team	Decisions you own under the shared-responsibility model.	Which projects move and in what order. Workflow and field decisions. Which Marketplace apps have a destination and which are retired. The change window. Sign-off on each cut-over.
iTmethods migration engineers	The work that needs a named engineer rather than a runbook, done with your team rather than to it.	The app and workflow inventory. Migration scoping and phased cut-over. Data mapping and the dry runs before it.

Beyond SOC 2 Type II for Reign Ops, no other certification or accreditation is claimed. What each framework asks for is set out on regulatory alignment.

FAQ

Questions buyers ask

Which date should we plan against?

Plan against the earlier one: the 2028 cut-off for new sales, expansions and Marketplace apps, a year before subscriptions expire. Confirm your position with Atlassian in writing first.

Where would Plane actually run?

In a single-tenant dedicated instance inside your authorization boundary, in infrastructure iTmethods operates or in your own cloud account on AWS or Azure. Both are available today. Google Cloud is planned for 2027. Air-gapped and sovereign deployment are supported. There is no multi-tenant or shared option. Deployment options →

Do you have a view on Atlassian Cloud?

Yes: Cloud is a good answer for many estates, more since Isolated Cloud went generally available in July 2026. It is single-tenant and answers most of what data residency used to rule out. The one gap is FedRAMP High and DoD IL5: Atlassian Government Cloud is authorized at FedRAMP Moderate, and Atlassian says only that it is building High and IL5 environments ready to be submitted for authorization before Data Center ends, with no date and no listing on its published cloud roadmap. If that is your binding constraint, the Cloud path does not currently close.

How long does a Jira to Plane migration take?

We do not publish a duration. It depends on the app inventory, how many workflows must be rebuilt and your change process; the scoping call produces a written estimate.