Supported ONTAP upgrade paths: direct, multi-hop & mixed-version rules

Direct-upgrade rules

An ONTAP upgrade is a rolling operation: nodes update one at a time while each node's HA partner serves its data. The upgrade runbook covers the mechanics. The rule that decides which releases you may jump in one pass is version-pair specific:

• Only the next few releases are direct-upgrade targets. In-repo guidance is explicit: 9.14.1 → 9.15.1 is a supported direct path, while jumping several releases usually requires an intermediate stop. The same reasoning applies across the 9.16.1–9.19.1 era — a multi-release jump is not a single direct upgrade unless the pair is documented as supported.
• Check the pair, not the train. Support can differ per exact release and per platform. The gates are Hardware Universe, the NetApp Interoperability Matrix, Active IQ Upgrade Advisor, and the release notes for both your current and target versions — including "required intermediate hops" where listed.
• Patch releases are part of the path. Feature releases such as 9.19.1 establish capabilities, but production planning must also select a supported P-release and confirm the upgrade path at that exact patch level.
• Downgrades are a different, narrower rule. ONTAP supports downgrading only to a release at or above the version the cluster was running when last initialized or upgraded — you cannot go back before the release the cluster was born on. Configuration created by the newer version may not survive the trip down.

Where this site's content is silent on a specific version pair, state the rule conservatively and check NetApp's upgrade documentation for your exact source and target releases.

When you must multi-hop

You need an intermediate release when your current version is too old to upgrade directly to your target. Common triggers:

• You skipped trains. If your cluster sat on 9.16.1 while the world moved to 9.19.1, the direct jump may exceed the supported window — plan one or more intermediate stops instead.
• Hardware forces a floor. New platforms list a minimum ONTAP train (for example, 9.16.1 is the minimum train for AFF A20/A30/A50 and AFF C30/C60/C80 class systems; 9.17.1 for AFX 1K; 9.19.1 for AFX 2K). A controller refresh onto a platform with a higher floor can force an ONTAP upgrade before or during the swap.
• An ARL path names its gate. Several documented controller-replacement (ARL) paths require a specific train — see controller upgrades below.

Multi-hop is just several single upgrades run in sequence: pick the intermediate release, run the full rolling upgrade runbook, verify, then repeat for the next hop. Never skip the intermediate validation because the destination is "just an intermediate" — each hop is a full production upgrade with its own release notes and known issues.

Multi-hop procedure

Each hop follows the same cluster image cycle used for any ONTAP 9 upgrade. The commands below are the canonical sequence (also in the upgrade runbook):

# 0. Plan: record current full version on every node
version -v
cluster image show -fields node,package,version,state,is-current

# 1. Stage the target package from a source the cluster can reach (HTTP server or node path)
cluster image get -package http://192.0.2.10/ontap/<target>_image.tgz

# 2. Validate BEFORE updating — checks prerequisites and reports concrete issues
cluster image validate -node node1 -package <target>_image.tgz

# 3. Update one node first as a canary, then the rest
cluster image update -node node1 -package <target>_image.tgz
cluster image show-update-progress
cluster image update -nodes node2,node3,node4 -package <target>_image.tgz

Per node, ONTAP runs pre-validation, triggers automatic HA takeover (the partner serves the node's data), installs the image and reboots, gives storage and LIFs back, then moves to the next node. Keep the previous image staged until the new release has run for a few days — it is your fastest rollback asset.

For a multi-hop campaign, after the final node reports is-current: true on the hop target and post-upgrade verification passes, start the next hop with the next target package.

Version-path table: 9.14.1 to 9.19.1

Mixed-version clusters during rolling upgrades

• Mixed versions are normal mid-upgrade. While each HA pair cycles through takeover, image install, and giveback, updated nodes run the new release and nodes still waiting run the old one. ONTAP is engineered to operate in this mixed-version compatibility mode during an active upgrade.
• Mixed versions are not a resting state. In-repo guidance is blunt: mixed-version clusters are supported only as a transient state. Some features and commands behave differently per node, and automated tools assume a uniform version. Drive the upgrade to completion — cluster image show -fields is-current reveals stragglers; get every node onto the same release promptly.
• If a node fails to boot the target image: do not panic — ONTAP's automatic rollback reverts the node to the previous image within the revert window and reboots it, returning the cluster to a consistent state on its own. Check the backup boot image with system node image show -node <node-name> and watch cluster image show-update-progress.
• Clean rollback is a command, not a scramble: if you must cancel before all nodes are updated, run cluster image cancel-update — ONTAP guides reversing updated nodes back to the previous stable release.
• Plan for LIF and client behavior: during takeover, ONTAP migrates data LIFs to the surviving partner's ports; SAN hosts need active multipath (MPIO/ALUA) paths to both nodes, and NFSv4.x/SMB sessions simply reconnect after each node reboot.

Pre-upgrade checklist

Run these before staging anything on any hop. Fix anything red — ONTAP's own validation refuses to start an upgrade against a degraded cluster, and forcing one turns a rolling upgrade into an outage.

# Cluster is whole and quorate
cluster show
cluster ring show

# Exact current version, HA pairs fully healthy (partial takeover blocks a clean upgrade)
version -v
storage failover show
storage failover show-interconnect

# No failed disks, no reconstructing/degraded aggregates, no active health alerts
storage disk show -state failed
storage disk show -reconstruction
storage aggregate show -state degraded
system health alert show

# Every LIF on its home port — a LIF that cannot failover takes its SVM's clients down
network interface show -is-home false
network interface show -fields home-node,current-node,is-home

• Take a configuration backup and store it off-cluster — cheapest insurance there is: system configuration backup create -node node1 -backup-name pre-upgrade-<version>.
• Check root-aggregate space for the image (~2–4 GB per node, df -h) and confirm NTP/time is sane — drift breaks certificate checks and validation in confusing ways.
• Read the target release notes and known issues, and check security.netapp.com for advisories affecting the version you are moving to or from.
• Schedule heavy SnapMirror transfers away from the window; transfers pause during each node reboot and resume after, but don't start new ones mid-window.
• Book the window anyway. A healthy HA pair makes the upgrade nondisruptive to data, but each node reboot costs a few seconds of I/O pause, path failover for SAN clients, and session reconnects for NAS clients.

Common upgrade failures & recovery

Controller upgrades (ARL) are their own path

Moving data to new controllers is a separate class of upgrade with its own rules. NetApp's ARL (aggregate relocation) selector maps supported controller replacements to minimum ONTAP levels — and some of those levels sit inside the 9.16.1–9.19.1 era:

• 9.18.1 gates documented ARL paths including A70→A90, A30→A50, A20→A30/A50, C30→C60, and FAS70→FAS90.
• Older systems can have hard version ceilings, so a controller refresh may require a carefully staged ONTAP upgrade rather than a direct swap.
• The supported procedure depends on source model, destination model, MetroCluster status, and ONTAP version; treat Hardware Universe and the selector as gates, not suggestions.

Start from NetApp's ARL upgrade documentation before planning any controller move. The platform context for the trains in this guide lives in the release guide.

Sources and boundaries

This synthesis is built from this site's upgrade runbook, release guide, upgrade troubleshooting runbook, and gathered NetApp documentation summaries. It is community guidance, not a NetApp support statement: for any real upgrade, confirm the exact source→target pair in the official ONTAP upgrade documentation, run Upgrade Advisor, and check Hardware Universe and the Interoperability Matrix for your platform.