How would you bring an existing, hand-built network under automation?
Show the answer
Say this first
Read-only first: back up every config, build the inventory and source of truth from what exists, parse configs into data. Then take control one section at a time, starting with low-risk global config such as NTP, syslog, SNMP and banners. For each section I write the template, render it for every device and diff against the live config until the diff is empty or every remaining line is an agreed fix. Only then is that section enforced by automation and closed to CLI changes. Over months the coverage grows to the whole config.
Go deeper
Phases
- Discover: inventory, backups, NAPALM getters or
gatheredfrom resource modules, LLDP for topology. - Populate the source of truth: import devices, interfaces, IPs and VLANs into NetBox. Clean the data as you go; this is where you find the duplicates and mysteries.
- Standardize: agree a standard per section, and accept that some devices must change to meet it.
- Template per section: render, diff, adjust the template or the data until the diff is understood.
- Enforce: push, then let drift checks protect the section.
- Expand: interfaces, VLANs, routing, ACLs, and finally full-config replace where the platform supports it.
Why sections and not whole configs
A whole-config replace on day one means every inconsistency in the estate becomes a change at once. Per section, each step is small, reviewable and reversible, and the team learns the tools on low-risk config.
They will ask next
How do you handle the 5 percent of devices that are snowflakes?
Capture the exception in data (a host variable or config context) so the template stays the same and the difference is explicit. If it cannot be expressed as data, leave that section on the device unmanaged and document it until the device is replaced.
Traps
- Starting with a full-config replace on production devices.