🚀 Early Access Program: Assets Cloud to Cloud Migration

[#1]

📣 Update:

Thanks for everyone that expressed interest in this program, we are no longer accepting signups, we will contact the sites that have signed up through the tickets, expect this to take a little bit longer than usual features as there is a lot of prep work that needs to happen to enable this feature.

Also if you haven't provided a source and destination site please do as soon as possible so we can start the prep work.

Thanks,

Mohamed

=================================================================


Hey Team 👋

We’re excited to open up our Early Access Program (EAP) for Assets Cloud to Cloud Migration in Jira Service Management!

This feature allows you to seamlessly migrate Assets data between JSM Cloud sites, making site consolidations and restructures smoother and more efficient.

What you should expect in the EAP:

• Access to a tool to migrate the following entities along with JSM projects:
  • Object schemas
  • Object types
  • Objects
  • References/Statuses
  • Attachments
  • Object work item (ticket) connections

• Share feedback directly with our team to help shape the experience

⚠️ Please note: At this stage, the migration tool does not support the following:

• Migrating the Services schema or the Service Registry. We’re focusing on the core object schema and data first, with more to come in future updates.

• Migrating Data Manager. Support for Data Manager migrations will be added in a future iteration after Data Manager becomes generally available (GA)

If you're planning a Cloud-to-Cloud migration or want to explore what’s coming next for Assets, we’d love to have you participate.

👉 Sign up for the EAP here

We'll enable the feature gradually and notify you once it's available on your site.

Feel free to drop any questions or thoughts below — we're here and listening!

Thanks,
JSM Data Portability Team

[Raúl Carrera López]

Will this functionality be available to migrate from production to sandbox?

[Tomislav Tobijas]

Hey @Mohamed Hassan ,

Cool news. Will this support moving Assets between the prod and sandbox environment as well, or is it recommended to move (during EAP) Assets only between two different prod sites?

[Josh]

I'm with @Raúl Carrera López and @Tomislav Tobijas here. This functionality would be incredibly helpful in moving to and from production and non-production (sandbox) instances.

[Bill Goetz]

Would also like to be able to use the between production and sandbox instances.

[Mohamed Hassan]

Hey Team - thanks all for your comments. This is mainly for site to site copy, we will start working on native sandbox copy soon, however you can still use it in case your doing your sandbox manually to another non-production site.

Thanks,

Mohamed Hassan

[Mohamed Hassan]

📣 Update:

Thanks for everyone that expressed interest in this program, we are no longer accepting signups, we will contact the sites that have signed up through the tickets, expect this to take a little bit longer than usual features as there is a lot of prep work that needs to happen to enable this feature.

Also if you haven't provided a source and destination site please do as soon as possible so we can start the prep work.

Thanks,

Mohamed

[Michal Štoppl]

Hello @Mohamed Hassan ,

I am part of this EAP and I would like to share a feedback:

Here are the points we found today during out "Copy app data" tests:

- If you go back from the "Validate data" step back to the "Select data" step in "Copy app data" wizard, (e.g., to change the Asset import option from "no objects" to "all"), changed configuration is not preserved and on "Review selections" you see originally selected configuration. To fix this it is necessary to create a new job.

- It is not possible to migrate assets data only (without project migration)

- It is not possible to remove existing migration jobs (it is necessary to wait until they expire)

- If the object schema exists in the destination object schema name and key, it is reported as two issues (object schema key and name) and we decide to ignore these schemas, we have to do that twice - if we exclude schemas with conflicting name, they will be still reported in validation step because of conflicting schema key - even if they were already excluded.

- During migration, duplicate custom fields are created with a "(migrated)" suffix, such as "Product Domain (migrated), even if custom field without the suffix has the same custom field configuration.

- If object attributes in existing objects within a scheme refer to another object in the same scheme, the field is empty (the attribute value isn't transferred).

If you want to meet to discuss any of these points, please let me know

Thanks

Michal

[Michal Štoppl]

Hello @Mohamed Hassan 

I am also slightly disappointed that object IDs are different.

If I understand correctly, every Assets instance has its own workspace ID, therefore, I hoped that:

- object IDs and object keys will stay the same

- References to objects (across objects or from assets custom fields) could work, since the only difference would be the workspace ID.

Michal

[Mohamed Hassan]

Hi @Michal Štoppl - Thanks for taking the time to write down your experience with the feature, I will reach out to set up a call and go through your feedback if that's okay.

Thanks,

Mohamed