Standard Operating Procedure (SOP)

SD-WAN (Velocloud) Firmware Upgrade Process

Document Owner: Head of Technical Operations
 Date: 1 October 2025
Version: 1.0

Date: 23 February 2026
Version: 2.0

1. Purpose

To define a structured, timeline-driven process for upgrading Velocloud SD-WAN firmware while ensuring platform stability, vendor alignment, security compliance, and client satisfaction, and to minimize risk by adopting only fully mature Long-Term Support (LTS) releases.

2. Definitions

Term

Definition

Long-Term Support (LTS)
  • Vendor-recommended production release line, supported for ~3 years and receiving periodic Maintenance Releases (MRs).

Short-Term Support (STS)
  • One-year support track. Not adopted unless mandated by critical vendor security advisories and approved by CAB.

Maintenance Release (MR)
  • Incremental update within an LTS branch (e.g., x.y.z.1, x.y.z.2).

Maturity Threshold (“.2 Rule”)
  • Production rollout will only proceed when firmware has reached Maintenance Release .2 or later (e.g., 7.0.0.2).
  • Lab validation of .0 may occur, but production deployment shall not proceed before .1 is available, and broad rollout requires .2 or later.

Pilot Deployment
  • Controlled implementation within internal lab and limited low-risk client environments prior to estate-wide rollout.

Tier Classification
  • Tier 1: Broader client base excluding high-priority clients. (more than 30 sites)
  • Tier 2: Low/medium impact clients. (1-30 sites)
  • Tier 3 – Internal (Coevolve Lab)

 

3. Roles & Responsibilities

Role

Responsibilities

Engineering (EE)
  • Vendor release monitoring, lab testing, pilot execution, maturity assessment, final recommendation.
  • Client communications, approvals, and scheduling.
  • EE to review release notes on monthly basis/monthly cadence with engineering team

CRC
  • Execute firmware upgrades under approved Change Requests
  • Real-time monitoring during upgrade window
  • Trigger rollback if objective thresholds are met

Account Managers / TC/CX
  • Client communications, approvals, and scheduling. (assist with client escalation if required)

Clients
  • Validate critical applications for post-upgrade, provide business approval.

CAB
  • Reviews risk assessment, approves schedule, escalation and rollback plans.

 

 

 

 

4. Timeline & Process Workflow

4.1 Firmware Release Lifecycle

Within 90 days of a new LTS release publication:

  • Engineering performs structured evaluation
  • Initial lab validation begins
  • Impact summary presented to CAB

If adoption is deferred, justification must be documented and approved by CAB.

Each edge must always remain:

• On a supported LTS branch
  • With at least 12 months of remaining vendor support
  • No more than one LTS generation behind the current recommended release

 

Phase

Trigger

Key Activities

Phase 1 – LTS Initial Release (.0)

Vendor publishes new LTS (.0)
  • Release notes review 
  • Security advisory / CVE assessment 
  • Hardware compatibility validation 
  • Bug fix and feature delta analysis 
  • Initial impact assessment documented

Phase 2 – Early Maintenance Release (.1)

Maintenance Release .1 available
  • Release note validation 
  • Deploy to Coevolve “CRC Lab” only
  • Feature regression testing 
  • Stability monitoring (tunnels, CPU, routing, control plane) 
  • Risk log created and maintained
  •  Bi-Weekly Update during “weekly TC call”

Phase 3 – Maturity Gate (.2)

Maintenance Release .2 available AND listed as “Recommended”
  • Upgrade all Tier 3 environments to .2 
  • 14-day stability validation 
  • Validate all pilot risk items resolved or mitigated

Phase 4 – Production Rollout (Tier 2)

CAB Approval Post-.2 Validation
  • Tier 2 (Low/Medium Impact) deployment 
  • 7–14-days observation window 
  • Incident delta monitoring

Phase 5 – Production Rollout (Tier 1)

Successful Tier 2 stabilization (at last 80% of Tier 2 clients complete)
  • Tier 1 (High Impact) deployment 
  • 7–14-days observation window 
  • Incident delta monitoring

Phase 6– Estate Stabilization & Closure

Production rollout substantially completed
  • 30-day stability validation
  • Upgrade Register updated
  • Lessons learned captured

 

4.2 Upgrade Criteria (Decision Gates)

Upgrades proceed only if all the following are true:

  • Firmware is LTS
    1. Listed as “Recommended” in Arista SD-WAN support portal
    2. Minimum Maintenance Release .2 or later
  • Current production version within 12–18-months lifecycle window
  • No unresolved high-severity defects identified in pilot

STS releases are only permitted if explicitly required by a critical security patch and approved by CAB.

4.3 Upgrade Frequency

Given that each LTS release is supported for approximately three (3) years (36 months), the following cadence will be applied to balance stability, security, and operational overhead:

Item

Best-Practice Guidance

Major LTS Adoption
  • Every 12-18 months.
  • End-of-Support Trigger
    1. Upgrade no later than six (6) months before vendor EOS.

 

Security-Driven Upgrades
  • Immediate action if no configuration mitigation is available.

Deferral Policy

CRC may defer adoption up to 12 months if:
  • No material security risk
  • No performance degradation
  • EOS > 18 months away

Deferral must be documented.

 

5. Execution Framework

Pre-Upgrade

  • Backup orchestrator configuration.
  • Confirm rollback image availability in orchestrator.
  • Submit CR to CAB with risk/impact matrix.

Upgrade Window

  • Execute during maintenance hours (regional or client-specific).
  • CRC monitors real-time logs (tunnel stability, event logs, CPU/memory).
  • Escalate anomalies immediately to Engineering.

Post-Upgrade Validation

  • Verify tunnels and routing policies.
  • Perform application testing (voice, key client applications etc).
  • Maintain 24-hour enhanced monitoring window with defined escalation thresholds.

Rollback Criteria

  • Core features non-operational (business policy, routing, management plane etc).
  • Major client application failures.
  • Rollback executed within 2 hours of trigger.

6. Reporting & Governance

  • Firmware Upgrade Register: Tracks client firmware versions, upgrade dates, and rollback events.
  • Monthly Updates in TC Call: Ongoing status reporting during rollout.
  • Post Implementation Review: Conducted after each major cycle to capture lessons learned.
  • Vendor Release Watch List: Engineering maintains a live tracker of vendor release statuses (preview, recommended, deprecated) to drive upgrade timing.
  • Release Monitoring: EE to manually check the Arista Support Portal at the start of each month for newly published firmware images and updated recommended release lists. Findings are documented and shared during the monthly engineering review.

Key Policy Summary

  • Only LTS firmware is approved for client production.
  • Minimum version maturity: .2 or later (two or more maintenance releases).
  • STS releases are prohibited except in critical security circumstances with CAB approval.