Go Live Best practice ( Tech Support Perspective) Onboarding.Summary<!-- /*NS Branding Styles*/ --> .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } span { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } h2 { font-size: 24pt; font-family: Lato; color: var(--now-color--text-primary, black); } h3 { font-size: 18pt; font-family: Lato; color: var(--now-color--text-primary, black); } h4 { font-size: 14pt; font-family: Lato; color: var(--now-color--text-primary, black); } a { font-size: 12pt; font-family: Lato; color: var(--now-color--link-primary, #00718F); } a:hover { font-size: 12pt; color: var(--now-color--link-primary, #024F69); } a:target { font-size: 12pt; color: var(--now-color--link-primary, #032D42); } a:visited { font-size: 12pt; color: var(--now-color--link-primary, #00718f); } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } } Before starting your development process, please engage your Solution Consultant. You should work with them on preparing your instance for Development and Go-Live. ℹ These are key considerations collated from Tech Support cases. They outline tasks involved during this process, which will vary for every organisation based on their specific development cycle and in-house process. Release<!-- /*NS Branding Styles*/ --> .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } span { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } h2 { font-size: 24pt; font-family: Lato; color: var(--now-color--text-primary, black); } h3 { font-size: 18pt; font-family: Lato; color: var(--now-color--text-primary, black); } h4 { font-size: 14pt; font-family: Lato; color: var(--now-color--text-primary, black); } a { font-size: 12pt; font-family: Lato; color: var(--now-color--link-primary, #00718F); } a:hover { font-size: 12pt; color: var(--now-color--link-primary, #024F69); } a:target { font-size: 12pt; color: var(--now-color--link-primary, #032D42); } a:visited { font-size: 12pt; color: var(--now-color--link-primary, #00718f); } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } } All Releases Instructions<!-- /*NS Branding Styles*/ --> .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } span { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } h2 { font-size: 24pt; font-family: Lato; color: var(--now-color--text-primary, black); } h3 { font-size: 18pt; font-family: Lato; color: var(--now-color--text-primary, black); } h4 { font-size: 14pt; font-family: Lato; color: var(--now-color--text-primary, black); } a { font-size: 12pt; font-family: Lato; color: var(--now-color--link-primary, #00718F); } a:hover { font-size: 12pt; color: var(--now-color--link-primary, #024F69); } a:target { font-size: 12pt; color: var(--now-color--link-primary, #032D42); } a:visited { font-size: 12pt; color: var(--now-color--link-primary, #00718f); } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } } 1. Prepare Instance for Development2. Instance Go Live 3. Instance Go Live approaches that are not recommended. 4. Plugins/Store Applications Go Live 5. Instance Backup requests before Go live 6. Can ServiceNow monitor the instance during/post Go-live/Module Implementation? 1. Prepare Instance for Development Step 1 — zBoot the PROD Instance Instances are typically provisioned with or without DEMO DataRemoving DEMO Data before going live or starting development is best practice — see Demo Data Removal FAQIf DEMO Data removal is attempted after Go-Live, issues can arise if applications or Workflows were built on DEMO components — that data will be lostDEMO data removal works by deleting records with specific demo data sys_ids. There is no cross-comparison to check if a record with that sys_id has been customised or used zBoot the PROD instance when it is provisioned without DEMO data. Log a case with Technical Support for the zBoot request on PROD instances. More info on Zboot is here Currency- If you plan to use a single-currency model on your instance, configure this now. Switching to a single currency after go-live is very complicated. Refer to the 'Single Currency Mode' section on the KB System Locale-The property glide.system.locale is very important — update this at the earliest opportunity. Step 2 — Install Entitled Plugins and Store Applications Install all plugins you are entitled to under your contract immediately after the zBoot is completed on PROD. We recommend testing plugins in SUB PROD instances first. Plugin Roll Back ℹ There is no graceful way to deactivate a plugin once it is installed. A rollback option is available for 7 days only. If you have purchased modules (e.g. ITOM, ITBM, Discovery), install them on PROD as they were purchased. Plugin Activation Overview KB0759221: Visibility of Plugins and Store Applications on Instances Step 3 — Clone/Restore Lower Instances from PROD Create a clone target first (requires admin credentials for the lower instance). This must be a FULL CLONE (OOB preservers and excluders) to transfer base data to all SUB PROD instances (Request a clone, Clone Frequently Asked Questions (FAQ))Request a restore of your PROD instance backup to the SUB PROD instance so that the SUB PROD instance can be an exact replica This ensures all lower instances are in sync with PROD (same sys_ids, no DEMO data). Development can then begin on DEV instances. When a Store app, custom-scoped app, or Plugin is installed, tables may be created with different sys_ids. Always perform customisations/development on the instance that is he replica of PROD instance ⚠ Some base system records are created on an instance after provisioning and do not match between different instances, leading to problems with update sets. Note from doc** To avoid this: Provision production and non-production instancesClone the production instance onto the non-production instance 2. Instance Go Live Traditional Approach (Update Sets) ⚠ Ensure all instances are in sync via cloning from the main instance. sys_id mismatches mean config data from update sets cannot find matching records on the target. 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 — Scoped Apps) 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. ⚠ If you are cloning from SUB PROD to PROD for go-live, do NOT have any Non-Purchased / Non-Entitled / Non-Subscribed plugins installed on your SUB PROD — they will be cloned to PROD. Clones are essentially a DB restore; only data can be excluded, not plugins. Customers can try paid plugins/Store Apps on SUB PROD without restrictionsIf a plugin was installed on SUB PROD and cloned to PROD, the plugin will stay active on PRODIf a plugin is active on PROD, it cannot be deactivated or uninstalledHow to manage ServiceNow plugins when uninstallation isn't possible 3. Instance Go Live approaches that are not recommended Instance Renaming Requesting an instance rename via the Now Support Service Catalogue(Rename) is not recommended. Renaming is time-consuming — the name cannot be reused until the old reference URL is decommissioned. If you want to make DEV into PROD, the PROD name cannot be assigned to DEV while PROD still holds it. Restoring DEV Backup to PROD Restoring an instance via the Now Support Service Catalogue(Restore) (e.g. backup of DEV restored to PROD) is not recommended. There is no on-demand backup available for restoration, and a restore will replace instance-specific parameters (e.g. themes) that must then be reconfigured. A clone retains instance-specific parameters and themes — only configuration and data are transferred. 4. Plugins/Store Applications Go Live KB0716626: Plugin FAQs KB0695388: Plugin Activation Overview KB0759221: Visibility of Plugins and Store Applications on Instances Plugins may also be requested via the Support Portal catalogue: Request Plugin. Plugins may also be requested from the "Activate Plugin" catalogue on the Support Portal (accessible by customer_admin): https://support.servicenow.com/now/en/pages/automation-store — navigate to All Automations > Service Catalogue > Activate Plugin. If the desired plugin is not listed, select "Plugin I'm looking for is not listed" and enter the plugin name as free text. ℹ Most Store applications are, by default, available on SUB PROD instances. The customer_admin must GET/OPT IN to these apps from the Store — regardless of entitlement — before they are installable on the instance. A licence/entitlement check is imposed for visibility within the Production environment. Installing on SUB PROD does not guarantee availability in PROD. If the application and its dependencies are installable on PROD, the instance admin can proceed — the licence/entitlement check has already been completedApplication Store Procurement — Store Application Installation ⚠ If planning a go-live for a plugin or application in PROD, ensure the application and all dependencies are visible in PROD well in advance. Even if entitled, if missing in PROD, resolution may take time as it involves multiple backend teams, contract verification, and daily data loads. ℹ The "Sync now" button in the ServiceNow Application Manager (System Applications > All Available Applications > All) manually refreshes your instance to reflect the latest apps and updates from the Store. KB0759221: Visibility of Store Applications on Instances ℹ For all licensing/subscription/entitlement questions, please contact your ServiceNow Account Representative — this falls outside the scope of Customer Support. 5. Instance Backup requests before Go live Ad-hoc backups are not possible to execute as they are an automated backend process. Furthermore, an instance ad-hoc backup does not prove beneficial in any scenario. The relevant Knowledge Base (KB) article provides detailed explanations. Backup Request for ServiceNow instance including Production More information on Backups and Retention is covered in this white paper: Delivering Performance, Scalability, and Availability on The ServiceNow Cloud 6. 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 or module implementation. We have different modules and SME teams for each functionality — a placeholder case will not be effective. Cases should be raised individually with the relevant teams for their respective issues. If issues arise during or after these activities, visit the Now Support Help Centre and raise a case. Please include: steps to reproduce, logs, and screenshots to help us begin troubleshooting immediately. ℹ ServiceNow has proactive monitoring in place for instance/infrastructure-specific resource constraints at all times. Automated alerts are created for any resource constraint events and we will engage customers on those as separate tickets. ServiceNow Monitoring — Overview and Insight Periodic manual monitoring by support engineers would risk missing events or delayed reactions due to external factors — our automated monitoring system ensures consistent, real-time response.