we have an existing Connect app that we would like to replace with a Forge version (a complete re-write). Our situation is similar to this topic: Moving an app from Connect to Forge completely.
From my understanding, we need to set the right app.connect.key in the manifest file to maintain the previous listing with all the ratings and installations. By publishing this new app version to the Marketplace and selecting the Forge app, our customers should be notified of the new version and invited to upgrade via UPM once the Forge version’s Marketplace listing is approved.
Is this considered as the “classic” Forge app or the “hybrid” Connect-on-Forge app? The incompatibility section mentions that “Connect-on-Forge apps are currently unable to offer data residency realm pinning or migrations,” which could be problematic for us. Would our app be considered Connect-on-Forge if it does not use any Connect modules (any remotes) and just retains the app.connect.key to preserve the Marketplace listing? Thus it would act as the classic Forge app?
This is correct - the app.connect.key will map the new Forge version back to the existing Connect marketplace listing, allowing you to replace it in place with a new Forge version.
We’re also happy to support the staging of this transition to facilitate targeting of your own testing sites first, enabling you to ensure things update smoothly prior to customers seeing the option.
Forge does not currently support the ability to declare multiple regions for remotes, meaning that Connect apps which declare multiple regionBaseUrls would not be able to persist these multiple mappings at the moment.
With that said, an app which moves from Connect to Forge can still adopt Forge Data Residency if it meets the eligibility criteria.
That would make the app a Forge app which has transitioned from Connect. The utilisation of the app.connect.key would be utilised for marketplace mapping purposes.
