Manual branch turn?ups on Software?Defined Wide Area Network controllers; Meraki/vManage APIs made cutovers predictable

Overview

A national retailer’s branch turn?ups required many manual steps across WAN and SD?WAN vendors. Engineers copied old configs, logged into controllers and firewalls, and verified circuits by hand. Mislabeling or missed steps led to rework and site visits. Intelligex templated WAN and SD?WAN configurations in Git, automated provisioning through vendor APIs, and validated connectivity with synthetic tests during approved change windows. Rollouts became predictable, on?site work dropped, and configuration drift receded—while the retailer kept its existing SD?WAN platforms, firewalls, circuits, and ITSM change process.

Client Profile

• Industry: Retail (multi?brand, multi?region)
• Company size (range): Central network engineering with regional field services and a managed service provider for some sites
• Stage: Mixed SD?WAN platforms across regions; firewalls from multiple vendors; manual change tickets and CLI/App?GUI workflows; inconsistent branch runbooks
• Department owner: IT & Infrastructure (Network Engineering and Platform)
• Other stakeholders: Store Operations, Security, Field Services, Managed Service Provider (MSP), Service Desk/NOC, Change Management, Procurement, Internal Audit

The Challenge

Branch activation was a relay of spreadsheets, screenshots, and vendor GUIs. Engineers copied configuration snippets from the last similar store and adjusted IP plans, VLANs, QoS, and routing by hand. SD?WAN controller changes and firewall rules were applied directly, and verification consisted of ping tests and a quick application check. Mistyped site codes or missing policy objects caused rollbacks and late?night calls with carriers and field techs.

Each region evolved its own playbook. Some used one SD?WAN platform, others another; firewalls and switching varied by store format; and Wi?Fi and POS networks required specific segmentation. Handoffs between procurement, field services, and networking were informal, so device claim steps, SIM activations, and controller templates weren’t applied consistently. When a store cut over, the NOC watched for alerts rather than following a standardized pre/post checklist.

Change reviews struggled to see risk. CAB approvals relied on narratives, and there was no artifact showing the exact route and policy intent heading to devices. Post?change, cleanup of temporary objects and legacy ACLs depended on who did the work. The result was longer lead times, unpredictable cutovers, and rework when small mistakes slipped through.

Why It Was Happening

Network intent lived in people’s heads and old configs. Without a single source of truth and templates, engineers copied and edited past examples per platform. Vendor APIs existed, but automation was ad hoc and script?based, so it didn’t survive platform changes. Validation focused on symptoms rather than on user journeys, and success criteria varied by engineer and region.

Ownership and timing were fragmented. Procurement ordered circuits, the MSP staged devices, Network applied policies, and Field Services turned up stores. With no unified pipeline tying site metadata, configuration intent, approvals, and synthetic validation together, each turn?up became a bespoke project.

The Solution

Intelligex introduced a Git?backed, API?driven branch turn?up pipeline with templated configurations, automated provisioning, and synthetic validation under change windows. Site intent (addressing, roles, segments, QoS, and policies) lived in a source?of?truth model; CI/CD rendered vendor?specific templates; SD?WAN and firewall changes applied through controller and management APIs; and pre/post?change synthetic tests verified reachability and key application paths. The design used a source of truth such as NetBox for site data (NetBox), vendor APIs including Cisco Meraki Dashboard (Meraki API) and Cisco SD?WAN vManage (vManage API), infrastructure?as?code tools, and synthetic monitoring like ThousandEyes.

• Integrations: Source of truth for sites, IP plans, and device inventory; Git repos for templates and policy modules; CI/CD (for example, GitHub Actions or GitLab CI); SD?WAN controller and firewall manager APIs; ITSM change records and approvals; synthetic test platform for pre/post checks; NOC dashboards.
• Template library: Vendor?specific templates for SD?WAN policies, VPNs, QoS, VLANs, ACLs, wireless SSIDs, and branch routing; shared naming and tagging conventions; parameterized by site role and format.
• Provisioning workflows: Device claim and inventory sync; push of site templates to SD?WAN controllers and firewall managers; staged policy attach with dry?run or preview where supported; idempotent re?apply for drift correction.
• Validation and health: Synthetic tests for DNS, HTTP(S), POS gateways, voice, and critical SaaS; performance baselines; automated roll?forward or rollback recommendation based on results; annotated change records.
• Change control: CAB approvals tied to rendered plans and diffs; maker?checker for high?risk policies; scheduled windows per region; rollback manifests generated with prior intent.
• Observability and logs: Job logs, API responses, and test results pushed to the SIEM/observability stack; dashboards for rollout status, failures by step, and policy drift.
• Security and guardrails: Least?privilege API credentials; secrets stored in the vault; pre?flight checks for overlapping subnets and reserved addresses; exception workflows for non?standard stores.

Implementation

• Discovery: Cataloged SD?WAN platforms, firewall managers, and site formats; reviewed current runbooks and naming conventions; mapped device claim steps and MSP handoffs; inventoried circuits and carrier lead?time data; gathered CAB expectations and audit requirements.
• Design: Defined the source?of?truth schema (site, role, IP plan, segments, QoS class, WAN links); authored template structure and variable maps per platform; selected provisioning steps per vendor API; designed synthetic test suites per store format; planned CI/CD stages, approvals, and dashboards.
• Build: Populated the source of truth and cleaned site metadata; created templates for SD?WAN policies, routing, and security; implemented CI/CD to render and apply via controller APIs; integrated ITSM for change creation, gates, and evidence; configured ThousandEyes (or equivalent) tests and baselines; enabled logging and drift detection.
• Testing/QA: Ran in shadow mode to render configs and preview controller changes without applying; piloted automated turn?up on a lab site and a low?risk store with field services on standby; validated synthetic tests against known good stores; tuned templates and guardrails based on findings.
• Rollout: Enabled automated provisioning for new stores first; migrated select refreshes and policy updates into the pipeline; scheduled regional waves aligned to carrier windows; retained manual apply as a controlled fallback during early cycles; tightened policy gates after stable results.
• Training/hand?off: Delivered sessions for Network, NOC, Field Services, and the MSP on request inputs, approvals, reading rendered diffs, and interpreting validation results; published store?format playbooks; updated SOPs for cutover, rollback, and exception handling; transferred template ownership and dashboards to Network Engineering under change control.
• Human?in?the?loop review: Established weekly reviews of failed validations, template updates, and exception stores; recorded decisions with rationale and effective dates; improvements fed back into templates, tests, and guardrails.

Results

Branch turn?ups shifted from manual steps to a repeatable pipeline. Site metadata drove template rendering, controllers applied policies through APIs, and synthetic tests verified that POS, voice, and SaaS paths behaved as expected during the window. When validation flagged an issue, rollback steps were clear and fast because prior intent was versioned in Git.

Rollouts stabilized across regions. Engineers and MSPs followed the same approvals and evidence pattern, NOC and Change Management saw the same rendered plans and test results, and post?cutover cleanup removed temporary objects consistently. Site visits dropped to cases that truly required hands?on work, and misconfigurations were caught before they reached customers.

What Changed for the Team

• Before: Branch configs were copied and edited by hand. After: Templates rendered from a source of truth and applied through controller APIs.
• Before: Verification meant a quick ping and hope. After: Synthetic tests checked DNS, HTTP(S), POS, voice, and SaaS paths during the window.
• Before: CAB reviewed narratives. After: Approvals tied to rendered diffs, plans, and rollback manifests.
• Before: Rollbacks were improvised. After: Prior intent and rollback steps were versioned and executed predictably.
• Before: Each region had a different playbook. After: Shared templates and guardrails applied across SD?WAN and firewall platforms.
• Before: Field techs were dispatched for config fixes. After: Most issues were resolved in the pipeline before a truck rolled.

Key Takeaways

• Put site intent in one place; a source of truth drives consistent templates and reduces drift.
• Automate via controllers; use SD?WAN and firewall APIs rather than per?device CLI work.
• Validate user journeys, not just reachability; synthetic tests catch issues that pings miss.
• Tie changes to artifacts; CAB decisions move faster with rendered plans and rollback manifests.
• Run in shadow first; preview configs and tests before applying at scale.
• Integrate, don’t replace; keep current platforms and ITSM—add a Git?backed pipeline and validation layer.

FAQ

What tools did this integrate with? Site metadata and inventory lived in a source of truth such as NetBox. Templates and policies were stored in Git and rendered/applied via CI/CD. SD?WAN and firewall changes used vendor APIs, including the Cisco Meraki Dashboard API and Cisco SD?WAN vManage API where applicable. Synthetic validation used platforms like ThousandEyes. Approvals and evidence flowed through the existing ITSM.

How did you handle quality control and governance? Templates, variables, and guardrails lived in version control with owners and rationale. CI enforced linting and pre?flight checks (overlapping subnets, reserved ranges, naming). CAB approvals required rendered diffs and rollback manifests. All apply jobs, API responses, and test results were logged and linked to change records, and exceptions followed a maker?checker path.

How did you roll this out without disruption? The pipeline ran in shadow mode first, rendering configs and previewing controller changes without applying. A lab site and a low?risk store piloted automated apply with field services on standby. Regions onboarded in waves aligned to carrier windows, and manual apply remained a controlled fallback until the process proved stable.

How were multiple vendors and store formats handled? The template library abstracted shared patterns and exposed vendor?specific options only where needed. Site roles and formats parameterized VLANs, SSIDs, QoS, and policies. Each vendor controller had a provisioning workflow tuned to its API, but approvals, evidence, and validation remained consistent across platforms.

What did synthetic validation cover? Tests verified key user journeys: DNS resolution, HTTP(S) to corporate and SaaS endpoints, POS gateway reachability, voice registration, and latency/jitter thresholds. Baselines were stored per store format, and results were attached to the change record. Failures triggered rollback recommendations and diagnostics for quick remediation.

How did you prevent configuration drift? Controllers were treated as the source of enforcement, and Git as the source of intent. Periodic drift checks compared controller state to rendered intent and opened tasks when differences appeared. Re?apply jobs were idempotent, and emergency changes made outside the pipeline required follow?up merges under change control.

What about MSP and field service coordination? The pipeline produced a pre?cutover checklist for device claim and staging, and a post?cutover report with synthetic results. MSPs received access to read dashboards and change artifacts, and exceptions (for non?standard stores) followed a documented approval path.