Moving servicenow application from one instance to another different instance

[sharmaprash]

How to move an application from one instance to another.

I got to know that an application can be moved through publishing to application repository but that was for dev instance to another. 

This is from one instance A to another B.

is there any sort or integration or something else let me know if there is any answers.

[Community Alums]

Hi @sharmaprash, 

You can use update set (it is one of the simple ways of moving app from one instance to another). Here're the steps:

• In Instance A, create or ensure your application changes are captured in a specific update set.

• Mark the update set as "Complete".

1. Export the completed update set as an XML file.

• In Instance B, navigate to "Retrieved Update Sets" and import the XML file.

• Choose .xml file you recently downloaded from Instance A and click upload

• When you successfully import the update set in instance B, open the record.

• Preview, resolve conflicts if any, and then commit the update set.

Hope this helps!

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

[dgarad]

Hi @sharmaprash 

1. If you are using AES and already have the CICD piplelines setup, then you should be able to submit your app and it would be installed in the QA instance.

2. Another way can be to publish your custom application in the app repo and pull the application in other instance.

3. Conventional way is to publish your application as a update set and retrieve in another instance, if other two options doesn't work for you.

More details can be odund here in SN support aprticle:

https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB0961293

[aruncr0122]

Hi @sharmaprash ,

You can also user Update source to move changes from one instance to another.

An Update Source is a configuration that allows one instance (Instance B) to pull updates (like application files, scripts, configurations) from another instance (Instance A).
It’s often used when:

You can’t use the Application Repository, or

You want to synchronize apps directly between linked environments (e.g., Dev → Test).

⚙️How It Works (Conceptually)

Think of it like this:

Instance A (source) → shares changes →
Instance B (target) → connects as a remote update source → pulls those updates.

ServiceNow tracks changes in update sets and Instance B retrieves them from A.

🪜 Steps to Move an Application via Remote Update Source
On Instance A (Source Instance)

Navigate to System Update Sets → Update Sources.

Ensure that SOAP Web Services are accessible (Instance B must be able to reach A).

Note the URL, username, and password (usually a dedicated integration user).

On Instance B (Target Instance)

Go to System Update Sets → Update Sources.

Click New → choose type Remote Instance.

Fill in details:

Name: any identifier (e.g., “Instance A Source”)

Source URL: e.g., https://instanceA.service-now.com

Username / Password: integration account credentials from Instance A.

Save the record.

Click Retrieve Updates to fetch available update sets from Instance A.

Once retrieved, preview and commit the update sets you want.

💡When to Use a Remote Update Source

✅Ideal for environments not linked via App Repository
✅Useful when you need to pull changes automatically (instead of XML exports)
✅Works well for update set–based deployments

⚠️Important Notes

Both instances must be able to communicate over HTTPS.

Works best for global or update set–based applications, not scoped apps.

Scoped applications are better moved using App Repository or XML export/import.

In short:

A remote update source is like setting up a “live bridge” between two instances so you can pull update sets (application changes) directly — no manual XML export needed.

Thanks

[Vishal36]

Hi @sharmaprash, 

The Application Repository works well between dev and test environments, but there are a few things to double-check when moving from one instance (A) to another (B):

• Access & permissions: Make sure both instances are linked to the same ServiceNow account and that you have the right roles (typically admin or app publisher).
• Version control: If the app uses source control (like Git), you can pull from one instance and push to another.
• Dependencies: Confirm that all referenced tables, scripts, and update sets exist in the target instance-missing dependencies can cause breakage.
• Testing: Always validate in a sub-prod or clone before pushing to production to avoid overwriting configs.

In your case, you may want to explore OpsHub Migration Manager (OMM), a ServiceNow Partner. It supports phased or full migrations with no downtime, no disruption, and no data loss, and it preserves historical fidelity - including relationships, attachments, and field mappings. As a result, you can move apps and configurations safely between instances without manual exports or dependency issues.

Hope it helps! 🙂