Why change windows need validation, not just approval
Change management processes exist to reduce risk. A ticket is raised, peers review the plan, a maintenance window is scheduled, and the change is executed. On paper, the network is protected. In practice, approval alone does not confirm that a change was implemented correctly — or that it did not introduce unintended side effects.
Pre-change validation establishes the starting state. Post-change validation confirms the outcome matches intent. Together, they transform change management from a paperwork exercise into a technical control that catches errors before they become outages.
Organizations that skip validation rely on engineer experience and luck. Organizations that automate validation catch misconfigurations, policy violations, and incomplete rollouts while engineers are still in the maintenance window — when rollback is still practical.
Pre-change validation: know your starting point
Before any production change, capture and validate the current device state. This baseline becomes the reference for post-change comparison and rollback if something goes wrong.
- Capture a fresh configuration backup immediately before the change window opens — not from yesterday's scheduled backup
- Run a compliance scan against current policies to document the pre-change posture and identify existing violations that should not be blamed on the change
- Compare the device against its peer group or golden baseline to confirm it is in an expected state before modification
- Verify that rollback configurations are accessible and tested — not buried in an engineer's local directory
- Confirm the change ticket references the specific devices, commands, and expected outcomes
- Check for unsaved running-to-startup configuration differences that could complicate rollback on reboot
Executing the change with validation in mind
During the change window, structure execution so validation is possible at each step. Monolithic changes that modify dozens of settings at once are harder to validate and harder to roll back than incremental changes with checkpoints.
For complex changes, use a staged approach: apply a subset of modifications, validate, then proceed. On platforms that support commit confirmed workflows — such as Juniper Junos — leverage built-in rollback timers. On others, maintain your own checkpoint backups between stages.
Document actual commands executed, not just the planned commands. Discrepancies between plan and execution are a common source of post-change surprises during audit or incident review.
Post-change validation: confirm intent, detect damage
After the change is applied, validation answers three questions: did the intended configuration take effect, did anything unintended change, and does the device still meet compliance and security policies?
Configuration diff is the foundation. Compare the post-change configuration against the pre-change backup. The diff should match the approved change scope — nothing more, nothing less. Unexpected additions or removals warrant immediate investigation before the maintenance window closes.
Functional validation goes beyond configuration syntax. Can routing neighbors still establish sessions? Are critical services reachable? Do ACLs permit expected traffic and deny the rest? Automated policy checks catch security regressions — such as accidentally opened management interfaces or removed logging — that configuration diffs alone might miss.
Peer comparison adds another layer. If the changed device is part of a group, compare its post-change configuration against peers that were not modified. Systemic differences may indicate an error in the change script or template.
Rollback readiness and failure handling
Validation is only valuable if teams act on failures. Define clear criteria for rollback before the change window: which post-change results trigger immediate revert, who has authority to call rollback, and what the rollback procedure is per platform.
Rollback should restore the pre-change backup, re-run post-change validation against the restored state, and confirm the device matches the pre-change baseline. A rollback that is not validated is an assumption.
When rollback is not possible — for example, during irreversible software upgrades — pre-change validation and staged execution become even more critical. In these cases, extend validation to include lab reproduction before production execution.
Integrating validation with change management
Validation works best when embedded in the change management workflow, not treated as an optional extra step. Integrate configuration management and compliance platforms with your ITSM or change ticketing system so validation results attach automatically to change records.
Pre-change scan results become audit evidence that the device was healthy before modification. Post-change scan results demonstrate the change was implemented correctly. Compliance deltas show whether security posture improved, remained stable, or regressed.
For recurring change types — VLAN provisioning, ACL updates, firmware upgrades — build validation templates that run automatically. Engineers should not recreate validation checklists for every maintenance window.
Platforms like Orion support automated pre-change and post-change validation across multi-vendor estates — capturing backups, running compliance scans, producing diffs, and generating audit-ready reports that attach directly to your change management process.