ServiceNow is a powerful platform, but like any complex system, it requires regular maintenance and optimization to support good performance and a smooth user experience. Oblytech’s Performance Tuning & Upgrades services proactively address potential bottlenecks, fine-tune configurations, and implement upgrades to help keep your ServiceNow instance performing well.
We conduct a comprehensive assessment of your ServiceNow instance to identify areas for improvement, bottlenecks, and potential performance issues.
We fine-tune your ServiceNow configurations, workflows, and scripts to enhance performance and efficiency.
We optimize your ServiceNow database structure, indexes, and queries to improve data retrieval and processing speed.
We meticulously plan and execute ServiceNow upgrades, aiming for a smooth transition to the latest version with limited disruption to your operations.
We evaluate your ServiceNow plugins and integrations to identify any performance issues and implement optimizations.
We set up ongoing performance monitoring and provide regular reports to track performance trends and identify potential issues early on.
When an instance feels slow and an upgrade has been postponed twice, the two problems are usually treated as separate projects. They are often the same project seen from different sides. A slow form can be caused by a customization that the upgrade will also have to examine, and an upgrade that has been put off can leave performance problems in place for another cycle. Performance tuning and upgrade work belong together when the customization load is the cause of both. They should be split when the slowness comes from a separable source such as a single integration or a reporting job, and the upgrade is limited by something else entirely.
This page is written for the people who make that decision: the platform owner who must justify the time, and the service leader who has to tell users when the slowness will stop. It explains how the work is typically separated, what evidence should exist before anyone commits to a fix, and where the work carries risk that a fixed plan will not show.
Users describe slowness in terms of the screen they were on, not the cause. That is why a useful performance review starts by matching the reported symptom to the part of the platform that usually produces it. The table gives the common pairings. It is a starting hypothesis, and each row should be tested against the instance before any change is made.
| What users report | Area that usually produces it | What to check first | Typical risk of a rushed fix |
|---|---|---|---|
| Lists and forms take long to open, but only for large tables | Table size, missing indexes, or queries that scan rows unnecessarily | Which queries are slow and whether the affected table has grown well past its original design | Adding indexes that slow writes elsewhere |
| A form is slow on save but fast to open | Business rules, client scripts or access checks that run on submit | The order and cost of rules that fire on that table | Disabling a rule that enforces a control |
| Everything slows at the same times of day | Scheduled jobs, large imports or reporting that overlaps with peak use | The schedule of background work and its run times | Moving work to a time that clashes with a different team |
| Integrated processes lag or fail to complete | Integration queues, retries or a slow external system | Queue depth, error patterns and the responding system’s own performance | Blaming the platform for a slow partner system |
| Pages load but the interface feels heavy | Client-side scripts, large numbers of UI policies, or heavy list layouts | Page weight and the number of scripts that run on load | Removing a UI behavior that users rely on |
An upgrade moves the platform to a newer release, and the effort it takes is driven mostly by what sits on top of the standard product. An instance that uses standard functions with few changes can usually upgrade with a predictable test effort. An instance with heavy customization needs time to find out which changes conflict with the new release, decide which of them to keep, and retest the processes they support. The more the business depends on custom behavior, the more of that time the upgrade will take.
Before you schedule an upgrade, the honest question is whether the instance is in a condition to be tested. Test cycles fail for predictable reasons: data that does not reflect production, environments that differ from each other, or customizations nobody can explain. A readiness view that names those gaps is worth more than an upgrade calendar. The platform performance and upgrade readiness page frames a review that connects customizations, integrations, data, workflows, rollback and evidence, and the automated testing and release assurance page covers which workflows should be protected by repeatable tests and what evidence a result provides.
A tuning engagement that produces only a list of recommendations has not finished its job. The useful output is a short set of findings tied to evidence, each with an estimate of the work it needs, a view of who must agree to it, and a note of what would change if it were not done. Findings should be ordered by the user experience they affect, not by how interesting they are to a developer.
Ask whether the provider will hand over the measurement method as well as the results. A baseline that only the consultants know how to reproduce is of limited use once the next release arrives, and your own team should be able to repeat the comparison after the engagement closes.
Performance work is often sold as low risk because it looks like tuning. In practice, several common fixes change behavior that someone depends on. Turning off a rule removes a control. Changing a query can alter which records a list shows. Moving a scheduled job can break a report another team relies on. Every fix should be checked against the process it touches, and the person who owns that process should sign off on any change to its behavior.
The upgrade itself carries its own risk, mostly in the period after go-live. Issues that did not appear in testing often surface when real volumes and real integrations meet the new release. A sensible plan keeps the previous state recoverable for long enough to find those problems, and names who makes the call to roll back if they appear.
Usually you should understand the performance problems first, because an upgrade can hide them for a while and then make them harder to diagnose. The exception is a release that fixes a known defect the business is suffering from, in which case the upgrade may be the tuning.
A proper review separates the platform’s response time from the time spent on the user’s side of the connection. If the platform responds quickly and the page still feels slow, the cause is probably on the client side, and the fix is different.
Much diagnostic work can be done live, and many fixes can be deployed through the normal change route. Work that changes the database structure or moves large volumes of data is usually scheduled for a quieter window.
Ask for the measured effect on a named slow process, the list of other processes that depend on the same code, and the test that will confirm the fix did not break them.
Bring three things to the first conversation: the symptoms your users describe, the date by which the next upgrade is needed or already planned, and a rough sense of how much custom behavior your team knows how to explain. The first two tell a provider where the pressure is. The third tells it how much time the upgrade will need in the testing phase. The effort is settled once someone has looked at the instance properly, and any figure given before that point is a guess.
To see the other consulting routes, return to the ServiceNow consulting overview. If the slowness has not yet been traced to a cause, the health checks and audits route may be the better first step. When you are ready to talk through a specific instance, discuss your performance and upgrade plan with the team.
To improve ServiceNow performance, pick one transaction that users find slow, reproduce it with a named user on a named record, and trace where the time goes before you change anything. Teams that skip this step tend to fix the component they suspect rather than the one that is slow, and the instance feels no different afterwards.
Start with a single record. A list that is slow for one department but fine for others usually points to a filter, a shared view or a role-based rule. A form that is slow only when one field is set usually points to a script or a reference lookup that runs on that condition. Write down the user’s role, the table, the record number and the steps, so the same test can be repeated after the change.
The checks behind each step are covered in our platform performance guides. In most implementations, the first two weeks follow this order:
The common failure is to cut business rules on a busy table to save time. That removes checks someone depends on, and the slowdown often returns once the control is put back. Keep the behaviour, change how the rule reads data, and move expensive work off the save path where the process allows it. Before a change reaches production, check the affected paths against our release readiness guide, because upgrade testing tends to cover the same paths.
Guides from the Oblytech ServiceNow library that explain the practice behind this page.