Go Live Best practice ( Tech Support Perspective) Onboarding.InstructionsBefore starting your development process; please engage your Solution Consultant for this and you should be working with them on preparing your instance for Development and Go Live. These are a few points to consider which have been collated from the cases created by Tech Support during this process which will provide an outline of the tasks involved during this process will be different for every organisation as per their specific development cycle and in-house process. Instances are normally provisioned with or without DEMO DataIt is a good practice to remove the DEMO Data before Going live /Starting development. 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 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 the customisations/development is 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. Development BEFORE Go live Step 1. Zboot the PROD instance as soon as it is provisioned without the DEMO data. Users are instructed to log a case to Technical Support for the zBoot request for PROD instances. More info on Zboot is here Step 2. Install the Plugins which you are entitled to with the contract as soon as a Zboot is completed on PROD. We recommend testing plugins in SUB PROD instances first 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 make sure that your PROD instance is ready with all the Modules/Plugins you purchased and this will be the "MAIN" instance. Step 3. Now you can initiate a clone to 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 make sure 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. Currency:If you are planning to use a single-currency on your instance, now is the time to set this as if you do not set it now, changing to single current model after go live is very complicated. Refer "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 this will be cloned over to your PROD. Clones are basically a DB restore with exclusions preserving initiated after the restore. Only data can be excluded and preserved during clone and plugins are configurations. There are no restrictions imposed for the customer to try paid plugins/Store Apps on a SUBPROD instance. If this was installed on a SUBPROD, this can be cloned over from a PROD. If a plugin is active on PROD, it cannot be deactivated/uninstalled. Uninstall a ServiceNow pluginPlugins Visibility / Activation / Licensing Go Live Traditional approach(Update-set) **Make sure all are in sync which is cloned from the main instance to make sure 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 target because of sys_id mismatch. Capture all your developments on Update-sets on DEV Get started with update setsClone PROD to TEST ( Safer if in case 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 customizationsIn case of any issues, address the issues on DEV and capture this on V1.1 update-set.Perform Point 2 again if the PROD data was changed while on Point 4. 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 order of commitment.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 of any issues 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 once more to make sure the customisations/development work 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 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 will be using that to perform the clone. Settings for configuring 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 Catalog:- Instance rename is a time-consuming process 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 is still having that name. Restoring an instance with the Now Support Service Catalog (Backup of DEV to be restored to PROD):- Unfortunately, there is no on-demand backup for restore available. Also, a restore will replace instance-specific parameters and you have to reconfigure them again (Eg: themes). A clone has options to 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 instance 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. In case of any issues observed during/after these activities, customers are encouraged to go to Now Support Help Center for assistance and we will be able to assist you with that specific issue. It will also be great if you can create a case and call us so that we have more details of the issue on the case with Steps to Reproduce/Logs/Screenshot. For any operational or functionality issues, we need these details to start troubleshooting. 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 which negates the need for Customer Support proactive monitoring. Were proactive monitoring to be 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