Upgrade History module: Track every upgrade

  • Release version: Xanadu
  • Updated August 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 provides administrators with a comprehensive log of every upgrade performed on an instance. It is essential for tracking upgrade processes, resolving upgrade conflicts, and managing customizations effectively. By using this module, administrators can ensure smooth upgrades while preserving or reverting customizations as needed.

    Show full answer Show less

    Key Features

    • Upgrade History Records: Each upgrade generates a record that includes details such as the versions involved, start and finish times, and the number of changes applied, skipped, or processed.
    • Skipped Changes Management: The upgrade process automatically skips applying updates to customized objects to protect user changes. The module lists these skipped records for review, allowing administrators to merge customizations or revert to the base system.
    • Detailed Breakdown of Changes: The module categorizes upgrade details by disposition and change status, including updated, skipped, different, or unchanged records, helping administrators understand the impact of each upgrade.
    • Review and Resolution Tools: Skipped records are organized into “Skipped Changes to Review” and “Skipped Changes Reviewed” lists to track which records need action and which have been resolved.
    • Additional Related Lists: Lists such as Customizations Unchanged, Changes Applied, Claim Outcomes to Review, and Upgrade Details provide granular insights into upgrade actions and outcomes.
    • Debug Upgrade Support: The module supports a Debug Upgrade feature that helps diagnose errors by producing detailed debugging output for affected transactions during the latest upgrade.

    Practical Use for ServiceNow Customers

    Administrators should regularly review the Upgrade History module after upgrades to:

    • Identify any skipped changes caused by customizations and decide whether to merge or revert those customizations to maintain system integrity and access new features.
    • Track the progress and success of upgrades, including timing and the number of changes applied, ensuring compliance with upgrade policies.
    • Use the audit trail to troubleshoot upgrade errors efficiently with the Debug Upgrade feature.
    • Maintain control over customized objects and prevent unintentional overwrites during upgrades by systematically reviewing and resolving skipped records.

    By leveraging the Upgrade History module, ServiceNow customers can optimize upgrade processes, safeguard customizations, and confidently implement new platform enhancements.

    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.