Atlassian Marketplace EOL: What Happens to Your Apps After 2029

The Hard Stop Most Teams Are Not Ready For

Atlassian's Data Center end-of-life roadmap is widely known at the platform level, but the downstream implications for Marketplace apps are still catching enterprise IT and procurement teams off guard. The headline dates — no new DC subscriptions from March 2026, no licence expansions after March 2028, full read-only from March 2029 — apply not just to Jira Software, Jira Service Management, and Confluence, but to every single Marketplace app running on those instances.

When March 2029 arrives, the expiry is simultaneous and non-negotiable. Draw.io stops rendering diagrams. ScriptRunner stops executing automation. Confluence pages built on macro-heavy apps return errors where content used to be. Any custom Jira workflow relying on third-party app logic freezes at the point where that logic is triggered. For organisations that have built years of operational processes on top of Atlassian's Marketplace ecosystem, this is a fixed contractual deadline — not a vague future concern.

What makes this particularly challenging is that Marketplace app migration is not simply a byproduct of the platform migration. It requires a separate assessment process, separate vendor engagement, and in many cases the procurement of entirely different tooling where no Cloud equivalent exists. Understanding the full scope of the problem, app by app, is the first and most critical step.

The EOL Timeline: What Each Date Means for Your Apps

The critical dates for Atlassian Data Center — and by extension all DC Marketplace apps — break down as follows. Understanding what each date triggers operationally is essential for migration sequencing.

• 16 December 2025 (already passed): The Marketplace closed to new Data Center app submissions. ISVs can no longer list new DC apps. The pipeline of new DC apps is permanently shut. Vendors who had not yet built Cloud versions by this date are now racing to complete Cloud products before 2029 or exiting the market entirely.
• 30 March 2026: No new Data Center subscriptions for new Atlassian customers. Existing DC customers remain on active licences and may continue purchasing Marketplace app licences for existing apps — but this marks the formal beginning of the wind-down period. New customers entering the Atlassian ecosystem can only choose Cloud.
• 30 March 2028: The final date to purchase new DC licences, expand existing user counts, or add new Marketplace app licences. After this date, your DC app estate is fixed. You cannot add apps, expand tiers, or grow coverage. This date has significant planning implications — any app that needs to be added to your estate must be in place before March 2028.
• 28 March 2029: Full end-of-life for all DC products. All DC Marketplace app licences expire simultaneously. The apps transition to read-only and cease functioning for active workflows.

One critical exception worth noting: Bitbucket Data Center is not subject to this EOL timeline and will continue under a Hybrid Licence model. Organisations running Bitbucket DC can plan differently for that specific product. But Jira Software DC, Jira Service Management DC, and Confluence DC follow the hard March 2029 deadline without exception.

What Actually Happens to Your Apps at EOL

When the EOL date arrives, DC Marketplace apps do not simply stop receiving updates — they stop functioning for active operational use. The specific mechanics vary by app architecture, but the practical outcomes fall into consistent categories based on how apps interact with the Atlassian platform.

Confluence macro apps — tools providing diagrams, interactive tables, dynamic reporting widgets, or embedded external content — will cease rendering. Pages that depend on third-party macros will display error states or blank content blocks where functionality previously appeared. The underlying page data is preserved, but the rendered output is gone.

Jira workflow automation apps — ScriptRunner, Power Scripts, JSM workflow extensions, custom field population logic — will stop executing. Issues that relied on automated transitions, SLA triggers, or business rule enforcement will stall. ITSM workflows built on top of these apps will break at the automation layer.

Reporting and analytics apps will lose their active data connections. Historical data stored in the database is preserved, but the interfaces, dashboards, and exports built on those apps will cease to function. Teams relying on these apps for management reporting or compliance evidence gathering will lose access to live data.

Integration apps connecting Jira or Confluence to external systems — HR platforms, monitoring tools, change management systems, security tools — will drop their connections. Bidirectional data flows that operational teams depend on daily will break without warning if not migrated before the EOL date.

The transition to read-only that Atlassian has described means data is preserved but process workflows are not. For most enterprises, the value of Atlassian tools is precisely those workflows — and losing them simultaneously across an entire app estate creates operational risk that a phased, well-planned migration eliminates.

The Cloud Compatibility Gap: Approximately 30% of Apps Have No Equivalent

The assumption that every Data Center Marketplace app has a usable Cloud equivalent is one of the most dangerous planning errors we see in enterprise DC migrations. Atlassian's own documentation acknowledges three distinct scenarios when assessing any DC app for Cloud viability.

The first scenario — Cloud version with full feature parity and supported migration path — represents the best case. The vendor has invested in Cloud-native development, the feature set matches the DC version, and tooling exists to migrate app data alongside the platform. This is the outcome every organisation hopes for but only a portion of apps actually deliver.

The second scenario involves a Cloud version that exists but with meaningful feature gaps. The Cloud app covers the majority of use cases but is missing specific workflow configurations, advanced macro parameters, or admin-level capabilities that teams rely on in DC. These gaps require workarounds, native feature substitution, or change management to address.

The third scenario — and the one that demands the most urgent attention — is no viable Cloud equivalent. The vendor has not built a Cloud version, or built one that is too early-stage to support enterprise deployment, or has decided to exit the Atlassian ecosystem as DC licence revenue declines. Industry estimates consistently put this category at approximately 30% of the total Marketplace catalogue. For an enterprise running 100 apps across DC instances, that potentially means 30 apps requiring full replacement. That is a substantial discovery and procurement programme that cannot be initiated in 2028.

How to Assess Your Marketplace App Estate

The app assessment process requires structured effort. Atlassian provides tooling that is a useful starting point but does not complete the analysis on its own. The Cloud Migration Assistant shows which apps are installed across instances and whether Cloud versions exist in the Marketplace. It flags known compatibility issues at the technical level. What it does not provide is a business impact assessment, feature parity analysis, or vendor roadmap intelligence — all of which are required to make informed migration decisions.

The assessment sequence that produces reliable results follows this structure. First, generate a complete inventory of all apps installed across all DC instances, including version numbers, user counts, and annual licence costs. The App Usage for Jira tooling available in Jira DC 8.20+ provides actual usage data alongside the inventory. Many organisations discover that 20 to 40% of installed apps show low or zero active usage — these are immediate decommission candidates that should not be migrated at all. Eliminating shelfware at this stage reduces migration complexity and cost significantly.

Second, cross-reference the inventory against Cloud Marketplace availability and vendor roadmap documentation. For every app with meaningful usage, contact the ISV vendor directly and request their Cloud product release timeline, a feature parity comparison document, and their data migration tooling documentation. Vendors who cannot provide concrete answers to these questions present migration risk regardless of whether a Cloud listing exists.

Third, for apps without viable Cloud equivalents, assess whether native Atlassian Cloud features can replace the functionality. Atlassian has invested substantially in expanding what Cloud plans include natively, particularly in workflow automation, reporting, and access management. Features that previously required third-party apps are increasingly available natively, especially at Premium and Enterprise tiers. Replacing a paid app with a native Cloud capability reduces cost, simplifies the estate, and eliminates ongoing vendor dependency.

As part of the broader Cloud migration planning process for 2026, this app assessment should feed directly into the migration sequencing plan. Mission-critical apps — those supporting ITSM workflows, security controls, compliance evidence, or executive reporting — should be prioritised for early migration and parallel testing before the full platform cutover.

ISV Vendor Risk: Many Are Already Exiting

The vendor landscape for DC Marketplace apps is shifting faster than many enterprise customers realise. With new DC app submissions closed since December 2025 and licence revenue declining, ISV vendors are making hard economic decisions about their Cloud investment timelines. Some have embraced the migration, built strong Cloud-native products, and are well-positioned to support enterprise customers through 2029. Others are delaying Cloud development, scaling back support, or exiting the Atlassian ecosystem entirely.

The signals of vendor risk to watch in your assessment process include: whether the Cloud app has reached general availability or remains in beta or early access; whether the vendor has published specific data migration documentation rather than just a Cloud listing; whether their support response times have declined — a common early indicator of reduced investment; and whether they are actively participating in Atlassian's developer and partner programmes, which provides visibility into their roadmap commitment.

The pricing changes Atlassian introduced in 2026 have also shifted the economics for smaller ISVs. Compressed margins and the fixed DC EOL horizon are accelerating exit decisions for vendors who were already operating on thin economics. Enterprises should not assume that an app with a published Cloud version will necessarily have a mature, enterprise-grade Cloud product by 2029 — the development trajectory of the Cloud product needs to be tracked, not just confirmed as existing.

Contracting Strategy for the Transition Period

The period between now and March 2029 creates specific contracting dynamics for DC Marketplace app renewals. Vendors are required to align DC app licence end dates with the March 2029 EOL. This means that renewing a DC app on a one-year or two-year term today should produce a licence that terminates in March 2029 rather than extending beyond it — confirming this in the renewal documentation is worth verifying explicitly.

In renewal conversations, organisations should be requesting several contractual terms that reflect the migration reality. Pro-rated pricing that accounts for the shortened remaining term is a legitimate ask — a two-year licence being renewed now is effectively a 35-month licence to EOL, not a full 24 months of standard value. Migration support commitments — vendor assistance with data migration, feature mapping, and parallel testing — should be negotiated as part of the renewal rather than as a separate engagement. Access to the Cloud version under dual licensing, which allows organisations to run Cloud and DC concurrently during migration, should be explicitly confirmed in the renewal terms for apps where Cloud versions exist.

The Cloud contract negotiation considerations extend to Marketplace apps in the same way they apply to the core Atlassian platform. Vendors who resist migration support commitments are vendors whose readiness for the 2029 transition should be treated with scepticism. Use renewal conversations as intelligence-gathering opportunities for your migration programme, not just as administrative contract renewals.

Regulated Industries: The Isolated Cloud Dimension

Organisations in financial services, healthcare, and government face an additional layer of complexity. Apps supporting audit trails, change management workflows, access control logging, or data governance functions carry regulatory weight beyond operational workflow value. If those apps do not have compliant Cloud equivalents — or equivalents approved for Atlassian's Isolated Cloud environment — the organisation may face a compliance gap at the point of migration that cannot be resolved quickly.

Atlassian's Isolated Cloud, the dedicated deployment option for regulated industries, is launching in 2026. The Marketplace app catalogue available in Isolated Cloud will be more constrained than in standard Cloud — not all Marketplace apps will achieve Isolated Cloud certification. Regulated organisations should be mapping their compliance-critical apps against Isolated Cloud certification requirements now, as part of the broader Marketplace apps licensing and EOL impact assessment, and engaging with Atlassian directly about certification timelines for those specific apps.

What Needs to Happen Before March 2029

The organisations that manage this transition successfully share a common characteristic: they treat the Marketplace app migration as a parallel programme alongside the platform migration, not as a secondary workstream that follows once the core Jira and Confluence instances are on Cloud. The app layer carries as much operational risk as the platform layer — and for many organisations, more, because the app estate is larger and more heterogeneous than the core platform.

Full app inventory with usage analysis should be completed now. Vendor roadmap assessments and Cloud product evaluations should be underway. Gap analysis for apps without Cloud equivalents — identifying whether native Cloud features, alternative Marketplace apps, or new tooling can fill the function — should feed into the 2027 procurement and programme planning cycle. And Atlassian's dual licensing programme, which allows Cloud and DC to run in parallel during migration, should be leveraged to enable testing and validation before the DC EOL deadline.

Our Atlassian licensing and migration advisors have supported enterprises through DC-to-Cloud transitions at scale, including detailed Marketplace app assessments that cover vendor viability, Cloud feature parity, and contract negotiation for the transition period. Contact us to assess your app estate and build a migration plan that accounts for every app, not just the platform.