How will we move the OOB scoped application from one instance to another

[brandonlab2]

Hi , I have been working on a project; as per the requirement I am using the OOB applications Quote management model and Source to pay Common Architecture. I need to make some modification on the tables using which will come under these OOB application. So my question is when the work is complete, how will I move these project from one to other. I usually worked as a support team and used scoped application. In the case of update sets, if i forget to keep track to make it as current , how will I move my work as a whole?

[Dr Atul G- LNG]

Hi @brandonlab2 

So, you are only making changes to tables and business logic. In that case, using an Update Set is the right approach to move those changes from one instance to another.

There is nothing unusual here. Just make sure that:

• The correct Update Set is selected while making the changes.
• The required plugins are installed and active in the target (upper) instance as well.

If both of these are in place, the Update Set should migrate the changes successfully.

[Ankur Bawiskar]

@brandonlab2 

my thoughts

-> any changes outside your scoped app you can capture in update set of that scope and move that update set

-> any changes within your scoped app there are few ways to migrate, everthing is listed here

a) app repository

b) update set

c) source control

💡 If my response helped, please mark it as correct ✅ and close the thread 🔒— this helps future readers find the solution faster! 🙏

[Tanushree Maiti]

Hi @brandonlab2 

When you make out-of-the-box (OOB) application customizations, the recommended way to move those changes between instances is by using Update Sets.

If you accidentally leave the Default update set as the current update set while making changes:

1. Open the Default update set.
2. Review the captured Customer Updates.
3. If the update set has not been committed to another instance, you can manually move the records by:
   • Navigating to the sys_update_xml table (or the Customer Updates related list).
   • Changing the Update Set reference on the relevant sys_update_xml records from Default to your intended custom update set.
4. Preview and commit the target update set on the destination instance as usual.

Important considerations

• Only reassign updates before exporting or committing the update set.
• Be careful not to split related changes across multiple update sets, as this can lead to dependency issues.
• Always review the update set contents after reassignment to ensure all required records are included.
• Some changes (such as data records or certain system configurations) are not captured by update sets and require other migration methods.