This is a follow up to the above thread concerning migration of our workspaces in GCP to AWS: https://gooddataconnect.slack.com/archives/C01P3H2HTDL/p1704322657757379. To keep things simple, we started with our newest workspace on GCP, which is pointing to a Snowflake data source (rather than BigQuery) - so we could avoid migrating any column names. To perform the migration, we followed the below steps: 1) Called GET /api/v1/layout/workspaces for our org on GCP 2) Updated the dataSourceId's in the returned JSON to match the dataSourceId's on AWS 3) Called PUT /api/v1/layout/workspaces for the corresponding org on AWS with the updated JSON The process was straightforward. I didn't check everything, but it seems to have populated the entire workspace, including LDM, metrics, attributes, insights, etc with the same ID's as on GCP. However, I'm hitting an issue where insights that render on GCP do not render on AWS. On AWS I receive an error message that the insight cannot be found (but the insight appears in the dropdown list of available insights!). I compared the URL's on GCP and AWS and they have the same path after the hostname. On GCP: https://[hostname]/analyze/#/b922ec833042440287f8e8837607fb6b/d1c4dc49-bcf6-4aab-97ae-54f0e6b2368a/edit On AWS: https://[hostname]/analyze/#/b922ec833042440287f8e8837607fb6b/d1c4dc49-bcf6-4aab-97ae-54f0e6b2368a/edit I verified that both the workspace "b922ec833042440287f8e8837607fb6b" and insight "d1c4dc49-bcf6-4aab-97ae-54f0e6b2368a" exist on AWS (calling the /api/v1/entities/workspaces/{workspaceId}/visualizationObjects endpoint for visualization objects, the insight appears in the returned objects with the same ID). So it seems that some required element is not being migrated. One clue shows up in the UI requests: On AWS, there is a failed request to POST /api/v1/actions/workspaces/{workspaceId}/execution/collectLabelElements, which suggests there's some issue collecting labels to render the insight. The same request succeeds on GCP. Is there some step we might be missing? Or is there some wrong assumption we're making about the migration? What are the "labelElements" and how would we transfer these elements to AWS as they exist in GCP (if this is in fact the root cause)? Thanks for any ideas.

Did you really start with calling GET /api/v1/layout/workspaces? If so, it migrates only workspaces, but not data sources. We suggested to use organization-level API instead, which migrates workspaces, data sources, users, permissions, etc., basically everything.

Hi Jan, yes, we started with GET /api/v1/layout/workspaces. We do not want to migrate data sources or users, which is why we did not choose the organization-level API. Would label elements be migrated with the organization but not with the workspaces? Is there a way we could migrate just the missing label elements?

I see. Label elements are calculated similarly to how reports are calculated. The same metadata (labels in LDM) are used. I need more info about failed executions. Please, open the web developer console and find details about the error.

Here is the HAR file from the network tab in Chrome. I did not see any errors in the server logs. Let me know if you need additional info. Also attaching a screen shot of the network tab from the devtools console:

I opened the HAR file and found the error:

Thank you, Jan. Will investigate.

Eh, we have always been afraid of something like that will happen. Between v2.5 and v3.1 we deprecated and then removed the PDM. We moved all physical properties into LDM. When you export organization from v2.5, PDM is there. When you try to import it to v3.1, PDM no longer can be imported and the LDM from v2.5 does not contain required PDM properties. There are two solution options: • Write a script transferring PDM properties from v2.5 PDM to v3.1 LDM • Upgrade GCP from v2.5 to v3.1 and then do the migration without any obstacles Which solution would you prefer?

@Jan Soubusta I'm afraid we'll have to go with the first approach, since we're not able to upgrade our production deployments so quickly on GCP, but we need some data migrated to AWS now for our tests on the new platform.

Let me discuss it internally. Will get back to you ASAP

thank you @Jan Soubusta

We are going to recommend you an official procedure how to handle this situation. I involved our support and an engineer who was responsible for the implementation. They are going to contact you ASAP.

@Pete Lorenz Hello, here is the procedure to add PDM information into LDM in all workspaces of one organization. One of the requirements is license key for all-in-one docker image. @Jan Kos will help you with that. Please note, that the procedure was updated for your scenario in a timely manner. If you hit any issue let us know.

Hi Pete for the guide ^ you’ll need GD.CN container edition (AIO - all in one image). Different license key is required to run AIO. I’ve reached out to our colleague to generate the license key for you (however it is possible that he is off for today). I’ll let you know once I know more.

ok, thank you @Jan Kos

It is publicly available on docker hub. The procedure contains command to spin it up in

Setup environment

step. This part:

docker run -i -t -p 3000:3000 -p 5432:5432 -e GDCN_LICENSE_KEY="$GDCN_LICENSE_KEY" \
-v gd-volume:/data gooddata/gooddata-cn-ce:3.0

ah, ok, perfect

AIO is abbreviation for gooddata all-in-one docker image

I see, thank you

Hi Pete, I’m sorry, I’m still discussing it with my colleague and your account owner, I’ll let you know.

Ok, thanks Jan, this is blocking our migration to AWS, so if there's any way we can expedite things, we'd most appreciate it 🙏

hi @Pete Lorenz I have sent to Rohit Mathur a contract with the terms and condition of the GD.CN Container edition, once reviewed and signed we'll share with your team a new licence key. Regards

Thanks @Pablo Castro!

@Pete Lorenz I shared with you the license Key via email. Let us know if all is Ok 🙂

Thank you @Pablo Castro. I just received it, we truly appreciate your support on this! 😀