I mapped every Connect module to its Forge equivalent — here's the tool, please tell me where it's wrong

Forge Adopting Forge from Connect
, , , ,
1

I’ve been working through the Connect→Forge migration and kept re-deriving the same question for every module: does this have a Forge equivalent, and if so how much does the behaviour change?

So I put Atlassian’s equivalence tables into something you can point at a descriptor. Paste a URL or the JSON, get a module-by-module breakdown with blockers, behavioural caveats and a rough effort estimate.

https://connect-forge-analyzer.vercel.app

Three things I found while building it that might save you time regardless of whether you use it:

1. Web item and panel locations matter more than the module. webItems isn’t one migration decision, it’s one per location. system.content.action maps cleanly to confluence:contentAction; several locations have no documented equivalent at all. Same module, completely different amount of work.

2. Some real modules are missing from the equivalence table entirely. webSections, jiraReports, jiraSearchRequestViews, confluenceThemes, spaceViews, and the version/component/profile tab panels. Absence isn’t proof no equivalent exists, but if you’re relying on one of these, find out before you scope.

3. The platform-level changes bite harder than the modules. The enabled/disabled/installed lifecycle events stop firing — if your provisioning logic depends on them it needs rewriting. And unlicensed/anonymous access silently disappears unless you explicitly declare unlicensedAccess.

What it can’t do: it reads your descriptor, not your code. Everyone who’s done a migration says the frontend is the longest part, and a descriptor tells you nothing about that. The day estimates are a heuristic for scoping conversations, not a quote.

The mapping is transcribed from Atlassian’s published docs as of August 2026, and they revise those tables. If you’ve done a migration and something here is wrong, please say so — I’d rather fix it than have someone plan against a bad number. Source is on GitHub - UmairAhmed29/connect-forge-analyzer: Analyze an Atlassian Connect descriptor for Forge migration readiness — module mapping, blockers, effort estimate. Connect EOS: 31 Jan 2027. · GitHub.

2

Hi @UmairAhmed, point 2 needs splitting. None of those six has a Forge-native module, so the answerable question is which ones a migrating app can keep carrying as Connect modules. ConnectModulesValidator gates that on SUPPORTED_MODULES. Four of your six items pass, webSections being two keys, one per product:

jira:webItems                success=true    <- control
jira:webSections             success=true
confluence:webSections       success=true
jira:jiraReports             success=true
jira:jiraSearchRequestViews  success=true
confluence:confluenceThemes  success=true
confluence:spaceViews        success=false   invalid value '...' in connectModules
jira:jiraVersionTabPanels    success=false
jira:jiraComponentTabPanels  success=false
jira:jiraProfileTabPanels    success=false
jira:zzzInventedByMe         success=false   <- a name I made up

Your other two items are those four keys, and they get the same error my invented name does.

spaceViews is the row I’d fix first. It isn’t a module, it’s routes.spaceview inside a confluenceThemes entry, the module directly above it passing.

My read is that green column is the trap. It covers the module name, the body still has to match the Connect schema, and the manifest reference says adding Connect modules to a new Forge app isn’t supported. Green means a hybrid keeps working. It doesn’t mean you can build it.

Is this aimed at people carrying a descriptor across, or people scoping a rewrite?

3

You’re right, and I’ve reproduced it — @forge/manifest 13.3.0, same results including webSections resolving to two keys, one per product.

The tool now separates the two questions instead of collapsing them into one. webSections, jiraReports, jiraSearchRequestViews and confluenceThemes report as having no Forge-native module and as carryable in connectModules, with the accepted keys shown. The version, component and profile tab panels get a separate status — they aren’t live Cloud Connect modules, so they fail the validator exactly the way your invented name does.

spaceViews was the worse error, and thanks for catching it. You’re right that it isn’t a module at all — it’s routes.spaceview inside a confluenceThemes entry. I’d taken it from a docs table without checking it against the schema. It now reports as part of confluenceThemes rather than as something you could migrate on its own.

Your point about the green column is the one I’ve tried hardest to reflect. The output now states that the validator checks the module name only, that the body still has to satisfy the Connect schema, and that the route is closed to new Forge apps. I also flagged that jiraProjectTabPanels and jiraProjectAdminTabPanels sit on the allowlist despite being deprecated since October 2017 — accepted by the validator clearly doesn’t mean the surface still renders.

To your question: I built it for scoping a rewrite, which is exactly why point 2 came out wrong. “No Forge equivalent” is true if you’re rewriting and misleading if you’re carrying a descriptor across. It now answers both — but the effort numbers still assume a rewrite, so they overstate the work for anyone doing a hybrid carry. That’s the next thing to fix.

Thanks for running the probe rather than just telling me it was off.

4

This is a very cool idea for a tool and I hope people get some good value out of it.

If you want to make this tool really useful, you could make it work for Forge manifests that still have connect modules in them too.

It seems like it wouldn’t be much more effort to make that work since you’ve pretty much done the majority of the heavy lifting.