Commercial to Regulated Market(SPP-ServiceNow Protected Platform) Instance migration FAQ (Technical Support perspective) - Support and Troubleshooting

Commercial to Regulated Market(SPP-ServiceNow Protected Platform) Instance migration FAQ (Technical Support perspective) .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: #000000; } span { font-size: 12pt; font-family: Lato; color: #000000; } h2 { font-size: 24pt; font-family: Lato; color: black; } h3 { font-size: 18pt; font-family: Lato; color: black; } h4 { font-size: 14pt; font-family: Lato; color: black; } a { font-size: 12pt; font-family: Lato; color: #00718F; } a:hover { font-size: 12pt; color: #024F69; } a:target { font-size: 12pt; color: #032D42; } a:visited { font-size: 12pt; color: #00718f; } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } }

Whitepaper: Accelerating digital transformation with the ServiceNow Protected Platform

For any migration-related questions, please contact your ServiceNow Account representatives. They can connect with the Cloud Migration Program Manager for further assistance via cloudmigrationservices@servicenow.com Most of your security inquiries should be addressed in the "Assessment Report for your respective environment." This report should be available through your organisation's ServiceNow contacts. If you don't have it, you can request these documents from your ServiceNow Account team representatives. Additionally, you might want to coordinate with your SAM and ServiceNow Account representatives to arrange a session with the ServiceNow Security team. If you require any architecture or data flow documents specific to SPP boundaries, it's best to obtain these through your ServiceNow Account representatives, as there may be legal restrictions involved. The instance email address will be assigned a regulated market domain, such as instancename@servicenowcloud.com.* The instance URL will also possess a regulated market domain, for example, instancename.servicenowcloud.com.* For SPP-AU, access to the instances will be limited and only available from pre-whitelisted IPs /IP ranges. SPP-SG doesn't have any restrictions. The instance IP will be changed if the instance is migrated from the Commercial Environment ( service-now.com to servicenowcloud.com)*) How does SPP-AU (Australian Regulated Market/APC/IRAP) differ from Commercial NowSupport? HITIDE Knowledge Base How does SPP-SG (Regulated Market Singapore) differ from Commercial NowSupport? HIRISE Knowledge Base FAQ 1. Can we clone from Commercial to SPP? 2. Can we restore from Commercial to SPP? 3. If we are planning for migration, should we maintain commercial instance names on SPP? 4. Will there be any change in the Customer Support URL after migrating to SPP? 5. Will my Instance IP change when migrated to SPP? 6. How long will the migration take? 7. Will there be any outages during the migration? 8. Will there be any data loss during the migration from Commercial to SPP? 9. Will we get the same number of nodes/database capacity allocated once we migrate to SPP? 10. Will there be any change in end-user access to the instance after migrating to SPP? 11. Will my Instance URL change? 12. Does SPP support custom URLS? 13. Will my instance email address change? 14. Can we perform a dry run of the migration? 15. Can I perform a dry-run Commercial X to SPP Y migration? 16. What are the high-level steps for migration? 17. How will I keep track of progress during migration? 18. Can we do a dry-run Commercial Prod to SPP Prod migration? 19. Can we enable commercial to SPP email forwarding? 20. Can we enable commercial to SPP URL redirection? 21. How long will the URL redirection and email forwarding run after Go Live to SPP? 22. Will any changes be made to the commercial instance during a dry run? 23. What happens to the commercial instance after it gets migrated to SPP? 24. Will we be able to access a commercial instance after SPP Go Live? 25. What happens to existing integrations post-SPP migration? 26. Is there an option to roll back SPP to Commercial after going live ? 27. Do I have to reconfigure the MID servers after migrating to SPP? 28. Will all existing features on the instance work in the SPP environment? 29. Can we use ServiceNow store functionality in SPP? 30. Can we use App repo functionality to install our custom-scoped application after migrating to SPP? 31. Are my existing published custom-scoped application versions available after Go Live? 32. Will the existing clone targets work after migrating to SPP? 33. What data will be changed on the instance post-migration to SPP? 34. How do I purchase Apps for my SPP instance? 35. Will my partner apps work in SPP? 36. Can an organisation transfer their existing users from NowSupport to the SPP* support portal? 37. Can an organisation transfer their existing cases and changes from Now Support to the SPP* support portal? 38. Transferring Existing Subscriptions and Entitlements to the SPP Regulated Market

1. Can we clone from Commercial to SPP? We cannot clone from Commercial to SPP as these are in 2 different infrastructures. SPP is high-security, so there is no direct connection between it and commercially hosted or other Regionally Regulated Market infrastructures.

2. Can we restore from Commercial to SPP? Restore can be initiated, but many prerequisites must be met first. You must match the backend infra versions to SPP/Regulated Market-approved versions (FIPS approved) before using the backup to initiate the restore. These activities do not create any functionality issues with the existing instance and must be one-time configurations.

3. Should we maintain existing Commercial instance names on SPP if we are planning for migration? Yes. It is better to retain the existing name as encryption keys are generated and linked with the instance name. During the migration, the source names should match the destination names; after migration, they can be changed within the Regulated Market infrastructure after Going Live.

4. Will there be any change in the Customer Support URL after migrating to SPP? Commercial support is support.servicenow.com, and Regulated Market support will have its own support URLS. Your account representatives will provide these links.

5. Will my Instance IP change when migrated to SPP? Yes. The IPS will be changed on the Regulated Market Infrastructure. KB0538621: Finding the IP information for your instance

6. How long will the migration take? This depends on the size of your instance and how you want to move the data. This information can only be provided by performing a dry run for the Restore and calculating the time it takes to copy and restore the data to the Regulated Market infrastructure. Please work with your account representatives and discuss with impacted teams once the dry runs are complete.

7. Will there be any outages during the migration? Yes. The high-level summary is as follows:

The customer should confirm the “Instance down” time as an update to the ServiceNow Migration SPOC ServiceNow Shut down the Commercial instance == Outage starts here Perform the backup of the Commercial instance Transfer the backup of the Commercial instance to the Regulated Market. Initiate the restoration of Regulated Market Infrastructure. Once the instance is up, make the database changes from the backend to update the properties and configuration based on the Regulated Market Infrastructure. Repoint the nodes to the DBI on the Regulated Market == Outage Ends here ServiceNow confirms the migration completion. The Customer can test the instance and enable "Email Send" and "Email Receive," which will process the emails from the infra. These timelines can be captured only with a dry run of the migration restore. The outage ballpark time varies with each case based on complexity and the data size.

8. Will data be lost during the migration from commercial to SPP? No data will be lost during migration. The instance is shut down during the migration window, and the database is read-only so that no users can connect. A database backup is performed and restored on the Regulated Market infrastructure.

9. Will we get the same number of nodes/database capacity allocated once we migrate to SPP? The resources linked to the Regulated Market instance will remain configured on the commercial instance.

10. Will there be any change in end-user access to the instance after migrating to SPP? Regulated Market instances can only be accessed from allow-listed IPS for SPP-AU. The URL is provided well in advance. An OOB instance with the same name will also be created on the Regulated Market infrastructure well in advance. IPS and other secure information can be provided and set up before migration. Only the data is migrated from the commercial to the Regulated Market during migration. SPP-SG-hosted instances don't have any restrictions.

11. Will my instance URL change? Post-migration, the URL will be changed from "instancename.service-now.com" to "instance name.servicenowcloud.* (depending on the Regulated Market domain)."

12. Does SPP support custom URLS? Yes, SPP supports custom URLS.

13. Will my instance email address change? Yes. The instance email will be changed from instancename@service-now.com to "instancename@servicenowcloud.* (depending on the Regulated Market domain)."

14. Can we dry-run the migration? A dry run can be performed before migrations. The migration program manager from ServiceNow can provide you with the specifics. Prerequisites and implementation take a few days, so dry runs should be planned correctly to accommodate all timeline segments. Please work with your account representative/architect for more information and to set up dry runs.

15. Can I perform a dry run for commercial X to SPP Y migration? Unfortunately, we can only do a dry run to match the source and destination. For example, X to X, prod to prod, dev to dev, or test to test. X over Y (prod over dev) cannot be tested because of the dependencies of the instance and the encryption keys generated. You can initiate a PROD to DEV clone within the commercial environment and then run a commercial DEV to SPP DEV.

16. What are the high-level steps of migration? The steps are as follows.

If the customer opts for email forwarding , it is crucial to ensure that all emails are redirected to the SPP infrastructure for the post-migrated SPP instance to handle. ServiceNow will configure this on our backend. Subsequently, the customer must disable the "Email Send" and "Email Receive" functions before taking the instance offline. This measure guarantees that emails remain on the instance or are forwarded to the SPP infrastructure, are not processed by the commercial instance, and are available in the SPP infrastructure for the migrated SPP instance to consume once it is online. After completing Point 1, the customer should confirm the “Instance down” time as an update to the ServiceNow Migration SPOC. ServiceNow: Shut down the Commercial instance and make it read-only from the database level. == The outage starts here. Create backend configuration for an auto URL redirect to the SPP instance URL Create a backup of the Commercial instance. Transfer the backup of the Commercial instance to the Regulated Market. Initiate the restoration of the Regulated Market infrastructure. Once the instance is up, make the database changes from the backend to update the properties and configuration based on the Regulated Market infrastructure. Repoint the nodes to the DBI on the Regulated Market == Outage Ends here. Have the customer test the integration and functionality. The customer should enable "Email Send" and "Email Receive," which will process the emails from the infra. Customer to release the instance to end users. URL redirection from commercial and auto email forwarding will function until commercial instances are retired . Commercial Instance retirement is requested by the customer_admin/ServiceNow Account representatives when ready. 17. How will I keep track of progress during migration? As the migration process has many segments, communication timelines will be set once the outage window is established, and your account representatives/Migration program manager will be provided with status and details. Currently, the process is not automated.

18. Can we dry-run the commercial prod to SPP PROD migration? Yes, this is possible. However, the commercial PROD will not be shut down; only the restore will be tested. This process will not impact the functionality of the commercial PROD instance. If any LIVE data gets onto "instancename.servicenowcloud.com.xx" as part of post-migration dry run testing, ServiceNow cannot recover/transfer it. Please be careful when testing any live integration during this DRY RUN .

19. Can we enable commercial to SPP email forwarding? This is possible and will work if the commercial instance is available (not retired). Migration will make the commercial database read-only. We use the existing commercial instance record to configure email forwarding. ServiceNow can configure the backend to auto-forward instancename@servicenow.com emails to the SPP instance email instancename.servicenowcloud.com.*

20. Can we enable commercial to SPP URL redirection? This is possible and will work if the commercial instance is available (not retired). Migration will make the commercial database read-only. We use the existing commercial instance record to configure the URL redirection. Customers can also work with their internal network team to create URL redirection within the customer network if they want a permanent redirection.

21. How long will the URL redirection and email forwarding run after the Go-Live to SPP? The redirection works as long as the commercial instance is available and operational on the commercial infrastructure. When the instance is retired, the instance record is decommissioned on NowSupport(Commercial) infra, and the backend configurations(Old FQDN, DNS, and Loadbalancer entries) are also removed, which removes the configuration.

If customers want to extend the redirection option, they should work with their internal network team to create URL redirection within their network.

22. Will any changes be made to the commercial instance during a dry run? Infrastructure within your commercial environment will be added with the FIPS-approved versions of backend applications, such as databases. This is configured for the migration dry run. This will not impact your existing commercial infrastructure and functionality. A few legacy encryption components will be disabled on your commercial instance.

23. What happens to the commercial instance after it is migrated to SPP? The commercial instance is put into read-only mode from the database. Nodes will not be attached to it for users to log in. The instance record will be listed in the "Manage my instance" section on the Support portal until the instance is retired.

24. Can we access the commercial instance after SPP Go Live? Once the instance is migrated, the commercial instance is not accessible. The instance will be put into read-only mode from the backend, and there will be no option to log in to it. If a URL redirection is configured(Customer network/NowSupport commercial network), the end user accessing the instance will be redirected to the Regulated Market instance.

25. What happens to existing integrations post-SPP migration? As the instance is a restoration of the commercial instance, the configuration remains intact. However, you must work with customer support and your account reps to ensure the external integration components are accessible from SPP. This can be tested during the dry run. The instance IP can be checked from the SPP Support portal. KB0538621: Finding the IP information for your instance . Please keep in mind for SPP-AU that the ADC/LoadBalancer explicitly restricts the inbound traffic allow list. External integrations with a public dynamic IP range (e.g., GitHub with 2500+ public IPS) should be revisited for SPP-AU-specific solutions. There are NO whitelist restrictions for SPP-SG.

26. Is there an option to roll back SPP to commercial after going live? There will not be a rollback option after Go Live. The commercial instance before cutover can be brought up on commercial from a service restore. Delta records created in the SPP instance post-Go Live can be transferred to the commercial instance. These instances are only accessible from allow-listed IPS, and ServiceNow cannot transfer any data from the SPP VM. We will help customers restore these records as soon as possible. But this will be a complex manual procedure, and we cannot provide a ballpark estimate.

The base SOP for this will be data loss, where the instancing functionality will be restored as early as possible. The delta transfer takes a few days based on the amount of data and the complexity of the requirements. We will involve multiple SME teams from a Fix Forward aspect. See Restoring a Production Instance from Backup

27. Do I have to reconfigure MID servers after migrating to SPP? Existing MID servers will continue to function; if there are any connectivity issues post-Go Live, we will assist you in fixing them.

28. Will all existing features on the instance work in the SPP environment? A few of the existing features will not work on SPP. This list is managed on the KB Services not available in ServiceNow Regulated and Self-Hosted Environments .

29. Can we use ServiceNow store functionality in SPP? Regulated Markets has its version of the store, which can be accessed from its support portal. See Federal AppStore Login for details.

30. Can we use App repo functionality to install our custom-scoped application after migrating to SPP? You can use app repo functionality, but the app versions published in Commercial AppRepo will not be available for installation once migrated to SPP. You can take the app version as XML, and once you are on the SPP instance, this can be committed, and future versions can be uploaded to the AppRepo. Please look at How to Move Custom Scoped Applications between instances for more information.

SPP ServiceNow application repository (Custom Applications) Entitlement check

31. Will my existing published custom-scoped application versions be available after Go Live? Currently, we cannot make published custom-scoped applications available after Going Live. If this is a requirement, we will try to find solutions. One way to solve this issue is to back up the app version in XML from the commercial developer before the migration.

32. Will the existing clone targets work after migrating to SPP? They will not work because a new target needs to be created, and the Domain and instance parameters of the instances will be changed.

33. What data will be changed on the instance after migration to SPP? Regulated Market-specific properties for automation and management will be changed from the ServiceNow backend during the Go-live outage change window. Customer-created data or custom configurations on the instance will not be changed.

34. How do I purchase Apps for my SPP instance? Purchasing Apps in SPP will be the same as in the commercial. You can work with your account representatives, and if you have any licensing issues, we can fix them after the ServiceNow Go-live outage change window. There will not be any changes to customer-created data or configurations on the instance.

35. Will my partner apps work in SPP? Yes. As we have regulated the Market Store, these apps will be available for download and installation based on your entitlement status.

36. Can an organisation transfer their existing users from NowSupport to the SPP* support portal? The initial set of users is automatically loaded from the sales portal to the SPP* support portal. However, not all users will transfer automatically due to the restricted environment. Therefore, customers should manually create user accounts relevant to the SPP* support portal.

37. Can an organisation transfer their existing cases and changes from Now Support to the SPP* support portal? Yes, all existing cases and changes for an organisation can be transferred from NowSupport to the SPP* support portal. However, if a case is linked to a user who isn't in the SPP* support portal, it will appear blank due to the missing reference value. The same applies to instance records and user records, especially for the "Affected CI field” on a change, as the instance record on SPP* is newly created and has a different reference value. Nevertheless, the instance names used in the description, short description, or the case content will sync as they are. Please create a case on the SPP* service portal for this request, and we can manage it both before or after the migration.

38. Transferring Existing Subscriptions and Entitlements to the SPP Regulated Market As we proceed with the migration to the SPP Regulated Market, it is crucial to note that customers within this sector will have distinct CONTRACT records, separate from those in the Commercial sector. This migration does not include subscriptions and entitlements for purchased products and applications, which are managed by sales/account representatives based on individual customer contracts and renewal schedules on the sales portal, and will sync onto the instances. It is imperative that account representatives and customer contacts ensure that the Regulated Market CON* records remain up to date. Please collaborate with your account representatives to verify that the Regulated Market CONTRACT records are up to date with the required subscriptions and license counts. This precaution will help prevent issues when licenses are downloaded to the SPP instance after migration. There is no method for customers to confirm the presence of these records until the instance is migrated and subscriptions are downloaded to the servicenowcloud.com* instance.

Please obtain confirmation from account representatives to ensure all products are appropriately mapped. Following instance data migration, the absence of Licensed applications for installation/update in the Production environment Application Manager can lead to significant delays if they need to be installed or updated, depending on the correct subscription/entitlement mapping of licenses. Resolving such issues post-migration within the time-bound SLA requires coordination with various backend teams for contract verification and relies on daily data loads. Given the involvement of multiple backend systems in the data flow, timely remediation may not always be feasible.