Upgrade duration might be significantly increased by fix script fix_clean_SLA executed as part of the upgrade process.
Release or Environment
On Kingston + instances
The fix script fix_clean_SLA cleans up the [task_sla] table for the definitions on [sn_vul_vulnerable_item] table, since [sn_vul_vulnerable_item] is no longer extending [task] (starting from Kingston).
It can become a major contributor to the upgrade duration when [task_sla] has a large amount of records, it has to delete all the records as they use the SLA definition for [sn_vul_vulnerable_item] table.
This is a one time fix script, also for future executions [task_sla] won't have [sn_vul_vulnerable_item] definitions any longer.
Script execution duration depends on number of records on [task_sla] table and number of records in scope of clean up.
Refer to Vulnerability Response product enhancements and updates in the Kingston release for further information: https://docs.servicenow.com/bundle/kingston-release-notes/page/release-notes/security-operations/secops-vuln-resp-rn.html
To workaround this issue, the recommendation is to run the fix script fix_clean_SLA (code below) before upgrade. It is safe as long as the instance is on Kingston or newer release.
var sla = new GlideRecord("task_sla");
//clean SLA Definition
var sla_de = new GlideRecord("contract_sla");
You can create a fix script with the above and choose to run in the background so that it will be run by the progress workers.
Since these records are residual records that are no longer needed, we do not need to enable rollback for these records.
We strongly recommend to test the script on a sub-production instance that is a fresh clone of the production instance and validate the results before considering applying the solution in production. This will also tell how long the script will run so that you can better schedule its execution in production.