Missing Custom Fields After Server → Data Center Migration (Plugin Dependencies)

[Digambar Prakash Dhanagar]

Hello Team,

We are currently working on a Jira Server → Data Center migration and have encountered issues with missing custom fields post-migration.

---

Environment Details

• Source Instance: Jira Server 8.13.11

• Target Instance: Jira Data Center 10.3.12

• Migration Type: XML Backup Restore

• Database: PostgreSQL

• Deployment: 2-node active-active cluster

• Shared Home: NFS mounted and accessible

---

Issue Description

After completing the XML backup restore, we noticed several custom fields are missing in the Data Center instance.

Upon investigation:

• Some fields were linked to plugins that are already installed and revalidated successfully.

• However, a few fields depend on plugins that are not available or not supported in the Data Center version — specifically:

  • Easy Links for Jira

  • Color Custom Fields for Jira

These field types are no longer available, so their associated field definitions and data did not migrate.

---

Request for Guidance

Could you please help us with the following:

1. Confirm whether XML restore supports custom fields from unsupported or deprecated plugins.

2. Suggest the best way to handle plugin-dependent fields when migrating to Data Center (e.g., convert them to standard field types or export their data manually).

3. Any recommended workaround or marketplace alternative for Easy Links for Jira and Color Custom Fields that is Data Center-compatible.

---

Thanks & Regards,
Digambar Dhanagar

[Christos Markoulatos]

Hi @Digambar Prakash Dhanagar 

App custom fields are created by the apps. If the app is not present during the migration meaning u have to install them in the new instance before migrating, App specific fields will not be migrated. In your case that the apps do not exist in DC and since u are migrating from server to DC u can create in DC the custom fields and copy the values from one DB to another but the field types have to be compatible. 

[Diana_Architect_ZigiWave]

@Digambar Prakash Dhanagar hi. +1 for the @Christos Markoulatos ' answer. Just to add another alternative solution, in case you want to try another approach - check ZigiOps. Apart form integrations, it can be used for migrations also - batch migrations, to be precise. No limits to the data that needs to be transferred, does not save any of your data + you can pick what data to be migrated. Feel free to look at it and reach out to us, if you're interested. 

[Dr_ Ankita Mehta-OpsHub_ Inc]

Hi @Digambar Prakash Dhanagar

 As rightly mentioned in the above answer. the app-based custom fields only come across if the same plugin exists on the target, and Jira will drop those fields completely during an XML restore if the app isn’t available.

A few things to consider as you work through this:

• XML restore requires full downtime, so unsupported field types need to be handled before the import or you'll end up redoing the restore.
• Re-creating compatible fields in DC can work, but Jira stores custom field values across multiple tables, so copying data at the DB layer needs extra care and a full reindex.
• For unsupported apps like Easy Links or Color Custom Fields, exporting values via CSV/SQL before the restore is the safest way to retain the data.
• Jira has no fallback for deprecated field types, so anything plugin-based must be remapped or converted ahead of time.

In your case, you may want to explore working with an Atlassian Solutions Partner, OpsHub Migration Manager (OMM). It supports phased or full migration with no downtime or disruption, and it carries over field mappings, history, attachments, and relationships end-to-end. It also handles on-the-fly transformations-all without needing to write any code.

You may also refer to this Atlassian marketplace listing (with video) on Jira Server or Jira DC to Cloud migration for more info.

Hope it helps!