Will Jira Cloud-to-Cloud Migration Be Blocked if a Source Marketplace App Is Not Installed inTarget?

Question

Hai ,

We are planning a Jira and Confluence Cloud-to-Cloud migration between two different Atlassian organizations.

We have a scenario where a third-party Marketplace app is installed in the source environment, but the same app is intentionally not installed or licensed in the target environment, as we do not plan to use it after migration.

We would like to understand the migration behavior in this scenario:

* Will the migration be blocked because the Marketplace app present in the source is not installed in the target?

Will Atlassian require us to install the same app in the target before allowing the migration to proceed?

Or will the migration be allowed to continue with a warning that the source app is unavailable in the target?

If the migration can proceed, will only the app-specific data/configuration be excluded or impacted while the rest of the Jira/Confluence data migrates normally?

We are not looking to migrate or retain the functionality of this third-party app in the target. Our primary concern is whether its absence in the target can block the overall Jira/Confluence migration.

Could you please confirm the expected behavior and share any relevant official Atlassian documentation?

Do we have to procure/install the app in the target just to perform the migration, even when we don't intend to use or migrate that app?

Thanks in advance.

Sarah Marenchino | Devoteam · Accepted Answer

Hi,

Atlassian recommends having the same Marketplace apps installed in both the source and destination environments when performing a Cloud-to-Cloud migration, to avoid potential data loss or issues with data relationships.

However, the official documentation does not explicitly state that a missing Marketplace app in the destination will systematically block the migration.

It's also worth keeping in mind that Atlassian's native Cloud-to-Cloud data transfer tool does not migrate Marketplace app-specific data.

If your goal is simply to complete the migration without retaining the app afterwards, why not consider temporarily installing it using a free trial, if one is available?

This would allow you to follow Atlassian's recommendations during the migration and then uninstall the app once all necessary checks have been completed.

I would still recommend performing a test migration and checking for any dependencies, particularly Jira custom fields and workflows or Confluence macros, before uninstalling the app.

Official Atlassian documentation:

https://support.atlassian.com/organization-administration/docs/before-you-start-copying-product-data/

Could you also clarify which Marketplace app you're referring to? This would help determine whether it has any specific dependencies that could affect the migration or the data after the app is uninstalled.

Best regards,

Sarah

Gabriela - LeanZero · Accepted Answer

Hey Likhita, I went looking for official wording behind what Sarah said, and I found two Atlassian tickets that I think are useful to have in your migration notes.

CLOUD-11907 lists exactly her approach as Atlassian's own workaround: "Install the apps on the destination instance, run the copy product data and then uninstall the apps you no longer need." https://jira.atlassian.com/browse/CLOUD-11907 The ticket itself asks to let the copy run without matching apps, and the Confluence copy page goes further than the Jira one, saying "you must have the same apps on your source and destination." https://support.atlassian.com/organization-administration/docs/copy-confluence-data/

On the Jira side I wouldn't skip it either. In the open bug CLOUD-12051, a project's copy fails when its setup references something the missing app defines, like an app permission in your permission scheme, and that error "caused 108264 other items to fail". So I'd expect you to lose the whole project's copy in that case, not only the app's own data. https://jira.atlassian.com/browse/CLOUD-12051

Once you know which app it is, its own docs may say whether its fields or workflow parts would sit in your projects' setup like that.