ONTAP upgrade: prechecks, ANDU commands and postchecks

01Record the exact starting state and choose the upgrade route

Start with the version on every node, not the version of the node that happens to answer SSH. Record hardware models, serials, HA pairs, cluster size, protocols, SnapMirror peers and special features. A mixed-version starting state requires investigation before this example can be used. The selected target must support the whole environment, including switches, host OS, HBA drivers, multipath software and backup integrations.

1. Generate and retain an Upgrade Advisor plan when available. Read release notes for both the target and relevant intermediate releases, including known issues and feature changes. Use Hardware Universe for the controller and shelves, and IMT for host and application interoperability.
2. Look up your exact current-to-target release path. A direct path stages one target image. A direct multi-hop ANDU stages the required intermediate and final images but uses the final target for validation/update. A multi-stage path completes and validates one supported upgrade before starting the next. Do not treat these routes as interchangeable.
3. For the illustrated 9.14.1 to 9.16.1 path, use the exact version string from the downloaded package repository. If the approved target is a P release, include its P suffix in every validate/update command; 9.16.1 below is only the teaching value.

cluster image show
system node show -fields model
cluster show
storage failover show

02Establish HA, cluster and storage prechecks

Nondisruptive describes a supported HA workflow, not a guarantee that every client will tolerate it. A degraded HA pair, failed storage path or host with only one usable path can turn a planned transition into a service incident. Capture this output immediately before the window as well as during preparation; compare with the known healthy baseline.

1. Investigate existing alerts and record an approved disposition for any residual warning. Do not clear an alert merely to make the output look healthy.
2. Complete or coordinate conflicting hardware work, aggregate/volume moves, controller replacement and other maintenance. Check client load and backup windows so a partner can safely carry the affected workloads.

cluster show
storage failover show
system health status show
system health alert show
storage aggregate show
storage disk show -broken
storage shelf show
storage shelf show -connectivity
volume show
snapmirror show
event log show -time >1h

03Prove NAS failover and SAN host resilience before the window

For NAS, verify eligible failover targets on ports that stay available during the node transition. For SAN, verify host paths and supported ALUA/multipath behavior rather than enabling NAS-style LIF migration. Use the actual service-policy and protocol design for your release. A reachable management LIF does not prove that an application has resilient data access.

1. Record LIF home/current node and port, administrative/operational state and intended failover group. Fix missing NAS targets or VLAN/broadcast-domain mismatches through a reviewed network change before upgrade validation.
2. On each representative SAN host, save device identity and path count. Linux examples are multipath -ll and lsblk; Windows examples are mpclaim -s -d and Get-Disk. Compare with the NetApp host configuration guide for that OS/protocol.
3. Have service owners execute a small named-user NAS transaction and an application-native SAN transaction. Retain evidence and latency/error counters. A planned resilience rehearsal should use its own approved change; do not add an unplanned takeover to this upgrade.

network interface show
network interface show -service-policy *data* -failover
network port show
network port broadcast-domain show
vserver nfs show
vserver cifs show
vserver fcp interface show
vserver iscsi session show
lun mapping show

04Preserve configuration, data recovery and key-management access

A cluster configuration backup preserves configuration; it is not a backup of user data. Verify separate application recovery points, retention and an accessible restore process. If encryption is used, verify key-manager connectivity and retain the required recovery material through the approved secure process. Never include passphrases or customer data in public notes or copied examples.

1. Create a uniquely named cluster configuration backup. Wait for the backup job and inspect the actual filename. A queued job is not proof of a usable backup.
2. Upload the completed file to an authorized backup receiver and confirm that the remote copy exists and is readable by the recovery owner. The HTTPS receiver must support the upload behavior documented for ONTAP and have the required trust configured. A simple image-download web server is not a backup upload receiver.
3. Review encryption, SnapMirror, SnapLock, active sync, application-consistent protection and other feature-specific upgrade requirements in the preparation checklist. Record the additional steps that apply to this cluster.

set -privilege advanced
system configuration backup create -node lab-01 -backup-name pre_ontap_20261009.7z -backup-type cluster
system configuration backup show -node lab-01
system configuration backup upload -node lab-01 -backup pre_ontap_20261009.7z -destination https://backup.example.net/ontap/pre_ontap_20261009.7z
set -privilege admin

05Download, check and serve the approved ONTAP image

Download through the NetApp Support Site using the approved release/build and platform selection. Retain the vendor checksum or signature verification evidence supplied with that download. A renamed file is not evidence of a different version; ONTAP reads the package metadata. The following Linux commands run on the staging host, not inside the ONTAP CLI.

1. Place the approved image under a controlled image directory. In this lab it is /srv/netapp/ontap/9.16.1/image.tgz. Keep the full filename and expected internal package version in the change record.
2. Calculate a checksum and compare it with the vendor-provided value using the same algorithm. Resolve any difference by downloading a clean copy; do not stage a suspect image.
3. Make the image available through a supported transfer endpoint reachable from the controllers. The example serves only /srv/netapp on a controlled maintenance network; replace the address and apply your access controls. Confirm the exact URL returns the image rather than a login page or HTML error.

# Linux staging host — example commands
sha256sum /srv/netapp/ontap/9.16.1/image.tgz
python3 -m http.server 8080 --bind 192.0.2.80 --directory /srv/netapp
# From another authorized machine:
curl -I http://192.0.2.80:8080/ontap/9.16.1/image.tgz

06Add the target to the cluster package repository

Use the cluster image repository for ANDU. This differs from fetching an individual firmware file into a node repository. Retain older files only according to the approved plan and available repository capacity; do not delete an image simply because a sample procedure includes cleanup. For a direct multi-hop route, stage both required packages before validating the final target.

1. Wait for transfer and package processing to finish. Check for errors and inspect the repository afterward.
2. Match the repository version exactly to the approved build. If it displays a P suffix, replace 9.16.1 in the remaining example commands with that full string.
3. If the repository lacks space, identify an obsolete package and review retention/recovery needs before using cluster image package delete -version <OBSOLETE_VERSION>. Do not delete an intermediate image required by the selected route.

cluster image package show-repository
cluster image package get -url http://192.0.2.80:8080/ontap/9.16.1/image.tgz
cluster image package show-repository

07Run validation and resolve each reported condition

1. Allow validation to finish. Collect the complete precheck output and correlate it with your manual compatibility, protocol and special-feature checks.
2. Resolve each error before proceeding. For a warning, identify its actual impact, owner and documented disposition; a generic warning that manual checks remain is not evidence that those checks were done.
3. After a corrective change, rerun validation for the same target and retain the new output. Recheck dependent client tests if the correction changed networking, identity, paths or HA behavior.

cluster image validate -version 9.16.1 -show-validation-details
cluster image show-update-progress

08Estimate the change and open the maintenance window

An estimate is planning input, not a completion deadline. Reserve time for client stabilization, firmware dependencies, a paused stage, diagnostics and postchecks. ONTAP upgrades can involve repeated node reboots and HA transitions. Agree on an escalation time that leaves enough window to investigate rather than forcing completion at the end.

1. Compare the estimate with the approved window and actual workload/resilience requirements. The four-hour notice is a dummy duration; use your approved duration and monitoring process.
2. Notify service owners, freeze conflicting work and verify support/console access. Maintenance suppression should cover planned symptoms without hiding a real client outage.
3. Repeat critical health, path and application checks immediately before starting. Stop if conditions have changed since validation.

cluster image update -version 9.16.1 -estimate-only
system node autosupport invoke -node * -type all -message "MAINT=4h"

09Start ANDU through the CLI

Review the validation and confirmation prompt before agreeing to start. ANDU manages image installation and HA transitions. Keep the console and a separate client-monitoring view available. Do not run a second upgrade session against the same cluster or manually perform takeover/giveback while ANDU owns the operation.

1. Start once with the exact approved target. Record the start time and keep session logging enabled in your terminal.
2. Monitor phase and node state. A two-node standard HA pair follows a rolling workflow; larger clusters can use batch behavior. An I/O stabilization wait is part of the process and is not automatically a hang.
3. During each transition, have the service owner monitor representative transactions and path availability. An SSH disconnect is less informative than the client service and console state.

cluster image update -version 9.16.1
cluster image show-update-progress

10System Manager alternative for the same approved upgrade

Choose one execution interface and keep its progress view authoritative. The following navigation matches the illustrated ONTAP 9.14.1 source workflow; later interfaces can use Software updates labels. The same compatibility, backup, manual prechecks and postchecks still apply.

1. Open System Manager through the cluster management address and go to Cluster > Overview. Open the actions menu and select ONTAP Update.
2. Add the approved image from the local client or the controlled server URL, or select the already staged image. Verify its displayed version against the change record.
3. Select Validate, inspect all results, and complete corrective actions before proceeding. Retain the validation record.
4. Select Next and Update when the window is authorized. Review any repeated validation warnings. Monitor the upgrade and client checks; use the displayed error details if it pauses.
5. After completion, sign in again if the management session reconnects and perform the postchecks. A returned login page alone does not prove the whole cluster upgrade succeeded.

11Handle a pause without mixing automated and manual work

Read the failed node, phase and stated action first. Distinguish a planned pause, a stabilization wait and paused-on-error. Correct the actual problem, recheck client service and then decide whether the existing workflow can safely resume. Repeatedly issuing resume does not fix a takeover veto or missing storage path.

1. For a user-requested pause, cluster image pause-update requests a pause at a supported transition point; verify the resulting state before further decisions. It is not an emergency power-off control.
2. If the approved recovery decision is to abandon ANDU and complete a supported manual procedure, use cluster image cancel-update only after recording the current node versions and state. Canceling stops orchestration; it does not reinstall the original ONTAP image.
3. An actual downgrade/revert requires the supported release-specific procedure, configuration eligibility and a reviewed recovery plan. Do not make a generic revert or force-giveback command part of routine error recovery.

cluster image show-update-progress
storage failover show
system health alert show
event log show -time >1h
set -privilege advanced
cluster image show-update-log
set -privilege admin
# Only after the identified fault is corrected and reviewed:
cluster image resume-update

12Verify software completion on every node

1. Verify the expected update phases completed and every intended node runs the approved target build. Inspect current/running image information; an old alternate image can remain in the repository without indicating a failed running upgrade.
2. Confirm both nodes are healthy/eligible and HA has returned to its expected ready state. Mixed versions may occur during an upgrade but are not this runbook’s final accepted state.
3. Compare RDB ring state across nodes and check SAN quorum where applicable. For each ring, compare its own epochs and primary/master membership; different rings need not use the same primary. Investigate rather than resetting database state.

cluster image show-update-progress
cluster image show
cluster show
storage failover show
set -privilege advanced
system node image show -version
system node upgrade-revert show
cluster ring show -unitname mgmt
cluster ring show -unitname vldb
cluster ring show -unitname vifmgr
# SAN environment only:
cluster kernel-service show
set -privilege admin

13Restore intended networking, verify storage and refresh DQP

1. Compare LIF state with the precheck record. For a NAS LIF that should return home, confirm its home port is healthy before issuing the single-LIF revert shown in the separate postcheck guide. Preserve intentionally disabled interfaces and reviewed placement exceptions.
2. Compare aggregates, volumes, shelves and disk faults with the baseline. Resolve newly introduced degradation even if client access currently succeeds.
3. Check and update DQP separately through the DQP procedure. The ONTAP software image upgrade does not itself refresh this qualification package. Verify the package on both nodes.
4. Verify protection and the first expected completed recovery point. If a transfer was deliberately quiesced, resume only the intended relationship after confirming its state and the change plan.

network interface show -fields home-node,home-port,curr-node,curr-port,is-home,status-admin,status-oper
storage aggregate show
volume show
storage disk show -broken
storage shelf show -connectivity
system health alert show
storage dqp show -instance
snapmirror show

14Accept the application and close the change with evidence

Repeat the same client and application transactions captured before the window. Confirm data integrity, authorization, SAN identity/path resilience and service performance rather than only port reachability. The linked post-upgrade checklist contains Linux and Windows examples and a sign-off matrix that can be reused for firmware and DQP changes.

1. Verify NAS read/write/delete with the intended user in a dedicated test folder, and SAN access through application-native checks without writing directly to a production block device.
2. Run backup, monitoring and automation checks through at least the first relevant operating cycle. API or authentication changes can leave an apparently healthy cluster unmonitored.
3. Record actual start/end times, target build per node, validation output, firmware/DQP changes, application acceptance and outstanding follow-up owners. Create and retain a fresh configuration backup after acceptance.

system node autosupport invoke -node * -type all -message "MAINT=END"
system node autosupport invoke -node * -type all -message "ONTAP_UPGRADE_ACCEPTED"
system health status show
system health alert show