ServiceNow Domain Separation for Service Providers

[Naushad1]

Hi All,

I was wondering if anyone can help me in understanding the difference between "ServiceNow Domain Separation for Non MSP" and "ServiceNow Domain Separation for MSP". How the configurations are different in ServiceNow?

ServiceNow advised that it is not possible to retrospectively reconfigure an MSP domain within a non-MSP configuration. The platform must be rebuilt and configuration migrated to the new build.

Does renaming existing domain and creating new child domains won't be sufficient?

Also in order to migrate configurations and data from one domain to the other , is there any process to follow?

Note: CSM has been installed on the instance.

Thank you very much for the response.

[Allen Andreas]

Hello,

If you're already in discussions with ServiceNow about it, I would continue in that support case/communication? As what you're asking isn't something common and I would imagine very few would have any knowledge related to that and are regularly answering questions on the forums, thus your question may end up getting unanswered.

[Punit S]

Hi Naushad,

ServiceNow Domain Separation is a feature that enables multiple customers or business units to use the same ServiceNow instance while ensuring data and process separation. The main difference between "ServiceNow Domain Separation for Non MSP" and "ServiceNow Domain Separation for MSP" is the level of complexity and the scope of separation.

ServiceNow Domain Separation for Non MSP is typically used when a single organization needs to manage multiple business units or departments within the same instance. This type of separation is usually simpler and involves creating domains for each business unit with different sets of permissions and configurations.

ServiceNow Domain Separation for MSP, on the other hand, is used when a Managed Service Provider (MSP) needs to manage multiple customers within the same instance. This type of separation is more complex and involves creating customer-specific domains with different sets of permissions, configurations, and data isolation.

To answer your question, renaming an existing domain and creating new child domains may not be sufficient to achieve the level of separation required for ServiceNow Domain Separation for MSP. It is recommended to follow the ServiceNow Domain Separation for MSP guidelines and best practices to ensure data and process separation between different customers.

In terms of migrating configurations and data from one domain to another, ServiceNow provides several tools and processes to assist with the migration, such as the Domain Migration application and the Import Sets feature. However, the migration process can be complex and requires careful planning and execution to ensure data integrity and minimize disruptions to the users.

In your case, since CSM has been installed on the instance, it is important to ensure that the migration process does not impact the CSM configuration and data. It is recommended to consult with ServiceNow experts or partners to ensure a smooth and successful migration process.

Please mark my answer correct/helpful in case it adds value and moves you a step closer to your desired ServiceNow solution goal. 

Thanks,
Punit

[Naushad1]

Hi Punit,

Thank you so much for your response and brief definition of MSP and Non-MSP Domain Separation.

I understand Domain Separation for MSP is complex where configurations, data isolation and permissions needs to be carefully managed however process for creation of domains hierarchy (Parent-Child) remains the same?

Also my understating on "Domain Migration application" is used to move a customer from a domain-separated environment to their own dedicated instance. I am missing anything here?

[Punit S]

Nuashad,

Migrating an application from a ServiceNow MSP instance to a private cloud can be a complex process that involves multiple steps. Here is a general outline of the process:

1. Review the application: Before migrating the application, review it to determine if it is compatible with the private cloud environment. Check for any customizations or integrations that may need to be updated or changed.

2. Plan the migration: Create a migration plan that includes timelines, resources, and dependencies. Determine what data needs to be migrated and how it will be migrated.

3. Configure the private cloud environment: Set up the private cloud environment, including the necessary infrastructure, servers, and network configuration.

4. Prepare the source MSP instance: Make sure the source MSP instance is in a stable state and that all necessary data has been backed up.

5. Export the application: Use the ServiceNow Application Export feature to export the application and any related data from the source MSP instance.

6. Import the application: Use the ServiceNow Application Import feature to import the application and data into the private cloud environment.

7. Test the application: Test the application in the new environment to make sure it is functioning as expected. Address any issues that arise during testing.

8. Go live: Once the application has been tested and is functioning properly, switch over to the private cloud environment.

It is important to note that the specific steps and requirements for migrating an application from a ServiceNow MSP instance to a private cloud will depend on a number of factors, such as the complexity of the application, the size of the data set, and the specific requirements of the private cloud environment.

I am not aware of any application that does migration from an MSP to a private cloud instance, if there's any, please reach out to your AE to know more .

It is recommended to consult with a ServiceNow expert or partner to ensure a smooth and successful migration.

Mark my answer correct or useful if this helps .

thanks,

Punit