Go Live Best practice ( Tech Support Perspective) Onboarding.SummaryBefore starting your development process, please engage your Solution Consultant. You should work with them on preparing your instance for Development and Go-Live.Release These are a few points to consider, collated from the cases created by Tech Support during this process. They will provide an outline of the tasks involved during this process, which will be different for every organisation as per their specific development cycle and in-house process. Instances are typically provisioned with or without DEMO DataRemoving the DEMO Data before going live /starting development is a good practice. Demo Data Removal FAQIf the DEMO Data removal is attempted after Go live, it can create issues where there were cases where applications/Workflows were built based on DEMO components, and that was lost.DEMO data removal works on removing the data with specific demo data sys_id from respective tables. There is no cross-comparison to check if that record with the sys_id is customised/ used.When a store app/custom-scoped app/ Plugin gets installed, there is a possibility that tables are created with different sys_ids. So it is always advisable that the customisations/development are done on an instance that will be the "MAIN". This can be any instance. ** Note from doc** Some base system records are created on an instance after provisioning and do not match between different instances, leading to problems with update sets. The best way to avoid this issue is to: Provision production and non-production instances.Clone the production instance onto the non-production instance. InstructionsDevelopment BEFORE Go Live Step 1. Zboot the PROD instance when it is provisioned without the DEMO data. Users must log a case to Technical Support for the zBoot request for PROD instances. More info on Zboot is here Step 2. Install the plugins you are entitled to in the contract as soon as a Zboot is completed on PROD. We recommend testing plugins in SUB PROD instances before doing it on PROD. ( There is no graceful deactivation for a plugin once installed. We have a rollback option available for 7 days. More information on Plugin Roll Back If you have purchased modules, these can be installed on PROD as these were purchased ( Eg, ITOM, ITBM, Discovery) Plugin Activation Overview This will ensure that your PROD instance, which will be the "MAIN" instance, is ready with all the modules/plugins you purchased. Step 3. Now you can initiate a clone of your lower instances from the PROD instance. Create a clone target first ( you need the admin credentials of the lower instance to do that) "This should be a FULL CLONE ( OOB preservers and excluders) to get the base data transferred to all subprod instances"Request a clone CLONE - Frequently Asked Questions (FAQ) This will ensure that all your lower instances are on par with the PROD instance in terms of sys_id and without DEMO data. Now, you can start development on the DEV instances. Important Modules Currency: If you plan to use a single-currency on your instance, now is the time to set this; changing to a single currency model after going live is very complicated. Refer to the "Single currency mode" section on KB glide.system.locale is a very important property, and update this at the earliest. Plugins/Store Apps: For your Go Live, if you are cloning from your SUBPROD to PROD, please make sure you do not have any Non-Purchased/Non-Entitled/ Non-Subscribed plugins installed on your SUBPROD, as these will be cloned over to your PROD. Clones are basically a DB restore with exclusions preserved after the restore. Only data can be excluded and preserved during cloning, and plugins are configurations. The customer can try paid plugins/Store Apps on a SUBPROD instance without restrictions. If a plugin was installed on a SUBPROD, it can be cloned from a PROD. If a plugin is active on PROD, it cannot be deactivated/uninstalled. Uninstall a ServiceNow plugin.Plugins: Visibility / Activation / Licensing Go Live Traditional approach(Update-set) **Make sure all are in sync, which is cloned from the main instance to ensure the sys_ids across all are the same. If there is a mismatch, the config data coming in via Update-set cannot find the data on the target because of the sys_id mismatch. Capture all your developments on Update-sets on DEV Get started with update setsClone PROD to TEST ( Safer if PROD data was changed). Make sure a FULL clone, not EXCLUDING anything( options on request clone form)Commit this in TEST/UAT/SANDBOX and do Testing: Creating, testing, and moving customisationsIn case of any issues, address the problems on DEV and capture this on V1.1 update-set.If the PROD data was changed while on Point 4, perform Point 2 again. This is optional as we are dry running this to analyse the impact on PROD.Perform Point 3 again if you performed Point 5Commit the V1.1 on TEST/UAT/SANDBOX and do TestingOnce the testing is passed, commit this on PROD in the same commitment order.Make sure you are taking the update-sets from DEV==> TEST and DEV==> PRODYou can also use Scoped Application development to move custom modules between your instances. Please refer to the documentation here Alternative Approach( Faster) Publish any Scoped application on DEV to the Application repositoryClone DEV to TEST/UAT/SANDBOX and do Testing ( this is to avoid no TESTING data on DEV)In case any issues are identified, fix this on DEV.Perform Point 1 again and do Testing.If you have a Scoped app in Development mode, post a clone on TEST/UAT/SANDBOX; Delete the application and install the application from the Application repository as we published them on Point 1Once the data integrity is confirmed, please remove the testing data on TEST/UAT/SANDBOX Mass-Deletion and Excess Data Management RecommendationsTest again to ensure the customisations/development work is as expected, as we removed data.Once Point 7 is validated, perform the clean-up on DEV ( we already tested the impact on TEST/UAT/SANDBOX, which is a clone of DEV on Point 6)Create a case for customer support and ask them to enable on-demand backup for the clone option for the DEV(Source) instance.Schedule the clone from DEV to PROD on the go-live date-time so that the clone engine will take a DEV (Source) backup at the start of the clone start time and use that to perform the clone. Settings for configuring the PROD instance as a clone target are covered here. There are options to exclude the data while cloning, so test/dummy data from the Source can be excluded.You can also follow the instructions available for Delete all records from a tableYour PROD will have all the customisations/developments, and you can go live. Go Live approaches that are not recommended. Requesting an instance rename with Now Support Service Catalogue: Instance renaming is time-consuming, as the name cannot be used until the old reference URL is decommissioned. So, if you want to make DEV into a PROD, we cannot use the PROD name for DEV if PROD still has that name. Restoring an instance with the Now Support Service Catalogue (Backup of DEV to be restored to PROD):- Unfortunately, there is no on-demand backup available for restoration. Also, a restore will replace instance-specific parameters, and you have to reconfigure them again (Eg, themes). A clone can retain instance-specific parameters and themes, and only the configuration and data will be transferred. Can ServiceNow monitor the instance during/post Go-live/Module Implementation? We do not recommend creating placeholder cases for Tech Support to monitor instances during Go-Live/Module implementation, as we have different modules and SME teams for each functionality, and a placeholder case will not help here, as the cases should be addressed for individual teams for respective issues. If any issues are observed during/after these activities, customers are encouraged to go to the Now Support Help Centre for help, and we will be able to help you with that specific issue. It would also be great if you could create a case and call us so that we have more details of the problem in the case, including steps to reproduce, logs, and Screenshots. We need these details to start troubleshooting any operational or functionality issues. We have proactive monitoring in place for any instance/infra-specific resource constraint issues at all times. In case of any resource constraints, automated alerts are created, and we will be working with the customers on these issues as separate tickets to remediate this. Our monitoring solution reacts at the time of the event and takes appropriate action as needed, negating the need for proactive Customer Support monitoring. If proactive monitoring is conducted by support engineers on an instance, this would be periodically every few hours and could lead to missing an event or not reacting fast enough due to external factors. For these reasons, ServiceNow Customer Support relies on our automated monitoring system. More information on ServiceNow Monitoring - Overview and Insight