Connect to Forge: The Vendor Migration Pathway Through 2027
Atlassian closed the Marketplace to new Connect submissions on September 17, 2025. Existing Connect apps stay listed and keep running, but they can't add new module types. Atlassian is pushing vendors toward Forge across a two-to-three-year runway. Structure by Tempo and BigPicture by Appfire are both still on Connect; Foundation was Forge-native from day one.
What actually happened in Sept 2025?
On September 17, 2025, Atlassian closed the Marketplace to new Connect-framework app submissions. Vendors submitting a brand-new app from that date forward must build on Forge. The change was announced several months in advance on the developer community site and framed as the completion of a multi-year platform transition that began with Forge's general availability in 2021. You can read the announcement on the Atlassian developer community.
Two details are easy to miss. First, existing Connect apps are not being kicked off the platform. Apps listed on Connect before September 17, 2025 continue to run; their vendors can ship maintenance and feature updates under the Connect framework. Second, existing Connect apps cannot add new module types. If a Connect app ships with ajira:projectPage module and a set of webhooks in September 2025, it can keep updating those. But if the vendor wants to add, say, a new Rovo agent action module or a Forge Realtime subscription, they need a Forge rewrite. That restriction is what creates the migration pressure — incumbent Connect apps can't follow Atlassian's platform roadmap forward.
What does a Connect-to-Forge migration cost a vendor?
Atlassian has not published official rewrite estimates, and most vendors don't publish theirs. What we can say from public developer-community threads and from talking to Marketplace vendors is that the cost scales with the Connect app's architectural complexity. A simple Connect app — a few webhooks, an iframe UI, a small database — can be ported in a matter of weeks. A large, mature Connect app with its own compute infrastructure, custom databases, long-running background jobs, and tens of thousands of installs is a multi-quarter platform project.
The rewrite is not just a language port. Forge constrains the architecture in ways Connect doesn't: serverless function timeouts (25 seconds for standard functions, 15 minutes for async events), storage limited to Forge SQL and Forge KVS, egress restricted to explicitly-declared external.fetch domains. Code paths that assume long-lived server processes, large in-memory caches, or unrestricted HTTP need to be restructured. For a Connect app that evolved against no such constraints for a decade, a faithful port isn't possible — it's closer to a ground-up rebuild that preserves the user experience.
During the rewrite window, the engineering team is typically split across two products: the Connect incumbent that still pays the bills, and the Forge replacement that will eventually replace it. That split is the opportunity cost. Every engineer-week spent on the Forge rewrite is a week not spent on new features in the Connect product. Forge-native competitors who didn't need to rewrite are shipping new capabilities during the same window.
What's the technical blocker for big Connect apps?
Three Forge platform constraints hit large Connect apps hardest, and each one requires architectural rework rather than a simple port.
Function timeouts. Forge runs code as serverless functions. A standard Forge function must complete within 25 seconds; async event handlers get up to 15 minutes. Connect apps hosted on vendor-owned servers have no such limit — a long-running import, a cross-project JQL sweep, or a nightly reconciliation job can run for hours. Porting those workloads requires splitting them into Forge-friendly chunks backed by async events, plus new state machinery to track multi-step progress. That's real work, and it changes the product's reliability surface.
Memory and compute limits. Forge functions run with capped memory; large Connect apps often keep big in-memory graph structures (issue hierarchies, dependency caches, resource models) on a vendor-hosted server. On Forge, those structures need to move to Forge SQL and be queried on demand, which is a materially different performance model. The rewrite has to re-tune the hot paths or introduce new caching layers that work within Forge's constraints.
Custom infrastructure. Mature Connect apps often run specialized services: a search index, a graph database, a custom rules engine. Forge does not host arbitrary infrastructure. The vendor has to rebuild those capabilities on top of Forge SQL and Forge KVS, or push them out to an external service with an external.fetch declaration (which reintroduces some of the vendor-hosting review surface Forge was supposed to eliminate). Neither path is free. The full platform capabilities are documented in the Forge platform overview and the build-a-Forge-app guide.
What's Atlassian's official timeline through 2027?
Atlassian has published the submission cutoff and the general direction of the transition, but not every downstream milestone. The table below consolidates what's publicly known as of April 2026, along with the buyer implication at each phase.
| Year | Milestone | What it means for Connect apps | Buyer implication |
|---|---|---|---|
| 2025 | Sept 17 submission cutoff | New Connect apps blocked. Existing Connect apps keep running; can ship updates but cannot add new module types. | New categories begin shifting Forge-native. Connect incumbents remain the mature option. |
| 2026 | Forge feature investment accelerates | Rovo AI actions, Forge SQL, Forge Realtime, and new platform modules ship Forge-first. Connect apps cannot adopt new module-type capabilities. | Feature gap begins widening between Forge-native apps and stagnating Connect apps in the same category. |
| 2027 | Large Connect incumbents expected to ship Forge versions | Major Connect vendors complete multi-quarter rewrites and list Forge counterparts (often as separate Marketplace entries or as migration releases of the same app). | Buyers of Connect incumbents will need migration decisions: stay on the Connect listing, move to the vendor's Forge replacement, or switch to a Forge-native competitor already in production. |
| Post-2027 | No public Connect sunset date announced | Atlassian has not committed to turning off the Connect runtime. The platform continues to run Connect apps; investment direction is Forge. | Plan for Connect apps to remain available but increasingly behind on features. A hard sunset, if it comes, would be telegraphed well in advance. |
The table reflects what Atlassian and the developer community have stated publicly. If Atlassian publishes a formal Connect sunset date, that's the signal to plan active migrations. Until then, the right posture is: factor Connect-app stagnation into your vendor-review process, but don't treat existing Connect apps as imminently at risk of shutdown.
What's the buyer risk of choosing a Connect app today?
The buyer risk is not that your Connect app shuts off. It's that your Connect app stops getting better. Connect apps can't add new module types, which means they can't adopt the platform features shipping to Forge — Rovo agent actions, Forge Realtime subscriptions, new lifecycle events, and whatever future modules Atlassian introduces. If your use case depends on capabilities built after September 2025, a Connect app may never gain them.
The second risk is compliance drift. Enterprise security reviews have begun explicitly asking “is this app Forge-native?” Forge apps have structural advantages in data residency and egress control — see our pillar on Forge vs Connect security for the full breakdown, and why Forge apps don't store your data outside Atlassian for the data-egress specifics. Connect apps can meet enterprise requirements, but the review process is longer because the vendor's hosting is in scope. Some procurement teams will begin preferring Forge for new purchases on that basis alone.
The third risk is migration overhead later. If you buy a Connect app today and in 2027 the vendor ships a Forge replacement, you'll likely face a migration event of your own: export data from the Connect app, re-import into the Forge replacement, retrain users, reconfigure integrations. That's real work. Buying Forge-native today avoids the second migration.
How are Structure, BigPicture, and Foundation positioned in this transition?
Structure by Tempo is Connect-based. As the longest-tenured PPM app on the Atlassian Marketplace (~14K installs), Structure has the biggest architectural surface area to port — its own hierarchy engine, Sync Agents, baselines storage, custom formula engine. Tempo has the resources to complete the rewrite, and they are actively investing in Forge. The question is how long it takes and what feature parity looks like at first release. You can see the current Connect listing on the Structure Marketplace page.
BigPicture by Appfire is also Connect-based. Appfire is one of the largest Marketplace vendors by install count and has a mature Forge practice across many of its other apps. BigPicture's scope — Gantt, resource management, portfolio reporting, program boards — is large, and the rewrite will take time. Like Tempo, Appfire has the resources to complete it. Neither vendor has published a public Forge release date for their flagship PPM app as of April 2026.
Foundation was built Forge-native from day one. That is not a marketing claim; it's an architectural fact driven by the September 2025 deadline. Foundation launched after the cutoff, so there was no Connect option. The practical consequence is that Foundation does not carry any Connect technical debt — no vendor-hosted servers, no external databases to migrate, no module-type gap to close. The trade-off is feature depth: Foundation is earlier in its product lifecycle than Structure or BigPicture, so the feature surface is narrower. See the Foundation Marketplace listing or the Foundation security page for the current posture.
For a buyer, the three apps represent three distinct positions in the transition: Structure and BigPicture are mature products with rewrites ahead of them; Foundation is a newer product with the rewrite behind it (because it never happened). The right choice depends on how much feature depth you need today versus how much platform-transition overhead you want to absorb over the next two years. For context on the broader security frame, see our Cloud Fortified explainer.
What signals should you watch for?
If you're evaluating Connect apps in 2026 and want to track where the platform transition is actually going, watch these signals.
Public Forge release commitments. When a major Connect vendor announces a specific date for their Forge version — not a vague “coming in 2026” but a concrete quarter — that's the strongest signal that the rewrite is close. Vendors don't commit publicly until they're confident they can hit the date.
Module re-releases in Forge format. Some vendors are shipping Forge versions of individual modules (a Forge-native Gantt module, a Forge-native dashboard module) before the full Forge rewrite. These partial releases are evidence that the vendor's Forge team is productive and that the rewrite is underway. They're also a migration-path option: use the Forge module alongside the Connect core until the full rewrite ships.
Cloud Fortified status on Forge. Cloud Fortified is Atlassian's highest app-trust tier. A Forge app achieving Cloud Fortified demonstrates operational maturity. See the Cloud Fortified program page for criteria. When a Connect incumbent ships a Forge version and that version earns Cloud Fortified, the transition is effectively complete — buyers can move with confidence.
Atlassian-announced Connect sunset dates. So far, there are none. If Atlassian announces a hard Connect runtime sunset, the planning horizon compresses significantly. Monitor the Atlassian developer community for announcements.
How we assembled this view
This guide is based on Atlassian's public developer announcements, the Forge platform documentation, Marketplace listings for the apps mentioned, and conversations with other Marketplace vendors during 2025–2026. It reflects the state of the platform transition as of April 21, 2026. Specific dates for individual vendor Forge releases are not public as of this writing; any claim in this guide that refers to a specific release date comes from an Atlassian announcement linked in Sources. We build Foundation, which is Forge-native by necessity of its launch timing, so treat our framing as biased toward Forge-native adoption. Corrections welcome to [email protected].
Frequently asked questions
Did Atlassian actually ban new Connect apps, or just push vendors toward Forge?
Atlassian closed the Marketplace to new Connect-framework app submissions on September 17, 2025. That's a hard gate: a vendor submitting a brand-new app after that date must build it on Forge. It was not framed as a ban on Connect itself — installed Connect apps continue to run, and vendors can still ship updates to Connect apps that were listed before the deadline. But vendors can no longer add new module types to existing Connect apps, which effectively caps Connect apps at the feature surface they had on September 17, 2025.
How long does a Connect-to-Forge rewrite take for a large PPM app?
Atlassian has not published official rewrite estimates, and vendors rarely publish theirs, so any number is inference. What we can say from the public developer-community discussions is that non-trivial Connect apps involve months of engineering work at minimum — and for apps the size of Structure or BigPicture, with their own compute infrastructure, custom databases, and long-running background jobs, the rewrite is a multi-quarter platform project. Both vendors are resourced to do it. The question is the opportunity cost of the engineering team working on a rewrite instead of new features.
Will Structure and BigPicture fail to make the Forge transition?
No — and it would be wrong to imply that. Both Tempo (Structure) and Appfire (BigPicture) are mature, well-resourced vendors with long histories on the Atlassian Marketplace, and both are investing in Forge. Our view is that they will migrate successfully, but the transition imposes a cost disadvantage against Forge-native entrants who didn't need to rewrite. During the migration window, engineering attention is split between maintaining the Connect product and shipping the Forge replacement — a drag that Forge-native apps don't have.
What happens if a Connect app I depend on doesn't release a Forge version by 2027?
As of April 2026, Atlassian has not published a hard sunset date for Connect apps already listed on the Marketplace. The platform continues to run them. The practical concern is feature stagnation: Connect apps can't add new module types, which means they can't adopt platform features that ship as new modules (some Rovo AI hooks, some Forge-only events, new integration surfaces). If your use case depends on features that haven't been built yet, a Connect app may never gain them. For current functionality, you're fine.
Is buying a Forge-native app in a category where incumbents are still on Connect risky?
It's the inverse of the risk people usually frame it as. A Forge-native app in a Connect-heavy category faces less platform-transition risk than the incumbents — it doesn't need to rewrite itself. The counter-risk is feature depth: Connect incumbents have had years to build out capabilities that a newer Forge entrant may not have matched yet. The right trade depends on whether your team's needs are served by the Forge entrant's current feature set or whether you need the incumbent's mature surface. This is a standard build-vs-buy evaluation, not a platform-risk evaluation.
Where can I see whether a specific app is Forge or Connect before I install?
Open the Marketplace listing and look at the Hosting Options or technical details block — Atlassian labels apps as “Cloud” or “Cloud — Forge.” At install time, a Forge app presents a permission screen listing Forge scopes (read:jira-work, storage:app, etc.) and any requested external.fetch domains; a Connect app presents a simpler grant that references the vendor's hosted URL. If you can't tell from the listing, email the vendor. Any honest vendor will answer directly.
Related
- Forge vs Connect: A 2026 security guide for Jira app buyers
- Why Forge apps don't store your data outside Atlassian
- Cloud Fortified explained — what the badge actually means
- Foundation security — Forge-native, zero egress
Sources
- Atlassian Community: Changes to Marketplace app submissions from September 17, 2025
- Atlassian developer community (platform announcements)
- Atlassian Forge platform overview
- Build a Forge app — official developer guide
- Atlassian Cloud Fortified apps program
- Structure by Tempo — Atlassian Marketplace listing
- Foundation for Jira — Atlassian Marketplace listing