ONTAP release upgrade guide: 9.16.1 through 9.19.1

Choose the upgrade path

Older releases can require direct multi-hop or multi-stage upgrades. Never infer a path from version numbers: consult the current NetApp upgrade-path table.

Upgrade decision workflow

1. Inventory cluster models, ONTAP patches, licenses, protocols, replication relationships, hosts and switches.
2. Confirm target support in Hardware Universe and the Interoperability Matrix.
3. Resolve Upgrade Advisor and automated pre-check errors; record warnings and explicit acceptances.
4. Test takeover/giveback, LIF failover, multipathing, replication and application recovery.
5. Schedule one supported hop at a time, with rollback criteria and support contacts written down.

Pre-flight commands

version -v
system node show -fields model,serialnumber,health,uptime
cluster show
storage failover show
system health alert show
cluster image show
cluster peer health show
snapmirror show -fields status,healthy,lag-time

Use the documented image-validation workflow for the exact target image. Command availability and output can vary by source release and privilege level.

Execution and validation

Use the rolling upgrade runbook for execution and rollback, and upgrade troubleshooting for stalled validation, takeover/giveback and post-upgrade symptoms. The 9.19.1 hub owns release-specific behavior changes.

Fixed issues and known issues

NetApp publishes the authoritative per-release fixed issues and known issues — including limitations and upgrade cautions — in the ONTAP 9 Release Notes. That document is gated behind a NetApp account, so there is no anonymous per-release fixed-issue list to mirror; the open ONTAP 9 release highlights index points to it explicitly.

Two open checks still surface the issues that actually apply to your cluster before you commit:

• Upgrade Advisor — validates the target release against your exact cluster, model and current patch, and flags the relevant issues rather than the full list.
• Automated pre-upgrade checks — in 9.19.1 these separate errors from warnings. Errors block the upgrade and must be resolved; warnings can be explicitly accepted and recorded so the decision is auditable.

Work them in that order: run the pre-checks, clear every error, then read the account-gated cautions for the exact target patch. A green pre-check is a filter, not a substitute for the release notes.

What 9.19.1 changes for existing clusters

These are the behavioral changes most likely to matter on a cluster that is already in production, taken from the official 9.19.1 release notes:

• ARP/AI with synchronous replication. ARP/AI now protects active read-write primary volumes in supported SnapMirror synchronous and active-sync relationships, but ARP snapshots are not replicated to the destination. Where ARP/AI default enablement had been suppressed by synchronous replication, 9.19.1 can restore it automatically — expect a pre-update warning and confirm the intended state.
• SnapMirror active sync for NAS. Adds SVM-level NFS and SMB protection on supported 2-node AFF and 4-node AFX configurations; read-write access stays primary-only.
• NFS over TLS 1.3. Opt-in in-transit encryption for NFS, with optional mutual TLS and export-policy enforcement. Existing NFS clients are unaffected unless you turn it on.
• Small-directory listing. Automatically assigns more CPU to highly concurrent listing of small NAS directories (about 2 MB or 25,000 files). No configuration and no admin action required.
• QoS ceiling behavior. The defaults that control temporary automatic QoS throughput-ceiling increases become configurable — review them if you tune QoS floors and ceilings by hand.
• S3 object access. Conditional writes and deletes, plus a second access key per S3 user (lets you rotate keys without interrupting a client), become available once the target patch is applied.
• Direct-attached FC hosts. Supported AFF, ASA and FAS adapter ports can attach FC and FC-NVMe hosts without switches — validate adapters, optics and cabling against the Interoperability Matrix first.

Confirm per-patch behavior in the 9.19.1 release hub and the what’s-new write-up, and cross-check the routes in the upgrade-paths reference.