Migration of data from one ServiceNow instance to another service now instance

[snehapatel]

Hi,

There is a single ServiceNow instance "A" which is used by 2 companies ( X & Y) who are partners. Now the requirement is to create a new ServiceNow instance "B" such that instance A is being used by company X and instance B is being used by company Y.

To enable this we would need to move/migrate the workflows, business rules, incidents, cases, problems, service requests, scripts, UI actions, policies, Service Catalog etc specific to company B to new instance i.e. B. What is the best way to achieve this.

How do we handle open records ? Example moving open incidents such that SLAs, workflows are continued. Need to make sure that contextual workflows is carried forward.

We are not looking for the tools like Precision Bridge because of the cost implications.

Thanks,

Sneha

[Chaitanya ILCR]

Hi @snehapatel ,

How about cloning? you can clone instance A into B

Please mark my answer as helpful/correct if it resolves your query.

Regards,
Chaitanya

[Dr Atul G- LNG]

Hi @snehapatel 

There is a single ServiceNow instance "A" which is used by 2 companies ( X & Y) who are partners. Now the requirement is to create a new ServiceNow instance "B" such that instance A is being used by company X and instance B is being used by company Y.

Atul: Is Instance A is domain separated? 

To enable this we would need to move/migrate the workflows, business rules, incidents, cases, problems, service requests, scripts, UI actions, policies, Service Catalog etc specific to company B to new instance i.e. B. What is the best way to achieve this.

Atul: If you want an exact replica of environment A in environment B, cloning is the best option. Otherwise, you'll need to create a new update set and segregate the changes related to Y, ensuring they are included in the update set.

How do we handle open records ? Example moving open incidents such that SLAs, workflows are continued. Need to make sure that contextual workflows is carried forward.

Atul: 

If you intend to move data, you'll need an identifier on instance A that is specific to Y. Using this identifier, you can transfer the data via XML. However, the history will not carry over, and the data will be treated as new on the target instance.

Practically, this approach poses significant challenges, and ServiceNow generally does not recommend moving data in this manner, as it is complex and not straightforward.

We are not looking for the tools like Precision Bridge because of the cost implications.

[snehapatel]

Thanks @Dr Atul G- LNG for your response.

Atul: Is Instance A is domain separated? 

Instance A is not domain separated.

I also wanted to understand what are the challenges involved in cloning the instance. Would there by any challenges in cleaning up the data? Is there are any best practices that should be considered for cloning approach? What are the best practices to be followed for cleaning up the data.

Thanks,

Sneha

[Dr Atul G- LNG]

Hi @snehapatel 

Greetings!!

Thank you for sharing the updates.

If Instance A is not domain-separated, I would like to understand:

• Do you have any unique identifier to differentiate changes, code, and data for X and Y?
• This differentiation will be critical for ensuring clarity and seamless operations.

---

Cloning:

I would also like to discuss the challenges involved in cloning the instance.

• Cloning Overview:
  Cloning essentially works like a complete copy-paste operation. The data, code, and configurations in Instance A will be fully replicated in Instance B.

• Challenges in Cleaning Up Data:

  • Cleaning up requires a clear identifier to distinguish data belonging to X versus Y.
  • Without proper identifiers, separating and managing the data post-cloning may become cumbersome.

• Best Practices for Cloning:

  • Use a clone profile to exclude tables that you don’t want to replicate.
  • Clearly define and document the data and configurations to be included.

---

Best Practices for Cleaning Up Data:

If you ask me, as a BPC, I would recommend:

1. Avoid Bringing All Data:
   • Only migrate data that is essential and relevant.
2. Set a Cutoff Point:
   • Migrate only “in-progress” records up to a defined cutoff date.
3. Encourage Data Closure:
   • Push teams to close as many records as possible in the old instance before cloning.
4. Foundation Data:
   • Bring only critical foundational data; exclude anything that hasn’t been used in a long time.
5. Reports and Dashboards:
   • Migrate only relevant and actively used reports and dashboards.

Let me know if you’d like to discuss this further or if there’s anything else I can assist with.