Atlassian has officially announced the end-of-life (EOL) for Atlassian Connect, signaling a major shift for anyone developing or using apps in the Atlassian ecosystem. Over the next couple of years, Atlassian Connect, the longstanding framework for extending Jira, Confluence, and other Atlassian cloud products, will be phased out in favor of Atlassian Forge, Atlassian’s modern cloud app platform. This transition has big implications for software teams, Marketplace app vendors, and the businesses that rely on those apps. In this blog post, we break down everything you need to know about the Connect EOL: the timeline of key phases, what makes Forge different from Connect (in plain English), and how to prepare your team for a smooth migration. Both technical stakeholders and business decision-makers will find strategic insights and actionable guidance to navigate this change with confidence.
Atlassian Connect has been the backbone for cloud app development on the Atlassian Marketplace for years. It allowed developers to build add-ons that run on external servers and embed within Atlassian products via iframes. While Connect enabled a rich ecosystem of apps, it also came with challenges: app developers had to manage their own infrastructure, security tokens, and compatibility as Atlassian products evolved. From a customer perspective, installing a Connect app meant trusting a third-party service to handle data and functionality.
Atlassian Forge, introduced more recently, addresses many of these challenges by providing a cloud platform where Atlassian hosts the app code for you. Forge offers a more integrated and secure approach; think of it as Atlassian’s own serverless app environment. By moving to Forge, Atlassian aims to ensure all cloud apps run within their trusted environment, improving security, performance, and the overall user experience. In short, Forge is the future of Atlassian app development, and Atlassian is phasing out Connect to unify the ecosystem on this modern platform.
Some key reasons driving this transition include:
Security & Trust: Forge apps operate within Atlassian’s cloud infrastructure with fine-grained permissions, reducing risks compared to external Connect apps that use shared secrets and iframes.
Simplified Maintenance: Forge eliminates the need for partners or customers to host and update app servers. Atlassian handles the heavy lifting of scaling and infrastructure, so developers can focus on functionality.
Unified Experience: With Forge’s native UI components and authentication, apps feel more seamlessly integrated into Jira or Confluence. This creates a smoother experience for end users than the older Connect approach.
Future Innovation: Atlassian is investing heavily in Forge. New extensibility features, performance improvements, and product integrations will arrive on Forge first (and sometimes only on Forge). Connect, on the other hand, will not receive new features as it winds down.
Atlassian is taking a phased approach to retire Atlassian Connect, giving organizations time to adapt. There are three key phases in the Connect End-of-Life timeline, each with its own policies and enforcement dates:
Phase One: No New Connect Apps on Marketplace (Enforcement: September 17, 2025) Starting in mid-September 2025, Atlassian Marketplace will no longer accept new apps built on Connect. Any new cloud app listing must be built on Forge and contain no Connect modules. Existing Connect apps already listed on the Marketplace can remain for now, but this marks the cutoff for any new Connect-based offerings. (Atlassian announced this phase in March 2025, providing roughly 6 months’ notice before enforcement.)
Phase Two: No New Updates to Connect Apps (Enforcement: March 2026) In early 2026, Atlassian will stop allowing updates to apps that rely on the Connect framework. After this point, Marketplace apps using a Connect descriptor cannot ship new versions or changes. Essentially, if an app is still on Connect by March 2026, the developer won’t be able to publish further enhancements or fixes through the Marketplace. This is a strong signal for vendors to migrate active apps to Forge before this deadline. Additionally, the ability to install new private Connect apps (custom apps via direct installation) will be disabled; any new custom extensions should use Forge going forward. Apps that have adopted Forge (even if they originally had some Connect components) will be able to continue updating, but pure Connect apps will be frozen from updates.
Phase Three: Connect Reaches End of Support (Enforcement: Q4 2026) By late 2026, Atlassian Connect will enter a true end-of-support state. This is the final stage: Atlassian will no longer actively maintain the Connect platform. Connect-based apps may continue to run for a period of time at your own risk, but Atlassian will not guarantee their functionality as Jira, Confluence, and other products continue to evolve. In this phase, Atlassian will stop issuing new features or non-critical bug fixes for Connect. Only critical security issues might still be addressed, and even those could have slower response times. Essentially, any Connect components that break due to product changes might not be fixed unless there’s a Forge equivalent also affected. For customers, Atlassian will likely display warnings in Marketplace about apps in this unsupported state. This phase signals that Forge is now the only fully supported way forward. Organizations should plan to have migrated off Connect by this time to avoid running unsupported apps.
For those less familiar with the technical side, here’s a plain-language breakdown of how Atlassian Forge differs from Connect and why it matters:
Hosting and Infrastructure: Connect apps run on external servers or cloud services managed by the app developer or vendor. In contrast, Forge apps run on Atlassian’s infrastructure (in a secure AWS Lambda-based environment managed by Atlassian). This means with Forge, you don’t need to run your own server; Atlassian handles the execution of your app’s code whenever needed. For businesses, this shift means less worry about third-party servers handling your data; everything stays within Atlassian’s cloud.
Authentication and Security: Connect uses JSON Web Tokens (JWT) for authentication, where the app and Atlassian exchange tokens to prove identity. This requires careful handling of secrets on the developer’s side. Forge uses Atlassian’s OAuth 2.0 system and built-in permissions (scopes) for apps. Forge apps operate within a sandbox with strict controls, aligning with Atlassian’s cloud security standards out-of-the-box. The result is a more secure model with Forge. For example, Forge apps can’t access data or make calls outside the permissions you grant, and Atlassian can enforce security policies globally.
User Interface Integration: Connect apps inject UI elements into Atlassian products via iframes (essentially embedded web pages). While functional, iframes can sometimes feel a bit isolated or load slightly slower, and styling must match Atlassian’s look manually. Forge apps can use Atlassian’s Forge UI kits or custom UI options that render content more natively inside the product interface. This means Forge UIs tend to be more seamless and consistent with the host application’s look and feel. In practical terms, Forge can provide a smoother user experience, as the app’s interface is tightly integrated (and there’s no separate server call to fetch an iframe for each view).
Development and Deployment: With Connect, developers had to write a web application, host it, maintain the Connect descriptor (a JSON file listing all the integration points), and handle updates themselves. Deployment might involve updating servers or cloud services and then updating the app descriptor. With Forge, development involves writing functions (in Node.js or similar) and defining a Forge manifest (YAML) for app capabilities. Deploying is as simple as running a CLI command to push the app to Atlassian’s cloud. Forge handles the rest: provisioning, scaling, and updating the app in the Marketplace automatically. This can greatly simplify the lifecycle of an app for development teams.
Capabilities and Limitations: Over time, Atlassian has been bridging the gap so that most Connect features have Forge equivalents. Forge now supports a wide range of modules (like UI components, web triggers, scheduled tasks, etc.) that cover the majority of use cases from Connect. However, not everything is identical: a few Connect modules or low-level capabilities are not available on Forge, often due to security or low usage reasons. (Atlassian has published lists of which Connect features are available in Forge and which are not planned.) For most apps, Forge will meet all needs, but if you have a very specific Connect feature your app relies on, you should check Atlassian’s documentation to see if Forge supports it or if there’s a roadmap for it. The good news is Atlassian is continually adding to Forge, and any critical gaps for popular apps are likely being addressed.
Performance and Scalability: Because Forge runs within Atlassian’s cloud, users may experience faster load times for certain interactions (no need to reach out to an external site for data that Atlassian could already have in-cloud). Atlassian also manages scaling the app code execution: for example, if your app suddenly gets heavy usage, Atlassian’s platform will scale up the compute power, something a Connect vendor would have to handle themselves. That said, Forge has usage quotas and limits (to prevent abuse and ensure fairness in a multi-tenant environment), but these are generally generous and Atlassian provides guidance on them. For businesses, Atlassian-managed scaling means potentially more reliable apps with less downtime.
In summary, Forge is designed to make apps safer, easier to manage, and better integrated into the Atlassian Cloud experience. Connect was a great solution in its time, but Forge is the evolution that aligns with Atlassian’s cloud-first, security-first strategy.
With the end-of-support dates on the horizon, it’s crucial to start planning your migration from Connect to Forge sooner rather than later. A successful transition involves both technical preparation and strategic planning. Here are actionable steps and considerations for teams preparing to navigate the Connect EOL:
Audit Your Atlassian Apps: Begin with a thorough inventory of all Atlassian apps (both those you’ve built in-house and third-party Marketplace apps you’ve installed). Identify which ones are Atlassian Connect apps. For in-house (custom) Connect apps, this should be well-known. For Marketplace apps, you can usually find in the app documentation or listing whether it’s built on Connect or Forge. This audit will clarify your exposure to the Connect EOL and prioritize what needs attention.
For In-House Developers: Start Experimenting with Forge If your development team maintains custom Connect apps or integrations, encourage them to get hands-on with Atlassian Forge as early as possible. Set up a development environment for Forge and try migrating a small, non-critical part of a Connect app to Forge as a pilot. This will reveal any learning curve issues or feature gaps while you still have time to adjust. Atlassian provides documentation, migration guides, and even a Forge migration toolkit to assist developers. It may also be wise to review Atlassian’s Forge Equivalence Roadmap (which shows the status of various features on Forge) to ensure the features you need are supported. If some needed feature isn’t available yet, you’ll need to plan around that, possibly waiting until Atlassian implements it, or finding an alternative approach using Forge’s existing features.
For Business and IT Leaders: Engage with App Vendors If you rely on third-party Marketplace apps that are built on Connect, reach out to those vendors or watch their announcements. Reputable app vendors are likely already working on Forge versions of their apps, given Atlassian’s timeline. However, it’s important to confirm this. Ask vendors about their migration roadmap to Forge and expected timelines. Most vendors will aim to migrate well before Phase 3 (end of 2026) to avoid disruption. If a critical app has no clear Forge migration plan, you might need to evaluate alternatives in the Marketplace or involve Atlassian/partners for guidance. Your goal is to avoid being stuck with an essential tool that suddenly isn’t supported.
Plan Updates and Testing Cycles: Migrating from Connect to Forge isn’t just a flip of a switch; it will involve refactoring code, deploying the new app version, and testing it thoroughly within your Jira/Confluence environment. Build a timeline for these activities aligned with Atlassian’s phases. For example, aim to have any custom app fully on Forge (and the Connect version deprecated) by Q2–Q3 2026, ahead of the end-of-support in Q4 2026. This buffer gives you time to catch and resolve any issues. Coordinate with stakeholders to schedule testing in a staging environment, and possibly run the Forge app in parallel with the Connect app for a short period to compare results and ensure feature parity.
Consider a Phased Migration or Hybrid Approach Atlassian allows some level of a hybrid app during the transition: an app can technically include both a Connect descriptor and a Forge manifest (this is sometimes called “Bridge” or Forge remote for Connect). While ultimately you need to remove all Connect modules, you can use this to incrementally move functionality. For instance, you might migrate backend services to Forge (using Forge functions or Forge Remote calls to your existing server) while temporarily still using some Connect modules for UI until the Forge UI is ready. This phased approach can reduce risk by not changing everything at once. Keep in mind, though, that by Phase 2 (March 2026) any update will require a Forge manifest in the app, so any hybrid approach should be completed by then.
Budget and Resource Allocation: From a project management perspective, ensure you allocate the necessary resources, budget, and time for this migration. While Forge development can be quicker than Connect in some respects, there will be effort involved in redesigning parts of the app and retesting. If you have multiple apps to migrate, decide if you need additional staff or external help (such as an Atlassian Solution Partner) to meet the timelines. The Connect EOL is a fixed deadline, so treat these migrations as high-priority projects in 2025–2026.
Leverage Atlassian and Partner Support: Don’t go it alone if you don’t have to. Atlassian has provided tools (like Forge Migration Guides, example code, and community support) specifically to help with this transition. Take advantage of Atlassian Community forums to ask questions; many developers are in the same boat, and Atlassian engineers are actively helping with Forge adoption issues. Additionally, consider engaging with Atlassian Solution Partners (like Atlas Bench) who specialize in Atlassian migrations. We’ve worked with many clients on cloud migrations and app development, so we can share best practices or even shoulder some of the migration workload for you. Sometimes an experienced partner can save you time by avoiding pitfalls others have encountered.
Communicate to End Users: If the Connect-to-Forge migration will cause any noticeable changes for your end users, have a communication plan. Ideally, a well-done migration is transparent (users shouldn’t notice if an app now runs on Forge except maybe things working faster or more reliably). But if there will be downtime or reconfiguration needed (perhaps users need to reauthorize a Forge app, or there’s a slight UX change), let your team or customers know in advance. This will build confidence that you’re proactively managing the change. From the business angle, proactive communication shows you’re on top of the transition and helps avoid confusion when Phase 3 arrives and Atlassian starts messaging about deprecated Connect apps.
By following these steps, your organization will be in a strong position to navigate the shift from Connect to Forge with minimal disruption. The key is to start early and treat the migration as a strategic initiative, not a last-minute fix. With good planning, you might even turn this into an opportunity, perhaps improving some app features during the rebuild or streamlining your app portfolio.
The end-of-life of Atlassian Connect marks a significant evolution in the Atlassian ecosystem. While change can be challenging, Atlassian’s phased approach and the robust capabilities of Forge provide a clear path forward. By understanding the timeline and differences, and by preparing diligently, technical teams can ensure their apps and integrations continue to thrive on Forge. Business decision-makers, meanwhile, can take comfort that this transition is aimed at better security, reliability, and innovation for the tools your organization relies on. In essence, Forge is the future of extending Atlassian products, and those who adapt early will reap the benefits of a more streamlined and secure app experience.