Connect Apps After End of Support: What Customers Should Do Now

Atlassian’s End of Support for Connect is set, and the timeline is moving. Since late March 2026, Connect apps can no longer update their descriptors. New features, permissions, or modules are effectively frozen. By Q4 2026 at the latest, regular support will end entirely.

We covered what this means for customers back in March. This article goes a step further: which Connect apps are still in use – and what should you do about them?

Not All Connect Apps Are Equal

It’s worth dividing your app inventory into three categories:

Apps for which a Forge version exists – the vendor has migrated or is in the process of doing so. Often, you will see apps in a “mid-migration” state. Thanks to approaches like Connect on Forge, vendors don’t have to scrap their entire server infrastructure overnight. Instead, they can securely embed their existing backend logic into the new Forge framework. The required action here is limited: check whether the migration is complete, and if not, ask your vendor for a timeline.

Apps from vendors who are no longer actively developing – no Forge successor in sight, no communication. These apps represent the greatest medium-term risk. They may still run, but without security updates and without any guarantee they’ll remain compatible after Atlassian-side changes.

Internally developed Connect apps – often the blind spot in any app audit. Many organisations have built their own Connect apps over the years that never reached the Marketplace and therefore fall outside the usual vendor communication process. Since March 2026, Atlassian no longer permits descriptor updates to these private apps. This means no new features or permission changes can be deployed. Because there is no external vendor to handle the heavy lifting, the burden of migration falls entirely on your internal teams, making action here highly urgent.

What “End of Support” Means in Practice

A common misconception: Connect apps won’t simply be switched off. They won’t stop working overnight. What happens instead is gradual – and that’s precisely what makes it tricky.

Atlassian has reserved the right to patch only critical security vulnerabilities. New app versions can no longer be delivered through the Marketplace. Basic backend fixes remain technically possible since Connect code runs on the vendor’s own servers – but any meaningful feature development is effectively blocked. And as Atlassian continues to evolve its own cloud infrastructure, there’s no longer any guarantee that existing Connect apps will remain compatible with it.

For compliance-sensitive environments, there’s an additional consideration: Connect apps run on the vendor’s servers, not on Atlassian’s infrastructure. This has always been a difference from Forge, but it becomes even more relevant after EOS when the vendor is no longer providing active maintenance.

Analysing Your App Inventory

Before you can act, you need clarity on what’s actually in use. Two practical approaches:

On forge-apps.com, you can see at a glance whether any Marketplace app runs on Connect, Forge, or is mid-migration. This is the fastest way to get an initial overview of your known Marketplace apps.

For internally developed and other installed apps, check the Jira or Confluence administration: under Manage apps, all installed apps are listed. Keep a close eye out for platform notifications or warning banners regarding the Connect End of Support timeline that Atlassian displays for affected apps. Apps without a “Runs on Atlassian” badge and without a Forge designation are the ones you need to focus on.

Options Depending on Your Situation

Push your vendor to complete the Forge migration. For actively maintained apps, this is the most straightforward path. Many vendors are communicating their migration timelines proactively – if yours isn’t, a direct inquiry is warranted. If you depend on an app and receive no response, treat that as a strong signal.

Evaluate alternative apps. If a vendor isn’t migrating or has stopped development, now is the right time to look at alternatives – not in Q4, when pressure is high. The Marketplace now has Forge-native options in many categories.

Decommission apps that are no longer in use. App audits frequently surface tools that nobody actively uses anymore. This is a good opportunity to clean up your inventory and eliminate unnecessary security risks.

Migrate internal Connect apps. For custom-built apps, there’s no way around making the switch. Initiating a Forge migration – whether internally or through a partner – takes time. Planning, development, and testing should not be left to the last minute.

Continue running the app with documented risk acceptance. In some cases, switching isn’t immediately feasible. That’s not a disaster, but it should be a deliberate decision – with the risk formally documented and a concrete deadline by which a solution will be in place.

Conclusion

The Connect EOS is not a one-time event that happens and then is done. It’s the starting point for an ongoing app governance question: which apps are running in my instance, on which platform, maintained by whom – and what do I do when that changes?

Teams that conduct a structured inventory now will be better positioned than those who defer the exercise until Atlassian takes its next step in Q4.

Is your team assessing its Connect app exposure or planning a Forge migration? Our experienced Atlassian development teams support you with architecture, development, and certification. Get in touch via email or simply schedule an initial remote meeting with us.