Protecting ServiceNow Platform Performance During a Migration

Establishing Performance Baselines and Identifying Bottlenecks

Before optimising platform performance, establish baseline metrics: how long do key operations take (form load, list query, report generation), what is CPU and memory utilisation during peak load, which components consume the most resources? ServiceNow provides diagnostic tools (slow query, slow script and slow transaction logs, transaction and session debugging, and the slow-pattern views in Application Insights) to identify bottlenecks. Conduct a performance baseline assessment: run key workflows and measure response times, identify which operations are slow, rank bottlenecks by frequency and impact.

Common performance issues include inefficient queries (retrieving unnecessary data, missing indexes), heavy client-side scripting (loading large scripts on every page load), integration latency (waiting for external systems to respond), and report execution on large datasets. Identifying which category affects your instance most helps prioritise optimisation efforts. Database performance issues require different solutions (indexing, query tuning) than script performance issues (code optimisation, caching).

Query Optimisation and Index Strategy

Queries against large tables (incidents, requests, changes with years of data) can be slow if not optimised. ServiceNow’s slow query logs identify queries taking longer than expected. Review slow queries and optimise them: add indexes on frequently-searched columns, reduce data retrieved (use display value fields more than raw references), break large queries into smaller ones. Index strategy impacts performance significantly—correct indexes speed queries dramatically; incorrect or missing indexes slow them down. Database performance tuning requires expertise and careful validation to avoid creating performance regressions.

Scripting and Processing Optimisation

Client-side scripts (client scripts, UI policies and UI scripts) executed on every form load impact user experience. Optimise scripts: reduce script size, cache data, defer loading non-critical scripts. Server-side scripts (business rules, script includes, notifications) can slow down critical operations if inefficient. Review scripts for expensive operations (looping over large result sets, calling external APIs synchronously). Converting synchronous operations to asynchronous (asynchronous business rules, scheduled jobs or event-driven processing) often improves perceived performance without reducing throughput.

Data Archival Strategy

Large tables accumulate historical data that slows queries. Archival (moving old data to storage outside active tables) reduces table size and speeds queries. Define archival policy: incident records older than one year, closed requests older than two years. Archival process requires planning (how often, which data, automated or manual) and testing to ensure archived data remains accessible if needed for reporting or auditing. Some organisations maintain searchable archives; others move data to storage and accept that it’s harder to retrieve.

Integration and External System Performance Impact

If ServiceNow integrates with slow external systems, integration latency appears as ServiceNow slowness to users. If an integration call takes 10 seconds and is made on form load, the form is slow. Identify integrations impacting user experience and optimise them: cache integration results, move calls from synchronous to asynchronous, use MID Servers for remote system calls. Sometimes external system performance is the problem, not ServiceNow—work with the external system owner to improve their performance.

Monitoring and Continuous Optimisation Approach

Performance optimisation isn’t one-time work; it’s ongoing. Implement monitoring to track performance metrics over time: watch for performance degradation as data volumes grow. Establish performance targets for key operations and alert when performance falls below targets. Use monitoring data to prioritise future optimisation efforts. Regular performance reviews (quarterly or biannual) help identify trends and emerging bottlenecks before they impact users.

Client-Side Performance and Browser Considerations

User experience isn’t determined solely by server performance. Browser rendering speed, network latency, and device capabilities affect perceived performance. Use browser developer tools to profile page load and rendering. Keep portal pages and custom widgets light: avoid large images, limit the scripts a widget loads and defer anything a user does not need when the page first opens. Consider user device capabilities: older devices or devices on slow networks need more optimisation than high-end devices on fast networks. Progressive enhancement ensures basic functionality works everywhere, with enhanced experience on capable devices.

Capacity Planning and Scalability Considerations

As your organisation grows and ServiceNow data volumes increase, performance may degrade unless you plan for scalability. Watch the transaction and semaphore statistics the platform exposes, the growth of the largest tables and the run time of scheduled jobs, and raise instance sizing with ServiceNow before those signals reach critical levels. Some optimisations (indexing, query tuning) help prevent growth-related performance issues; others require a conversation with ServiceNow about instance capacity. Plan for regular capacity reviews to ensure infrastructure keeps pace with business growth.

Deciding what the move must not slow down

A migration project usually has a date, a cutover plan and a list of data sets, and the performance question gets attention only after users report that the new environment is slower than the old one. The better order is to name the few operations that the business cannot afford to lose during the move, then plan the cutover around them. Typical candidates are the dispatch view that opens every morning, the approval queue that gates other work, and the integration that feeds an external system on a fixed schedule. Write each one down with the time it must complete and who depends on it.

A cutover order that keeps the old baseline usable

The old environment is your reference. Once it is switched off, the team loses the ability to compare timings honestly, so capture the baseline before the first load begins. The steps below keep the comparison possible.

1. Record timings for the agreed critical views in the old environment across the working days and times they matter most, using the measures set out in the KPI guide.
2. Load configuration and reference data first, then active records, then history. Confirm each stage before the next starts.
3. Rebuild or verify indexes and refresh statistics after the large loads, not during them.
4. Run the critical views in the new environment with the same users and browsers used for the baseline.
5. Switch scheduled jobs on one at a time, starting with the lightest, and watch the window each one uses.
6. Keep the old environment readable for an agreed period so a disputed timing can be repeated.

Signs the new environment is not ready to take the load

Watch for a gap that appears only at specific times. A view that matches the old timing in the morning but slows at the hour when the imported data is processed often has a job conflict rather than a sizing problem. Another sign is a list that loads quickly for a small test group and slowly for the full user base, which often means the access rules or sorting were tested on too little data. Treat either pattern as a reason to hold the cutover for that group, not as a reason to add capacity immediately.

When a migration should not try to fix performance

A migration is a poor time to redesign slow processes. If you change the data model, the integrations and the reports in the same window, you will not know which change caused a new delay. Move the platform first, measure it, and schedule the redesign as a separate piece of work with its own baseline. The exception is a change that the move cannot happen without, such as a retired integration that cannot be re-created as it was.

Keeping the first weeks honest

The first few weeks after cutover often generate the most complaints, and many of them are about habit rather than speed. Users look for records in the old places and wait for screens they used to open quickly. Keep the timing method from the baseline and repeat it weekly. If the numbers match the old environment and the complaints continue, the issue is often navigation or training, which sits outside the technical scope of a move. That problem is covered on the user adoption and training page.

A migration that touches reports and dashboards as well as the core platform needs the reporting migration considerations, which is worth reading alongside, because the reports and the data they read are moved in the same window.

Should history be migrated at all?

Only as much as people actually search. Many teams migrate a rolling window of closed records and keep older history in a read-only store. The decision depends on audit requirements and on how often users need older records, and both should be confirmed with the business owner before the load plan is set.

Can the old schedule run alongside the new one for a while?

Only for jobs that are idempotent or that write to separate targets. For anything that writes to a shared record or sends a message, run one copy only and use the parallel period to compare outputs, not to double the work.

Why does a report look different after the move?

Often because a field was mapped differently, a filter was not carried across, or history was archived and the report still points at the active table. Compare the row counts and totals for a fixed date range in both environments before accepting the output.

How long should the old environment stay available?

Long enough to resolve a disputed timing or data question, which often means through one full reporting cycle. Set the end date in the cutover plan, not after the first complaint.