Agile Board and Update Set Integration During Production → Development Environment Clone

kuuum_aaaya
Tera Contributor
Hello ServiceNow Community,
I'm seeking advice from anyone who has experience with maintaining the relationship between Agile Boards and Update Sets during production to development environment cloning.
Background:
 
Update Set related tables (sys_update_set, etc.) will be excluded during cloning
 
Development environment has custom integration between Agile Board stories and Update Sets via related lists
 
The clone process may break the relationship between stories and Update Sets
 
Production environment has Agile Board plugin installed but is not actively used
Potential Approaches:
 
Pre-export + Post-recovery (XML extraction → re-import after clone)
 
Re-establish relationships using production data
 
Discontinue the integration
Questions:
 
Which of the above approaches would be most effective?
 
If pursuing approach #1, what are the key considerations and potential pitfalls during recovery?
 
(Optional) Is it possible to exclude/preserve Agile-related tables during cloning even if they're not actively used in production? Target tables include: rm_story, rm_epic, rm_sprint, rm_release, rm_task, rm_scrum_task, sys_journal_field, backlog_definition
Any insights, experiences, or best practices would be greatly appreciated!
Thanks in advance for your help.
1 ACCEPTED SOLUTION

M Iftikhar
Tera Sage

Hi @kuuum_aaaya ,

The relationship between Agile stories and Update Sets will break during a clone because sys_update_set and related tables are always excluded.

The most reliable approach is Option #1 (Pre-export + Post-recovery):

  1. Before Clone

    • Export your in-progress or critical Update Sets to XML.

    • This captures the metadata and relationships you need.

  2. After Clone

    • Import the Update Sets back into Dev from XML.

    • Commit them so the changes are available.

    • If you still want them “in-progress,” you can change the state back or merge them into a fresh Update Set.

I found some references from community which can help u:

Preserve Update Sets when Cloning a Community thread where pre-export → XML / import after clone is discussed.
https://www.servicenow.com/community/itsm-forum/preserve-update-sets-when-cloning/td-p/810249


Update sets show committed after cloning dev  here someone did exactly what we are talking about
https://www.servicenow.com/community/developer-forum/update-sets-show-committed-after-cloning-dev/m-...

This explains the “Preserve In Progress Update Sets” option added in Orlando release, which helps reduce manual export/import. 
https://www.servicenow.com/community/developer-articles/system-clone-preserve-update-sets-orlando/ta...

This is from forum, about how to preserve update sets of latest 90 days during cloning.
https://www.servicenow.com/community/servicenow-ai-platform-forum/preserve-in-progress-update-sets/m...


Exclude a Table from Cloning  Doc about excluding tables like sys_update_set via clone settings. Useful to understand what cannot travel via clone.
https://www.servicenow.com/docs/bundle/zurich-platform-administration/page/administer/managing-data/...



Thanks & Regards,
Muhammad Iftikhar

If my response helped, please mark it as the accepted solution so others can benefit as well.




Thanks & Regards,
Muhammad Iftikhar

If my response helped, please mark it as the accepted solution so others can benefit as well.

View solution in original post

2 REPLIES 2

M Iftikhar
Tera Sage

Hi @kuuum_aaaya ,

The relationship between Agile stories and Update Sets will break during a clone because sys_update_set and related tables are always excluded.

The most reliable approach is Option #1 (Pre-export + Post-recovery):

  1. Before Clone

    • Export your in-progress or critical Update Sets to XML.

    • This captures the metadata and relationships you need.

  2. After Clone

    • Import the Update Sets back into Dev from XML.

    • Commit them so the changes are available.

    • If you still want them “in-progress,” you can change the state back or merge them into a fresh Update Set.

I found some references from community which can help u:

Preserve Update Sets when Cloning a Community thread where pre-export → XML / import after clone is discussed.
https://www.servicenow.com/community/itsm-forum/preserve-update-sets-when-cloning/td-p/810249


Update sets show committed after cloning dev  here someone did exactly what we are talking about
https://www.servicenow.com/community/developer-forum/update-sets-show-committed-after-cloning-dev/m-...

This explains the “Preserve In Progress Update Sets” option added in Orlando release, which helps reduce manual export/import. 
https://www.servicenow.com/community/developer-articles/system-clone-preserve-update-sets-orlando/ta...

This is from forum, about how to preserve update sets of latest 90 days during cloning.
https://www.servicenow.com/community/servicenow-ai-platform-forum/preserve-in-progress-update-sets/m...


Exclude a Table from Cloning  Doc about excluding tables like sys_update_set via clone settings. Useful to understand what cannot travel via clone.
https://www.servicenow.com/docs/bundle/zurich-platform-administration/page/administer/managing-data/...



Thanks & Regards,
Muhammad Iftikhar

If my response helped, please mark it as the accepted solution so others can benefit as well.




Thanks & Regards,
Muhammad Iftikhar

If my response helped, please mark it as the accepted solution so others can benefit as well.

jamesdhackg
Mega Contributor

I lost $55,000 worth of founds  to a fake liquidity mining platform and thought it was gone for good. Thankfully, the ETHICSPY team helped me recover everything. They are legitimate experts in  asset recovery not like the many
sc-m sites out there. Recovering lost founds  requires rare technical expertise skills only a legitimate team like ETHICSPY possesses. With many fake recovery sites online, it's crucial
to work with trusted professionals.
You can reach them on
Gmail  @ ETHICSPY