An ITSM Upgrade-Readiness Checklist for Automations and Integrations

Most ITSM upgrades are uneventful. The ones that are not tend to fail in the same place: the custom layer. Scripts, webhooks, custom functions and integrations sit outside the vendor's test matrix, they are rarely documented, and they usually break quietly: a notification that stops firing, an approval that never routes, a nightly sync that silently returns nothing.

ManageEngine's ServiceDesk Plus On-Premises build 15300, released on July 16, 2026, is a useful worked example. It is not a dramatic release. But buried in the behavior changes are two items that will break working automations on migration, and neither of them throws an obvious error when it does. This post uses that release to lay out a checklist you can run before any ITSM upgrade, on any platform.

What actually changed in build 15300

Two behavior changes carry real risk.

Execute Script $ parameters were pruned to seven. Execute Script now supports only $COMPLETE_JSON_FILE, $COMPLETE_V3_JSON_FILE, $COMPLETE_V3_0_JSON_FILE, $HTML_DATA_JSON_FILE, $DIFF_JSON_FILE, $HANDSHAKE_KEY and $HELPDESK_ID. Support for every other $ parameter has been removed, and ManageEngine states plainly that after migration, existing scripts that reference unsupported variables will not work. If your team wrote dependency scripts, field-and-form rules or custom actions that pass individual field values as $ variables, those are the scripts at risk.

The Request History API contract was rewritten. The endpoint is now /api/v3/requests/{id}/_history. Inside the history.requests object, the title field has been renamed to subject. The history.by object returns additional partial fields. Most consequentially, the status codes changed shape: a successful retrieval that previously returned a string "200" now returns 2000. An empty history, which used to return an error-style message, is now a success with code 2000. Unauthorized access returns 4002, internal errors return 4004, and a non-existent request returns 4007 with an "Invalid URL" message.

That second change is the dangerous one. Any integration that branches on the old status codes, or that reads title out of the history payload, will not crash. It will just start behaving incorrectly. A reporting job that treated empty history as an error will now treat it as data.

A third change worth flagging

Build 15300 also altered filter behavior in release, asset, CMDB, user and technician reports: the is not and not contains operators now return records with null values alongside genuine matches. If you have scheduled reports or API-based report pulls that use exclusion filters to drive downstream automation (license reclamation, offboarding sweeps, compliance evidence), the row counts will change and no error will be raised.

Add to that the Select2 component upgrade. Legacy Select2 v3.5.1 has been removed and all components now run on version 4. Any page script or custom UI logic that manipulates picklist widgets directly against the v3 API is a candidate for breakage.

Step 1: Build the inventory before you build the plan

You cannot regression-test what you have not enumerated. Before an upgrade window is even scheduled, produce a single list covering every automation artifact: business rules, custom triggers, field-and-form rules, page scripts, custom functions, workflows, timer actions, webhooks, scheduled reports that feed other systems, and every external system holding an API key against the instance.

For each entry, record three things: what it does in business terms, who owns it, and what breaks downstream if it silently stops. Most organizations discover during this exercise that a meaningful share of their automations have no current owner, the person who wrote them has moved on. That finding is itself the most valuable output of the step.

Step 2: Grep the custom layer against the release notes

With the inventory in hand, read the behavior-changes section of the release notes as a search list rather than a narrative. For 15300, that means searching every script body for $ parameters and flagging anything outside the supported seven. It means searching your integration codebase for the string history alongside title, and for any hardcoded comparison against the old status values.

Do this against source control, not the admin UI. If your scripts do not live in source control, that is the gap to close before the next release, not this one.

Step 3: Re-test API consumers against the new contract, not the old assumption

For every external consumer (ETL jobs, monitoring tools, in-house portals, Power BI models, MSP tooling), write down the exact fields and status codes it depends on. Then exercise it against the new build in a staging instance and compare payloads field by field.

Pay particular attention to the paths that are supposed to be quiet. Unauthorized access, missing records and empty result sets are exactly the branches that never get tested and exactly the branches 15300 changed. A consumer that handles the happy path correctly can still corrupt data on the error path.

Step 4: Verify authentication and access paths

Build 15300 adds two-factor authentication support to Request Custom Menu actions. That is a security improvement, and it also changes the interaction model for any custom menu action that a technician or an automated process invokes. Confirm which actions now prompt, and confirm that nothing headless is calling a path that has become interactive.

Similarly, the release adds scheduled LDAP user import notifications with per-entry failure reasons, and extends AD and Entra ID import failure notifications with CSV attachments explaining each failed entry. These are genuinely useful. But if you built your own monitoring around import silence, no news is good news, you now have a new notification stream to route somewhere a human reads.

Step 5: Stage it, and read the operational fine print

Upgrade in a staging environment that mirrors production database, edition and integration set. Then read the fixed-issues list for operational traps as carefully as you read the behavior changes. Build 15300 fixes a case where upgrades to 15270 and later fail if MSSQL driver JAR changes were applied to a run.bat file locked by another process, the kind of detail that turns a two-hour window into a two-day one.

Also note the framework moves: Log4j2 goes from 2.25.3 to 2.25.4 and the bundled PostgreSQL from 15.17 to 15.18. If your security team tracks component versions independently, give them the delta before they find it.

Step 6: Write down what the upgrade cost

After cutover, record the hours spent, split between the vendor's product and your custom layer. Track it release over release.

This is the number most IT organizations never capture, and it is the number that matters. A single upgrade absorbing a few days of engineering time is unremarkable. The same few days, several times a year, across scripts nobody wants to own, is a standing tax on the team, and it is paid out of the same budget that is supposed to fund improving the service.

The condensed checklist

1. Inventory every automation artifact, with a named owner and a stated downstream impact.
2. Search the custom layer for every deprecated parameter, field name and status code in the release notes.
3. Test API consumers against error and empty paths, not just success paths.
4. Confirm authentication changes do not sit in front of headless processes.
5. Stage against a production-equivalent instance and read fixed-issues for upgrade blockers.
6. Record the true cost, and compare it release over release.

The structural question underneath the checklist

Running this checklist well is good engineering. But it is worth asking why the checklist has to be this long.

Heavily customized on-premises ITSM accumulates a private layer of scripts that exists to make the platform behave the way the process actually works. That layer is the organization's real operating knowledge, and it is also the thing the vendor cannot test for you. Every release, you pay to re-verify it.

An AI-first approach changes the shape of that liability. Rezolve.ai's Sidekick resolves employee requests conversationally in Teams, Slack, email and voice, grounded and cited, rather than through brittle field-level scripting, roughly 70% of requests are resolved before they become tickets. Where automation is genuinely needed, Agent Studio lets teams build governed agents in plain language, with approval gating and audit trails, instead of $ variables that a point release can retire. DeskIQ reads ticket history and ranks what is worth automating next, so the custom layer that does exist is the layer that earns its maintenance.

None of that removes the need for upgrade discipline. It does change what you are defending during an upgrade window: business logic that is explicit, governed and owned, rather than an archaeology project.

See how an AI-first system of record handles this →