I’m glad to hear that the originally-proposed Bitbucket dates were not a sign of things to come for the rest of the Connect ecosystem. I have one further comment about dates:
One point that I had not registered based on the original blog post was that the beginning of phase 2 (“All app updates must be delivered by Forge”) seems like the end of Connect for Marketplace vendors, at least commercially speaking.
The title of that section (“All app updates must be delivered via Forge”) does not seem to quite summarize the entire gravity, but if I am reading it correctly, it means:
Connect apps can no longer be installed on customer instances. Therefore, no more evaluations can be performed, and thus no new sales are possible from this date forward. I infer that even customers who are setting up sandbox instances will no longer be able to delete and recreate the sandbox and maintain the vendor’s app (“The ability to upload new Connect apps to Jira and Confluence instances will also be phased out”). None of this would be commercially tenable.
Connect descriptor updates will no longer be possible, meaning that the app cannot respond to any changes that might otherwise be required by the Atlassian platform (say, renaming “issues” to “work items”, changes in permissions or required scopes, etc) and internal vendor changes become much more difficult.
Assuming these are correct, vendors are effectively forced to adopt Forge by the beginning of phase 2 (unless they want their products to die). I would hope/suggest that the “at least six months for each phase” promised here could be “at least 12 months” for this particular phase, because it seems like the most critical.
Since all serious apps would really need to be migrated by the time this goes into effect, I would also hope that the prerequisites are also all delivered before that 12-month deprecation clock starts ticking, so as to give vendors sufficient time with a fully-working platform against which they can build their apps.
I definitely appreciate the already-provided commitment to deliver prerequisites before entering a given phase, so the nuance in my comment is that I hope we can avoid the situation where some prerequisites end up being tagged against phase 3, while the vendor community most likely needs all of them before phase 2 starts.
@SeanBourke / @asridhara can I also add as a prerequisite to starting Phase 1 the requirement to add documentation on how to perform data migrations from Connect to Forge?
More specifically:
how to match Connect instances to Forge instances
authentication between Connect & Forge
different strategies (bulk import vs lazy migration, and how to work around limitations)
Input on how to get direct access to forge storage options and/or how to use web triggers or schedulers to get the data across
This is really important for existing apps to be able to migrate and it seems that there isn’t much information about this yet. A lot of vendors are now re-inventing the wheel and it would be great if there was some guidance from Atlassian.
This thread worries me a bit, but I appreciate the open discussion.
I recently saw the announcement about retiring “Connect Apps” in the future and as someone who maintains a small Connect App in the marketplace, this raises some concerns. I initially started with Forge a couple of years ago but eventually moved away due to its missing features and performance limitations.
Wouldn’t it make more sense to first ensure that Forge fully meets developers’ needs before phasing out Connect? Migration requires a significant investment of time and resources, and without a truly robust alternative, this change feels more than premature.
I have a small Connect app on the Atlassian Marketplace, similar to @berecom
I’ve been constantly looking at the feasibility of migrating it to Forge, but the reality is that this would require a complete rewrite while still supporting the existing Connect version. I understand Atlassian’s “Runs on Atlassian” certification provides assurance for some customers. However, perhaps these customers might be better served by working directly with a vendor for a tailored solution, rather than relying solely on pre-built marketplace apps if they want zero risk.
To add to the many valid concerns already expressed… I installed the Forge CLI and got a whole bunch of warnings about deprecated and insecure dependencies:
$ npm install -g @forge/cli
npm WARN deprecated gar@1.0.4: Package no longer supported. Contact Support at https://www.npmjs.com/support for more info.
npm WARN deprecated inflight@1.0.6: This module is not supported, and leaks memory. Do not use it. Check out lru-cache if you want a good and tested way to coalesce async requests by a key value, which is much more comprehensive and powerful.
npm WARN deprecated lodash.pick@4.4.0: This package is deprecated. Use destructuring assignment syntax instead.
npm WARN deprecated npmlog@4.1.2: This package is no longer supported.
npm WARN deprecated lodash.isequal@4.5.0: This package is deprecated. Use require('node:util').isDeepStrictEqual instead.
npm WARN deprecated rimraf@3.0.2: Rimraf versions prior to v4 are no longer supported
npm WARN deprecated are-we-there-yet@1.1.7: This package is no longer supported.
npm WARN deprecated glob@7.2.3: Glob versions prior to v9 are no longer supported
npm WARN deprecated glob@8.1.0: Glob versions prior to v9 are no longer supported
npm WARN deprecated gauge@2.7.4: This package is no longer supported.
npm WARN deprecated memfs@3.6.0: this will be v4
changed 892 packages, and audited 893 packages in 16s
151 packages are looking for funding
run `npm fund` for details
27 vulnerabilities (3 low, 3 moderate, 19 high, 2 critical)
I know npm audit is a hot mess with all kinds of false positives, but this does not exactly instill confidence in this new tooling. Especially the ten dependencies listed that are no longer actively supported/maintained. Are there plans to update the Forge CLI so it’s actually production-ready?
Others have said it before, but I’ll say it again: the DX of Connect is light years better than the DX of Forge. I would much rather work on a regular web server that serves HTML pages than learn new tooling with a bespoke framework, a manual deployment process, and developer-hostile “security features” that I’ll have to learn how to work around.
And I strongly suspect any SaaS company will feel the same way. So it seems the Forge platform is catering more towards small plugin developers that don’t run their own SaaS products or other backend systems… which seems directly counter to the “enterprise ready” marketing Forge is being sold to customers with. Enterprises use big established SaaS players and want to integrate them with Atlassian, and Forge makes that way harder.
Please consider prioritizing this, as this is already coming up in our Vanta ISO / SOC2 vulnerability checking and we need to provide reasoning why we have critical dependencies in our codebase.
@scottohara Thanks for posting this comment. I ran into this issue today and just spent the past few hours trying to track down what I was doing wrong in my project. It wasn’t until I searched the forum and saw your comment that I realized that this is actually an issue in Forge. Not using type: "module" resolved the WEBPACK error for me and allowed me to invoke my function. I could probably go into a rant about wasting half a day trying to track down this issue but that would be pointless. SMH at Atlassian.
Thanks for flagging this. The team responsible for the CLI is tracking this under ECO-712 and I’ve shared your posts and concerns with them. Please follow this ticket for further updates as this progresses.
For example, impersonation, which is a blocker for many serious apps, is set to release only in June 2025, just a few months before the first stage of supposed deprecation period
The recurring theme of this entire developer platform is:
Atlassian releases an inferior v2 of an API, library, package or platform.
No developers want to voluntarily migrate to these objectively inferior versions.
PMs fearing this will impact their KPIs decide to force a short deprecation date or change requirements like “migrate by X date or lose your partner badge”.
Developers reluctantly migrate.
PMs claim success.
Repeat.
They’ll say “but X apps have already migrated”. The first migrate-or-else thing I believe began in Oct 2024 with that minimum Forge gross sales requirement change.
Go and run the numbers prior to then and tell me the percentage of apps that migrated from Connect to Forge.
Thanks for the feedback. We understand that user impersonation is an important feature for apps and that’s why we’ve prioritised it as a key capability which is required before our first phase. With that said, the first phase only impacts new apps being published to the marketplace - up until September 17 2025, it is still possible to publish Connect apps on the Marketplace.
Even once we enter phase three in the last quarter of 2026, where Connect enters end of support, Connect or Connect on Forge apps may still use Connect’s user impersonation at their own risk.
And Phase 3 might as well not exist, because once we are locked out of Manifest changes in Phase 2 the apps will start breaking due to whatever other forced manifest changes Atlassian pushes between now and then. (e.g. deprecating extension points, data residency, data migration changes) never mind being unable to make functionality changes.
It took Atlassian 2+ years to transition a handful of Confluence API’s. 11 months to ENTIRELY REBUILD all of our apps UX and backend to an unstable and mutating platform is unacceptable. The customer experience is going to be negative because of this unnecessary make work.
Sincerely
Chris Cairns
Director of Software - Digital Rose
That ticket doesn’t even mention the security vulnerabilities, which are at least half of the problem here. It only mentions the no-longer-supported dependencies. (I left a comment on the ticket noting this.)
Any rational actor would lay out a 3-5 year migration timeline for Connect>>Forge given the vast complexity and extreme impact to the entire Marketplace. Atlassian stock vests quarterly over four years so there’s little incentive for long-term projects.
From the beginning the migration should have been progressive. Forge should have never been built as a parallel platform.
