TechPrufer
Get started
Atlassian
Atlassian logoAtlassian · Feature trail

Adopting Forge Features in Connect Apps

17 posts · Sep 2023 – Aug 2026

What this trail covers

Atlassian is guiding app developers in migrating from the Connect framework to Forge, extending support deadlines for Connect to provide ample time for transition. The platform offers various architectural patterns and utility modules to facilitate the development and integration of Forge apps, including patterns for extending Atlassian app UIs, updating app state, reacting to events, defining capabilities, and integrating with external systems via web triggers, API routes, and Forge Remotes. This post details the end-of-support timeline for Connect and provides guidance for custom app developers to migrate to Forge, including auditing existing apps, starting Forge proofs-of-concept, and leveraging Forge resources. It also highlights the differences between Connect (externally hosted) and Forge (Atlassian-hosted) apps.

All Atlassian trails
  1. From internal tool to Marketplace: How ScriptFabric built on ForgeThis post details the journey of ScriptFabric, an internal Jira scripting tool built on Atlassian Forge, which was later productized as a Marketplace app. It highlights the decision to use JavaScript/TypeScript over Groovy for broader accessibility, the advantages of Forge's managed platform for reducing infrastructure overhead, and the learning curve associated with the Forge development lifecycle. The team's experience progressed from using Forge Studio for rapid prototyping to the Forge CLI for a feature-rich product. The post also touches on the challenges encountered during the publishing process and outlines future development directions, including AI-assisted scripting and deeper integrations with developer tools like GitHub and Bitbucket.
  2. How to Speed Up Connect to Forge Migration With AIThis post details how AI tools were used to accelerate the migration of Atlassian Marketplace apps from Connect to Forge. The authors established migration patterns by manually migrating the first app, then used AI to replicate these patterns for subsequent apps. Specific AI tasks included reworking React frontends, mapping Connect scopes to Forge equivalents, performing routine deployment and log checking, building Storybook components first, and conducting smoke testing. The post also outlines best practices for setting up AI for success, such as documenting patterns, feeding current Forge documentation, planning before execution, creating small reviewable diffs, and instructing AI to use only Forge UI components. The payoff was a significant reduction in migration time, particularly for frontend work.
  3. More ways to Build on Forge: Container Services is Now in PreviewThis post announces the Preview release of Forge Container Services, enabling the deployment of container images as persistent web services on Forge infrastructure. It details the benefits for developers, including support for existing backends, multi-language support, and long-running processes. The post outlines the available features such as a private container registry, manifest-driven deployment, observability, and a REST API, along with security measures like blue/green deployments and restricted file system permissions. It also highlights early adopter successes and provides usage statistics from the Early Access Program.
  4. Getting Ready for Connect End of SupportThis post announces an extension of the Connect end of support date to January 31, 2027. It details the technical steps for migrating from Connect to Forge, including converting `atlassian-connect.json` to `manifest.yml`, adding the `connectToForgeMigration` module with a `migrationGuideUrl`, and migrating individual modules by adding Forge equivalents. It also discusses Forge Remote as an alternative to 'Runs on Atlassian' and outlines the process for migrating Marketplace presence and revenue share. The post also provides guidance on submitting feature requests for Forge and highlights community migration stories.
  5. Forge Architectural PatternsThis post outlines various architectural patterns for Forge apps, categorized into methods for extending Atlassian apps, automation, integration without Forge Remotes, integration using Forge Remote, Jira workflow extensions, Jira custom fields, and utility patterns. It details specific patterns within each category, such as 'Surface Information and Controls to Users', 'Update Atlassian App State and Data', 'React to Atlassian App State and Data Changes', 'Define Atlassian App Capabilities', 'Out of the Box Automation', 'Automation Platform Extension', 'Send Data from External Systems to Atlassian Apps (Auth as App/User)', 'Send Data to External System – Atlassian App Initiated/Forge App User Initiated', 'Cross-App Integration', 'Single Remote', 'Customer Hosted Forge Remotes', 'Validating Workflow Transitions with Expressions/Code', 'Responding to Workflow Transitions', 'Define a Custom Field/Type', 'Fetch Custom Field Data on Demand when Editing', 'Push Custom Field Data to Jira', and utility patterns like 'Environment Variables', 'Store Data in Forge Storage Mechanisms/Atlassian App Entities', 'Scheduled Triggers', 'Async Tasks', 'Frontend Events', 'Invoke an App Backend', 'UI Interactivity', 'Run a View Background Script', 'Send Events Within/Between Forge Contexts'.
  7. Forge app implementation patternsThis post introduces several implementation patterns for Atlassian Forge apps: 1. Code sharing: A shell script-based approach to synchronize code (utilities, types) between different code areas (Custom UI, backend functions). 2. Configuration distribution: Loading configuration data upfront in each activity, making API calls to gather Jira entity IDs, and using this configuration object for subsequent API calls. Includes a tamper check hash for security. 3. AI form helper: Using the Forge LLM API to pre-fill lengthy forms, with user review and editing capabilities. 4. Long running UI operations: Performing backend tasks in chunks, passing state between asynchronous tasks, and storing state in work items for progress reporting. Results are pushed to the UI via Forge's realtime API. 5. Resolver function keys: Using TypeScript types to define and reference resolver identifiers, ensuring singular maintenance and type safety.
  8. How TitanApps Migrated Smart Checklist to Forge (and Got It to Run on Atlassian)This post details TitanApps' migration of their Smart Checklist app from Atlassian Connect to Forge. Key technical contributions include: 1. Rethinking feature delivery by organizing the migration into product functionality epics rather than technical components. 2. Solving storage and indexing challenges by using Jira issue entity properties to store hashed checklist item metadata for JQL search, and splitting raw checklist data across multiple entity properties to stay within the 30KB limit. 3. Implementing a one-step data migration strategy using four types of Jira entity properties (application user, addon, project, and issue properties) to bridge the gap between Connect and Forge storage, and developing a checkpointing system for background jobs to handle large data unpacking.
  9. Connect End of Support: What It Means for Custom Apps and How to Migrate to ForgeThis post details the end-of-support timeline for the Atlassian Connect framework, with support ending in late 2026 and the inability to push updates after March 31, 2026. It provides guidance for developers of custom Connect apps on how to identify their apps, audit their functionality, and plan a migration to Forge. Key migration steps include checking app customizability, accessing source code, auditing use cases, and starting Forge proofs-of-concept. It also clarifies the distinction between custom and Marketplace apps and the implications of using Connect modules after end of support.
  10. Meet the new Forge UI: More features, flexible experienceThis post introduces the new Forge UI Kit, which unifies the development experience by allowing Custom UI elements to be integrated into UI Kit apps via the `Frame` component. It also details enhancements to the component library with new components like Visualisation Charts, Comment, and Pressable, and customizable layout components (Stack, Inline, Box). New features like Macro-autoconversion and background scripts are also highlighted. The post mentions support for 26 languages and previews upcoming features like an Editor Component and Full Page Experiences.
  11. Announcing Connect End of Support: Timeline and Next StepsThis post announces the phased end-of-support timeline for Atlassian Connect, detailing three phases: Phase One (no new Connect apps on Marketplace starting Sep 17, 2025), Phase Two (no new updates via Connect descriptor changes starting Mar 2026), and Phase Three (Connect enters end-of-support state starting Q4 CY2026). It clarifies the distinction between Forge and Connect apps, emphasizing that apps must exclusively use Forge modules and Forge auth to be considered Forge apps. The post also highlights that certain Connect modules will not have direct Forge equivalents and provides links to updated documentation on Connect-Forge equivalences and a roadmap for Forge capabilities. It recommends developers transition to Forge for new app development and prepare existing Connect apps for migration.
  12. Taking the Ecosystem Forward: An Update on the Future of ConnectThis post announces the strategic decision to phase out support for the Connect framework and transition to Forge as Atlassian's sole app development platform. It outlines a three-phase plan for this transition: Phase 1 (no net-new Connect apps on Marketplace), Phase 2 (all app updates via Forge), and Phase 3 (Connect enters end of support). The post defines 'end of support' for Connect, emphasizing a 'use at your own risk' model with limited bug fixes and potential deprecation of integration points. It also details planning the journey to Forge, including different migration strategies (full Forge adoption, Forge remote, hybrid) and the critical first step of adopting the Forge manifest. The post highlights the availability of EAP for realm pinning and previews for realm migration, and mentions upcoming consumption-based pricing for Forge hosted capabilities.
  13. Connect apps will gain new extensibility features through ForgeThis post announces the general availability of the pathway for existing Connect apps to adopt Forge modules and capabilities. It highlights that all new platform extensibility features will be delivered exclusively through Forge. The post details the progress made in Forge, including UI Kit GA, improved Forge remote communication, and license testing for former Connect apps. It also mentions upcoming features like Rovo agent-enabled apps and Forge SQL databases. The migration process is described as streamlined with automated tooling, allowing for incremental adoption or full migration. Examples of partners adopting Forge are provided, along with their motivations for moving to Forge, such as hosted storage and data residency. The post emphasizes the benefits of Forge's built-in infrastructure and observability, leading to fewer moving parts for developers.
  14. Bringing Forge-Powered Features to Connect Apps - Inside AtlassianThis post details the technical process for Connect app developers to incrementally adopt Forge features within their existing Connect apps. It outlines the preparation steps: converting Connect descriptors to Forge manifests using a CLI tool, registering the app as a Forge app, and deploying/installing it. It also explains how to list a Forge successor on the Marketplace to transition customers. Limitations for Bitbucket Connect apps and apps using certain Connect features are mentioned, directing users to documentation for eligibility.
  15. Announcing the EAP of Forge in Bitbucket CloudThis post announces the Early Access Program (EAP) for Forge in Bitbucket Cloud, marking the introduction of Forge as a platform for extending Bitbucket Cloud's core code and CI/CD experiences. It explains the rationale behind Forge's importance for handling complex customer requirements and outlines the initial steps for developers to get started, including setting up the Forge tooling, following a Bitbucket Cloud Forge app tutorial, and referencing modules, events, and API endpoints. It also establishes the community space as the primary channel for collaboration, feedback, and support during the EAP.