You're on your way to the next level! Join the Kudos program to earn points and save your progress.
Level 1: Seed
25 / 150 points
1 badge earned
Challenges come and go, but your rewards stay with you. Do more to earn more!
What goes around comes around! Share the love by gifting kudos to your peers.
Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!
Join now to unlock these features and more
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?
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:
project = 10000 //project ID
cf is not EMPTY //custom field ID
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:
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.
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 :-(.