How will we move the OOB scoped application from one instance to another
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago
Hi Janak,
Since Quote Management and Source-to-Pay Common Architecture are OOB applications, you do not need to move the entire application. First, ensure that the same applications and compatible versions are installed on the target instance. You only need to migrate your customizations.
For moving the configuration changes, you can use Update Sets. Make sure that you select the correct Application Scope and create a separate update set for each scope.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago
Hi Brandon,
It happens to the best of us! When you make modifications within an OOB scoped application like Quote Management without explicitly setting a current update set, ServiceNow doesn't lose your work. Instead, it automatically logs those configuration changes into that specific application's "Default" update set.
To capture your work retroactively and move it safely:
Navigate to Local Update Sets and open the one named "Default" where the application scope matches the one you were working in.
Scroll down to the Customer Updates related list.
Filter the list by your user ID (sys_created_by) and the dates you worked on the modifications.
Create a new, correctly named Update Set for your project.
From your filtered list in the Default update set, perform a UI action or list edit to change the "Update set" reference field on those specific records, pointing them to your newly created Update Set.
Once everything is moved over, you can complete and export your new update set as usual.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago
Hello Brandon,
When managing enterprise architecture, making structural modifications to OOB applications requires a robust deployment strategy. Relying on manual Update Sets often introduces this exact risk: administrative overhead and human error in tracking changes, which can easily lead to incomplete deployments or technical debt.
While you can manually extract your unassigned changes from the scope's "Default" update set for this immediate release, I highly recommend transitioning your development team to Source Control (Git) for scoped applications. Linking your ServiceNow instances directly to a repository automates the tracking of every configuration change via branches and commits. This completely eliminates the reliance on "making an update set current" and lays the necessary groundwork for a resilient, automated CI/CD pipeline across your environments.
