Scenario
This runbook is a change checklist. Use the exact NetApp upgrade procedure for your source and target release, hardware, MetroCluster status, and protocol environment.
Before you change production
Commands and screens can differ by release and platform. Replace example names and documentation IP addresses. Check prerequisites, impact, current health and rollback with your change owner.
1. Before the window
- Confirm supported upgrade path, release notes, interoperability for host/switch/software, firmware dependencies and maintenance requirements.
- Validate cluster health, HA, storage capacity, snapshots, SnapMirror, AutoSupport, client multipath and a tested recovery plan. Collect a baseline of affected application checks.
Read-only prechecks
cluster show
storage failover show
system health alert show
storage aggregate show
volume show
snapmirror show2. Execute according to release guide
- Notify stakeholders and freeze conflicting changes. Follow System Manager or CLI upgrade steps for the exact release; keep console and support access.
- Watch node health, HA, client access, EMS and protection after each stage. Pause if a precondition changes or client I/O is impacted beyond the plan.
Verify
Each stage completed with expected node and client status.
3. Post-upgrade acceptance
- Confirm ONTAP versions across nodes, HA ready, all expected LIFs and volumes, SAN paths, NFS/SMB access, SnapMirror transfers and application transactions.
- Review new alerts for at least one monitoring cycle. Capture final state and document deviations or rollback decision.
Verify
Application owner accepts service; protection and monitoring restored.
If validation fails
- If a precheck reports degraded HA, insufficient space, a failed SnapMirror relationship or host path issue, resolve it before starting the upgrade.
- If a node fails to return during the window, preserve console and EMS output, follow the release-specific recovery procedure and engage support.
- If applications pass initial checks but errors appear later, compare new alerts and workload latency through at least the next monitoring cycle.
Verify
Re-run the original validation and record the observed result, exact error, time, and corrective action.