Splitting Snow instance to two instance for 2 org best practice

[Servicenow lear]

Hello All ,

I would like to get some guidance or best practice on this scenario :

We are using 1 instance as a company but we might have to split the instance into two org with seperate identities.  What is the best rpactice on disconnecting data and config ?

Instance Z >>Now becomes >>Instance A and instance B .   Instance B needs to have its config that existed in Instance Z and Instance A needs to have its config that existed in Instance Z.

Should we clone Instance Z and then trim config and data ?  what would be the right approach ?

[Vinod54]

Hello @Servicenow lear ,

Before answer to the question two key points to specify. 

1. Best practice recommended by ServiceNow official stance, is to use a single instance whenever possible. A split should be a deliberate, well-justified architectural decision.

2. Before going the two-instance route, evaluate Domain Separation, which is ServiceNow's built-in mechanism for logical data isolation within a single instance.

Finally if split is the last option, consider below best practices thoughtfully. 

• Clone the current production instance as a starting point for the second org's instance.
• Scope and tag data belonging to each org (companies, assignment groups, users, CIs, tickets).
• Export org-specific data using Import Sets or Data Export APIs and import it into the new instance.
• Reconfigure integrations, SSO, MID servers, email settings, and discovery schedules for each instance independently.
• Keep the original instance intact as a fallback until you're confident the new instance is stable,  do not delete historical records, as this creates compliance and audit issues.

If the answer helps, hit the Helpful and Accept As Solution buttons. 

Thanks,

Vinod Kumar M

[Dr Atul G- LNG]

Clone is the best option if you want A and B to be the same. once clone done, and then it will follow its configuration and way of working.

[drbob]

Once cloned, are they needing to stay in sync (logic/process) ? You're duplicating effort but as they start from the same place then the update sets you prepare in DEV can be applied to both to keep them the same. ...but you run the risk of them getting out of sync if someone forgets or if there is a manual intervention in one that isn't done on the other. In theory you can keep one DEV for both but if A and B _do_ get out of sync cloning one over DEV will render it inappropriate as a source for the other.

If the logic is to be maintained then, as Vinod said, one instance is definitely better and use some mechanism to keep the data separate.


If the logic/processes will diverge and this is just your starting point then you'll need a new DEV and TEST too..