Limitations and differences

There are currently some differences when registering your existing Connect app on Forge.

If you're blocked by one of these limitations, make sure you watch the related Jira issue (press W on your keyboard). Along with keeping you up to date, this also helps us prioritize the most needed features.

Differences

When adopting Forge for your Connect app, there are some differences and caveats to what a developer may be used to:

1. The first update to Forge may or may not require Admin approval (major update)

2. Non-admin-approved updates will roll out quickly, without callbacks

3. License must stay consistent

4. Updates to Forge will show as a 'new installation' in audit log

5. Some modules can not be migrated from Connect to Forge types

6. App keys need to be manually handled across dev/stage/prod

7. App Migration Platform only supports Connect modules

8. Remote realm migration hooks

1. The first update to Forge may or may not require Admin approval (major update)

When a Forge version of your app is made public on the Marketplace, it may be eligible for Non-admin approved updates if the new Forge version doesn't request elevated permissions compared to the Connect version.

This upgrade applies different criteria to your app when determining whether your app updates require a major version update, and should result in fewer major version updates for your app. If the customer's current installation of your Connect app and the most recent version of your Forge app satisfy the criteria, the app will be automatically rolled out to customers without requiring admin approval, enabling your customers to access the latest functionality of your app without administrator involvement.

See Versioning in Connect Vs Forge for more detail on how versioning is different.

2. Updates that do not require admin approval (automatic updates) will roll out quickly, without callbacks

For a Forge app using Connect modules, updates that do not require admin approval - automatic updates (micro updates for Connect, minor updates for Forge) will roll out at the same speed as Forge updates (within minutes).

See Versioning in Connect Vs Forge for more detail on how versioning is different.

3. License must stay consistent

When registering your existing Connect-only app on Forge, the licensing must stay consistent.

A paid connect app (enableLicensing: true in the descriptor) must be replaced by a paid Forge app (app.licensing.enabled: true), and an unpaid Connect app by an unpaid Forge app.

The licensing status of the app can't be changed until all installations have migrated to Forge. There are currently no plans to address this, as it only affects apps that are in the process of updating to a Forge version.

4. Updates to Forge will show as a 'new installation' in audit log

An update that moves from Connect-only to adopting Forge shows as a new installation in the UPM audit log. There are currently no plans to address this.

5. Some modules can not be migrated from Connect to Forge types

Retaining a module's existing data when migrating their Connect equivalent to a Forge version is currently supported only for the following module types:

• Confluence Macros
• Confluence Custom Content
• Jira dashboard items
• Jira workflow modules
• Jira Global and Project Permissions

6. App keys need to be manually handled across dev/stage/prod

app.connect.key can and should be set differently in different environments, but the field in the manifest is not environment-specific. This means app.connect.key needs to be changed to the appropriate key before running forge deploy to different environments.

See Developing with Connect and Forge for more information on how to best handle app keys.

7. App Migration Platform

The app migration platform now supports automated migrations from Server/DC to Forge. Apps using Connect on Forge can continue to use the Connect migration pathways. It's important to note that if you are using a module with an automated migration pathway (such as custom fields), you must align with the automated migration platform based on the module type. For example, if you maintain your Connect custom field module, you should follow the Connect migration approach. Conversely, if you modify this to a Forge custom field module, you should adopt the Forge migration approach.

8. Remote realm migration hooks

Unlike Connect apps, which use JSON Web Token (JWT), Forge remote migration hooks use Forge Invocation Token (FIT). Instead of validating a JWT, your remote endpoint must validate the FIT token included in the request header — providing stronger security and aligning with Forge’s event-driven model.

See Support data residency realm migrations for Forge remotes for more information on setting this up.

Next steps

Now that you're aware of the differences, you're ready to start adopting Forge in your Connect app.