feature flags migration-assistant.app-migration.feature is enabled in Confluence.
Confluence server v7.10.2
We have the migration path already available online but when I create a new migration plan through the assistant UI, the migration cannot start due to missing automated pathway. Since we are still in the implementation phase, is there any way to test the migration platform without enabling the automated pathway or am I missing something here?
As long as you have the followings in place, app migration platform lets you migrate apps.
Have a listener implemented
In AppAssessment flow, select ‘NeededInCloud’ - despite you have a path or not. And complete the flow once. This flow is not meant to be blocking at present, so you should be able to complete this.
Make sure that App is installed on the cloudsite you would like to migrate too.
Also note that at present only those apps that have the same key on server and cloud can be migrate, so if serverAppKey and cloudAppKey are different then you can’t migrate.
I also implemented both listeners interfaces available in migration OSGi and none of them worked. (AppCloudMigrationListenerV1, AppCloudMigrationListener)
I attach a video showing the steps I followed to create a migration plan here:
Hi @anon65479381 and @thomasr, from EAP, the completion of App Assessment is necessary for those migrations that have Apps involved.
Therefore, you need to make sure that every installed App should have a deterministic state either - ‘Needed in cloud’ or ‘Not needed in Cloud’ or ‘Use Alternative’. In App Assessment, please make sure that it is true for every app and then go through the flow.
The workaround you provided was working fine but after updating CCMA to v3.1.8, and the wanted apps for migration are not listed in the migration plan and the app migration listener not being called anymore.
Please let me jump in here for my colleague. Generally we find that sometimes on the upgrade depending on how you’ve implemented the listener that a complete restart of Confluence Server will help to reset the apps. Or at least at a minimum restart your app after making sure CCMA is enabled.
Exactly which page are you referring to when you say
the wanted apps for migration are not listed in the migration plan
I also restarted the Confluence Server but it didn’t help.
The page Choose what to migrate in the previous version was showing the apps being migrated.
It looks like you need to reset the dark feature flag to turn App Migration on. There should be a large orange banner at the top to let you know you’re running the EAP code.
Please follow the instruction in this step in the Getting Started Guide
Scroll down and enter migration-assistant.app-migration.feature
Click Save
This should activate the EAP App Migration features. You do not need to restart. (A restart will clear out the dark feature.) I also recommend reviewing the Getting Started page again because there might have been some changes since the last time you viewed it.
After restarting the Confluence instance, the app listener was called.
There is still one issue with the mapping API which I have not been able to figure out yet.
The API doesn’t return the user mappings on either Cloud or Server.
GET request to this URL: https://my-site.atlassian.net/rest/atlassian-connect/1/migration/mapping/26925583-10bd-49fb-b67c-15fc2447a97b/page?namespace=identity:user
I tried with other namespaces like confluence:space and confluence:page and the API returned a map.
I can see that a new user gets added on the Cloud site after migration but it’s not available in the mapping API result.
In spite of a new user in the migration plan, the AppCloudMigrationGateway always returns an empty map for identity:user .
All users are not migrated every time, only the changes from the last migration. I’ll have to confirm this with a test, but if you migrate twice to the same cloud site, then the same users are not sent on the 2nd migration as they have already been uploaded.
Actually, I was aware of that.
I don’t get the user identity mapping from the API in the listener when a user is being uploaded to the Cloud for the first time.
if I understood this correctly it essentially makes the user mappings pointless for a lot of migrations:
I guess a lot of customers will migrate individual spaces. So I assume the first migrated space will also trigger a migration of the users. If an app’s feature is only used in another space that is migrated later on, doesn’t that mean that app’s migration code will never see the users at the time it has something to migrate?
To clarify this: Our app stores some data with user references in a space. If the migration code is invoked for another space not having such data, our migration code currently doesn’t do anything (because there’s nothing to migrate).
So we (and every other vendor with a similar use case) would need to add code to our app that stores the user mappings in a separate location just in case it might be required later on. This is not really ideal.
Can the migration platform be changed to provide such ‘global’ mappings in each partial migration?
I’ve checked with the team and I misunderstood what was happening. Each link between server and cloud is given a unique id (we call it a migrationScopeId) and this ties the mappings between server and cloud. So, when we get the transferId we look up the migrationScopeId and then request the mappings.
Can I ask you try again with a fresh new cloud instance? If it still fails, post the migrationId and I can check.
We’d like to confirm that you’re selecting the user and groups option, and not just selecting users for selected spaces. identity:user mappings are only created if you specifically specify the users and groups option. We’re asking because we can’t see any user mappings being created in our logs for your migrationId.
The mappings are cumulative for each migration, so long as they haven’t been removed based on the time limits (e.g. user mappings are kept for 5 days) but you need to specifically send the users and groups, not just the spaces with associated users.
Great to hear that you’ve got the mappings you were looking for. I want to confirm this question I asked because it means I might need to update to the documentation.