nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Preserve Custom fields IDs when migrating to Cloud?

Lise Wåsjø

When migrating custom fields to Cloud with Atlassians Confluence Cloud Migration Assistant, the custom Field IDs are changed.

We have queries where the Custom field ID has been referenced and not the custom field name, so after migrating those queries no loger reference the correct custom field. Is there any work around for this issue?

Comments

Hana Kučerová

Hi @Lise Wåsjø ,

I don’t think there’s any workaround. When the cloud site is created, there are already some custom fields created and these (their IDs) can be in conflict with your server instance. I believe this is the reason custom fields always get the new IDs.

You will probably have to map these queries and change them after the migration :-(.

Dawid Joshua _TechTime_

Hi @Lise Wåsjø

Certified Cloud Migration specialist here. I hope I don't blow it up too much but I think you and the Atlassian Community have the right to know that migrations are still painful. You have encountered just the tip of the iceberg. Let's stick to filters: there are a few more issues. Two of the most common issues from my perspective:

ID references in JQL will either break or filter for wrong results. Example JQL:

project = 10000 //project ID

cf[10112] is not EMPTY //custom field ID

Name references of fields that were duplicated. Example JQL:

custom_field_name is not EMPTY // where custom_field_name was migrated previously to Cloud

The list is much longer, and if you're planning to perform a migration, you should be aware of it. You can find the list here.

Now to a solution to your problem:

As @Hana Kučerová mentioned, there is no easy solution.

If you're in a pre-Prod migration step: depending on the size of your server instance, you might be able to go through all the filters shared with you in the front end and change the custom field ID reference to an actual custom field name.

But for bigger instances, I suggest a SQL solution:

SELECT id, filtername, authorname, reqcontent, fav_count FROM searchrequest WHERE LOWER(reqcontent) ~ 'cf\[\d.+?]';

This will only show you the filters which will break on Cloud. You can update them in the DB directly (please only if you know what you're doing and in the best case, you have a migration staging environment), or use this shortcut:

Use the ID column of the SQL result and insert it at the end of the URL in your browser:

http://<JIRA_server_instance>/secure/admin/EditCustomField!default.jspa?id=<ID&gt;

However, if you're already on Cloud:

For small instances, checking all filters manually might be fine. For larger instances, try this REST API. It might be worth creating a small Python script for it.

I'm fearing I'm getting too technical so I'll stop here, but should you (or anyone else reading this) wish for more details, hit me up.

Cheers,
Dawid

Hubert Kut

Hi @Lise Wåsjø

It is common problem for people migrating from datacenter / server to cloud. We usually do a mapping of objects from datacenter to objects in cloud after migration. You can just use doctor for jira to download all customfields and filter on datacenter AND cloud. Then compare side by side and fix it after migration either manually or by writing script i.e. in python to fix it.

Cheers
Hubert

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

custom-field

cloud