Upgrade History module: Track every upgrade

  • Release version: Washingtondc
  • Updated February 1, 2024
  • 2 minutes to read
    • Summarize
    Summarized using AI
    This content was generated using new OpenAI-powered functionality. Results are provided on an as is basis and are not guaranteed to be accurate or complete.

    Summary of Upgrade History module: Track every upgrade

    The Upgrade History module in ServiceNow is essential for tracking every upgrade made to an instance. It aids administrators in resolving upgrade conflicts and allows for the reversion of customizations to base system versions, facilitating access to new features. Each upgrade generates a record that can be viewed underSystem Diagnostics > Upgrade History.

    Show full answer Show less

    Key Features

    • Upgrade Records: Each upgrade creates an upgrade history record containing details such as the previous and current .war file versions, timestamps for start and finish, and counts of changes skipped and applied.
    • Skipped Changes Review: The Skipped Changes to Review related list helps track records that were skipped during the upgrade, allowing administrators to understand and resolve customization conflicts.
    • Claim Outcomes: Administrators can review and resolve claim outcomes related to system upgrades via the Claim Status tab.

    Key Outcomes

    By utilizing the Upgrade History module, ServiceNow administrators can effectively manage upgrades, ensuring that customizations do not interfere with system updates. This leads to smoother upgrade processes, minimized conflicts, and enhanced system functionality as new features become available.

    The Upgrade History module tracks every upgrade made to an instance. Administrators can use the module to resolve upgrade conflicts and optionally to revert customizations to base system versions to take advantage of new features.

    An upgrade history record is created for each upgrade that is run. To view an upgrade history record, navigate to System Diagnostics > Upgrade History and click the upgrade.
    Note:
    Debug Upgrade provides detailed debugging output for transactions containing artifacts affected by the most recent upgrade, and is designed to assist in upgrade error resolution. See Debug upgrade.
    Note:
    The Payload and Payload Hash fields have been removed from the Upgrade History record in a previous release.
    Table 1. Upgrade History record
    Field Description
    From Name of the previous .war file (version).
    To Name of the applied .war file (version).
    Upgrade started Time stamp when the upgrade process began.
    Upgrade finished Time stamp when the upgrade process was completed.
    Changes skipped Total number of records that were different from the previous upgrade but were skipped, mostly likely due to customization.

    Changes skipped is the sum of the records that have disposition of skipped manual merge (where the value of changed is true), added to the number of records that have disposition of skipped error, added to the number of records that were skipped and different.

    Note:
    To prevent your customizations from being overwritten during system upgrades, the upgrade process skips (does not apply the update to) objects that have been customized. One of your responsibilities as the administrator is to resolve each update that was skipped due to a customization. To resolve a skipped update, you review the reason for each skipped record and then either merge the customization or revert the customization to the base system.
    Changes applied Total number of the changes that were applied in this upgrade.

    Changes applied is sum of updated and different records, added to the number of deleted records (where the value of changed is true) added to the number of inserted records (where the value of changed is true).
    Changes processed Total number of items processed during this upgrade. Changes processed is the sum of Changes skipped, plus Changes applied.
    Table 2. Upgrade History Details form section
    Field Description
    Updated and different

    Number of Upgrade Detail records for which the value of the disposition is updated, and the value of changed is equal to true.

    This does not appear on the form by default.
    Updated and not different

    Number of Upgrade Detail records for which the value of the disposition is updated, and the value of changed is equal to false.

    This does not appear on the form by default.
    Skipped and different Number of Upgrade Detail records for which the value of the disposition is skipped, and the value of changed is equal to true.

    This does not appear on the form by default.
    Skipped and not different Number of Upgrade Detail records for which the value of the disposition is skipped, and the value of changed is equal to false.

    This does not appear on the form by default.

    Review Skipped Records form section

    The Skipped Changes to Review related list displays each record that was skipped during the upgrade process. Use the list to review the reason for each skipped record in the list and then either merge your customization or revert your customization to the base system.