ServiceNow version upgrades are usually done by first upgrading a sub prod instance with a clone from prod. After the upgrade completes, the skipped changes to review entries are reviewed by the unlucky admin that is chosen for the task. Fortunately, the said unlucky admin only has to do this once as these changes can be captured in an update set and applied to prod. However, one point of confusion (for me anyway) is how this update set works — the sys_id’s of the records in the Upgrade Details table (sys_upgrade_history_log) in sub prod are different from the sys_id’s from records in the same table in prod.
Usually, update sets use the sys_id to find the right record in the target instance, however in the case of the sys_upgrade_history_log table, it uses the file_name field. Here’s a payload:
<?xml version="1.0" encoding="UTF-8"?>
<record_update table="sys_upgrade_history_log"><sys_upgrade_history_log action="INSERT_OR_UPDATE"><sys_scope>global</sys_scope><incoming_version_payload_hash>sha256:20c3ab845be8713f6409404a5a5f9a881cba6533be01b285f3658c2e4200ad00</incoming_version_payload_hash><file_name>sys_properties_bd50ae03c723201033ccfa49f4c2601f</file_name><disposition>10</disposition><resolution_status>reviewed_retained</resolution_status><type_priority>5</type_priority><comments></comments></sys_upgrade_history_log></record_update>As you can see, there isn’t any sys_id field, although a sys_id is included in the file_name.