-
Suggestion
-
Resolution: Fixed
-
None
-
6
-
This ticket has been raised to track interest in an automated migration path for Cloud Forge apps.
Problem Definition
A vendor with a server app cannot provide an automated migration path to a Forge app.
Currently only Atlassian Connect apps provide and support an automated migration path.
Suggested Solution
Provide an automated migration path.
Workaround
Today vendors can provide an app data migration path outside of the Cloud Migration Assistants. The Migration Assistants support displaying the vendor documentation using the Marketplace Migration API.
[MIG-771] Provide a migration path to the Cloud Forge counterpart of a Server apps
Hi there!
Forge App Migrations is now available as EAP (Early Access Program) starting from JCMA 1.11.6 (Jira) and CCMA 3.9.17 (Confluence).
We are still preparing the official docs. In the meantime, the Connect x Forge comparison page remains relevant.
Your feedback is invaluable in shaping the GA version. Please fill out this form to get more details and help us make Forge App Migrations the best they can be.
Looking forward to your suggestions!
Andre
Hello,
I'm bringing some updates about Forge App Migrations. We are starting an early access program, and you'll soon be able to express your interest in it.
As a sneak peek, please feel free to take a look at this page.
Stay tuned; more comms and details will come soon.
Have a great day!
Andre
Any update on this? With the end of server support moving closer, we receive a growing number of customer requests for a migration to Cloud. As our Jira Cloud app is built on Forge we need to know whether or not to keep investing in a custom migration path...
Hi,
What is the planned outcome of this ticket? Can you share what is planned?
For now I have written my own python based storage format converter to migrate Server/DC Confluence Page macro storage format to Cloud Forge storage format. I will provide this to my customers as "manual" way to convert each confluence page that contains the macros.
This is very very inconvenient and I hope that the conversion my converter performs will be done by Atlassian automatically, once this ticket is done.
Here is the code:
- https://github.com/codeclou/advanced-codeblocks-cloud-migration-helper
- There are many tests and example files under "lib/"
Please tell me if this is what we can hope for, thanks.
Hi,
I can confirm that within our DC/Server app, we can export the mappings. This should allow us to implement a custom migration solution. It didn't worked at my first try, but it now works. Thanks a lot.
Hello bfb3093d2c47 ,
Thanks for raising this issue. We plan to working on fixing the reported behaviour (to have app installation check work as expected for Forge apps ) soon and will update here once the fix the released.
With regards,
Pooja
Hi,
We have a Forge app and we are trying to provide a data migration for our customers but suggested workaround is not possible. Because migrating to cloud changes all the entity IDs for example issue id, worklog id. We have our own data associated with worklogs and issues through this ID and there is no way to get new IDs for entities. So, suggested workaround, "vendors can provide an app data migration path outside of the Cloud Migration Assistants" is not applicable.
Although Forge apps are not supported, I have updated our server app and implemented automated migration. My idea was, saving the mapping provided to onStartAppMigration method to a JSON file and import this JSON file to our Cloud app manually. But this was also not possible. Migration Assistant insist that our app is not installed to the cloud site, although it is. I think migration assistant needs your app to be a Connect App. Can you remove this check? If you remove this check, we can save mappings to a JSON file and perform a manual upload to our Forge app.
You are pushing all customers to the Cloud, suggesting vendors to use Forge platform and leaving us without any solution to port our customer data.
Facing similar issues here to Fred L, prompted me to write a community post to see how others are leaning into the problem, particularly when those macros are nested - that pattern alone makes discovery and assessment of the size of the migration task, risk assessment for data loss hard: https://community.atlassian.com/t5/Atlassian-Migration-Program/Handling-nested-macro-discovery-at-scale-in-Confluence/qaq-p/2268009 - would really like to see Atlassian lean into this harder, affects DC + Server clients.
Macros migration is a huge problem...
We leveraged "user macros" heavily in our current instance (server, on-prem) and now that we are "pushed" into migrating to Atlassian Cloud we are faced with hundred of pages with macros not being rendered correctly, and it's not just a cosmetic issue: we are talking about potential data loss here.
Trying to use Forge macros doesn't get us very far, given that macros "with body" are not supported yet, and given various other UI toolkit API shortcomings (e.g. Header UI component allowing to generate H1 and H3 but not H2, and such headers not being picked up by the native TOC macro).
And I'm not even sure that deploying a Forge macro created with similar "key" (as our "user macro" previously defined on server product) will be enough to get the migrated pages rendered correctly: so far, all my experiments failed).
This means a huge cost impact for our migration and it's quite hard to justify to key sponsors tbh. It's not encouraging to leverage more of the product in the future (given the extra hassle now for those of us who tried to leverage it in the past), and harder to advocate for it.
Please do something urgently.
Please also be mindful of issues with migrating macros. See https://community.developer.atlassian.com/t/macro-bodies-in-forge/43704/10
The App Migration Platform now supports automated Forge App Migrations: https://developer.atlassian.com/platform/app-migration/changelog/#CHANGE-1946