ServiceNow’s automated workflow solutions help organizations across industries to revolutionize their operations tremendously. ServiceNow proves to be an end-to-end means to digital transformation driving both – cost reduction and business growth. Hence, organizations are implementing ServiceNow to increase their automation effort, operational efficiency, and speed-to-market.
However, in the process of using ServiceNow, organizations make some customizations to their ServiceNow platform to meet ever-changing business requirements. And these customizations may give rise to a series of platform issues over the years. To overcome this challenge, reverting an over-customized ServiceNow platform to its out-of-the-box (OOTB) state (default settings or in-built functionality state) may become essential. But how do organizations achieve this without disrupting their current processes and operations?
This article throws light on why organizations should get back to OOTB from their customized ServiceNow platform and how they can make the reversal smooth.
Avoiding Customizations and Sticking to OOTB Standards – The Why
Whenever organizations go with modifying features of their business platform, they should strive to stick to the “configuration” (using ServiceNow’s inbuilt capabilities to alter features) rather than “customization” (writing code and modifying the platform’s base code to add or change features).
Customizations can often invite complexities and problems like:
- Poor platform performance, stability, and scalability
- More time to upgrade the platform during periodical ServiceNow releases (deprives organizations of access to ServiceNow’s technical support)
- Increased platform maintenance time and cost
- Bad user experience
- Difficulty in accessing the latest ServiceNow features, which subsequently invites the need to customize functionalities
While over customization does not necessarily mean lower quality, it can cause scalability issues. Hence, ServiceNow has been suggesting to not to over customize and continue with out of the box where possible. Many organizations now seem to be listening to this call. In a 2021 ServiceNow Development Report by Quality Clouds, it was inferred that out of the 127 instances that were analyzed, 17% were customized, and 83% were configured, against the ratio of 29:71 in 2020. It clearly shows a downward trend.
If there is no choice but to customize, one of the best practices is to utilize scoped applications–applications limited to a specific scope that allows undertaking customizations without changing out of the box elements with code, affecting the original system/platform. Besides, to get a positive outcome from the customizations, a structured approach and an expert team are essential.
Benefits of Moving Back to OOTB
Execute ServiceNow upgrades faster
Improve platform performance and stability
Deliver exceptional platform user experience
Reduce platform maintenance time and cost drastically
Get access to the latest ServiceNow features easily
Reverting an Over-customized Platform to OOTB Instance – The How
Going back to OOTB functionality needs expertise, without which it would take a lot of time and effort. Having said that, here is a 3-step framework that organizations can follow to revert their customized ServiceNow platform to the OOTB state the right way:
Step 1 – Identifying the Level of Platform Deviation
The first step in restoring a highly customized ServiceNow platform to its OOTB state is to conduct a complete assessment of the platform and understand how much deviation from OOTB functionality has taken place. The skipped records (overly customized ServiceNow features) that are automatically identified by the “ServiceNow Upgrade Center” application while upgrading the ServiceNow platform can give an idea about the level of deviation from OOTB functionalities. Organizations can also understand the deviation through a manual code review process.
Step 2 – Setting Up a New Instance and Migrating Data & User Groups
Post the assessment and identification of the degree of platform deviation, the next step is reversion. If a particular module has been customized, it can be difficult to revert that module alone to its OOTB state since there’s no inbuilt ServiceNow functionality to do so.
Therefore, organizations can set up a new ServiceNow instance with OOTB scope (which may require spending money) and duplicate their current instance. They can then leverage a bi-directional replicator to sync the required data and the user groups between the current duplicated platform and the new OOTB instance. This helps make sure that the organization’s current operations are not disrupted while the new OOTB instance is being set up.
Step 3: Decommissioning the Old Instance and Implementing Platform Maintenance Processes
Once the replication of data and user groups in the new ServiceNow instance is done, the old and customized instance can be scrapped, and the new OOTB ServiceNow instance can be implemented. Subsequently, organizations should set up continuous maintenance and management processes to ensure the proper functioning of their ServiceNow platform. They should follow best practices such as using scoped applications, documenting customizations, using ServiceNow’s HealthScan, etc., in case there are future requirements for platform customizations.
Taking Expert Guidance
While customizing the ServiceNow platform provides the capability to meet short-term business requirements, the long-term problems can be numerous. Therefore, reverting the ServiceNow platform to OOTB functionality and ensuring careful customization in the future can help maintain platform stability.
Moreover, whether organizations want to customize the platform or move back to OOTB, both these tasks should be undertaken by ServiceNow-certified experts. If there is a shortage of in-house experts, employing ServiceNow partners and Managed Service Providers (MSPs) like KANINI is the way forward. We help organizations ensure smooth platform customization and transition to OOTB. Contact our ServiceNow experts to learn more.
Author
Ravi Rajamani
Ravi is the ServiceNow Practice Lead at KANINI. He brings close to 18 years of experience in the IT industry and has strong program & project management skills spanning ServiceNow, Resource Management, Solution Design, and Service Delivery. He has a proven track record of helping enterprise customers leverage ServiceNow platform efficiently.
