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

[snehapatel]

Thanks @Dr Atul G- LNG. This was very helpful.

We have an identifier to identify the data but no identifier for code for X & Y. Some code is common to both X and Y.

Could you please further elaborate what is meant by 

Set a Cutoff Point:

• Migrate only “in-progress” records up to a defined cutoff date.

Moreover I understand that by default the workflow context data is excluded from cloning. This is because if this data is included in cloning then it might have issues as cloning might run for hours. I think same would be case for the SLA clocks. Could you please suggest what strategy should be followed for the open records ?  

Thanks,

Sneha

[Dr Atul G- LNG]

Hi @snehapatel 

Greetings!!

We have an identifier to identify the data but no identifier for code for X & Y. Some code is common to both X and Y.

Atul: 

Good news for data, but bad news for code. In this scenario, you can copy the code from A to B and then comment out any parts of the code that are not applicable for Y.

Key considerations:

1. Time-Consuming: The process requires significant effort and attention.
2. Risk-Prone: You’ll need to test thoroughly, down to the smallest use cases, to ensure nothing breaks.
3. Logic Updates:
   • Pay close attention to logic changes, especially if there are hardcoded values.
   • Adjust logic if certain values are shared between X and Y.
4. Impact Analysis: A comprehensive impact analysis is critical before proceeding with the move.
5. File Identification: Identify files that are common, create a list, and prioritize them for migration.

Proper planning and careful testing are essential to minimize risks and ensure a smooth transition.

Could you please further elaborate what is meant by 

Set a Cutoff Point:

• Migrate only “in-progress” records up to a defined cutoff date.

Atul:

Cut-off Details:

• By 31st March 23:59, any record for Y that remains open or in progress in Instance A will be moved to Instance B.
• From 1st April 00:01, all new records for Y will be created in Instance B.
• Any records for Y that are resolved in Instance A by 31st March will remain in Instance A for tracking purposes.
• The goal is to ensure that:
  1. Only resolved records for Y stay in Instance A.
  2. All other records (open, in-progress, or new) for Y transition to Instance B.

This ensures a clear separation of responsibilities and proper tracking of records across both instances.

Moreover I understand that by default the workflow context data is excluded from cloning. This is because if this data is included in cloning then it might have issues as cloning might run for hours. I think same would be case for the SLA clocks. Could you please suggest what strategy should be followed for the open records ?  

Atul:

The main challenge with moving incidents from Instance A to Instance B is that the records will transition to a new state in B, and a new SLA will be applied. There’s no direct way to retain the original SLA in Instance B for records transitioned from A.

Suggested Approach:

1. Keep Instance A Open for Y for 7 Days Post-Cutoff

   • Allow Instance A to remain operational for managing Y-related incidents for a buffer period of 7 days after the cutoff.
   • During this period, close all open records for Y in A and resolve them there.

2. Start Fresh in Instance B Post-Cutoff

   • From the cutoff date, 1st April 00:01, begin creating new incidents for Y directly in Instance B.
   • This ensures clean separation and avoids complications with SLA tracking across instances.

3. Advantages of This Approach

   • Simplified Tracking: All unresolved incidents remain in Instance A until they are resolved, making it easier to manage SLAs and historical data.
   • Avoid SLA Conflicts: Since incidents are resolved in A, the SLA logic remains intact without needing adjustments in B.
   • Seamless Transition: Starting fresh in B ensures a clean slate for new records without legacy issues.

This approach ensures smoother tracking and maintenance while minimizing SLA disruptions during the transition. Let me know if you'd like to discuss or refine this further!

[snehapatel]

Thanks @Dr Atul G- LNG for very detailed explanation. 

Considering the fact that lot of code analysis and cleanup would be required (in some cases some amount of refactoring as well), would cloning be a better approach compared to selective movement of data & code via update sets ?

Thanks,

Sneha

[Dr Atul G- LNG · Accepted solution]

Hi @snehapatel 

Greetings!!

As I mentioned earlier, cloning is essentially a full copy-paste process. If you clone B from A, it means A and B will be identical in every aspect. Here's why I think cloning can be beneficial in this scenario:

• You can simply remove the code related to X from B, which should be a relatively straightforward process.
• Implement ACLs to hide X's data in B, ensuring that no operations related to X can be performed by the other customer.

Regardless of whether you choose cloning or a selective approach, the workload will be significant. Proper planning is essential, and thorough testing is crucial to ensure everything functions as expected.

[Dr Atul G- LNG]

Thanks @snehapatel  for accepting my answer as solution. If you still any doubt, happy to help.