Server teams adopted automation years ago. Network teams have been slower, for a defensible reason: a bad change on a server affects a server, and a bad change on the core affects everything, including your ability to log in and fix it.
That fear is rational. The response to it is not to avoid automation, it is to sequence it so that the first year carries no risk.
Phase one: collect
Write automation that only reads. Connect to every device, pull the running configuration, gather facts: version, model, serial, uptime, interface state, neighbours.
Commit the configurations to a repository, on a schedule.
This produces, within a week:
A complete, current inventory. Including the devices nobody remembered.
A configuration history. Every change, diffed, dated, attributable. Most network teams have never had this and it changes incident review immediately. “What changed on Tuesday” becomes a question with an answer.
A compliance report. Which devices have the wrong NTP servers, an old SNMP community, a missing ACL, a firmware version with a known advisory. You are not fixing these yet, you are counting them.
Nothing here can break anything, which means it does not need a change board, which means it can start on Monday.
Phase two: validate
Now write automation that checks intent. Are all the uplinks up? Does every access port have the expected configuration? Is the routing table what it should be? Do the neighbour relationships match the design?
Run it on a schedule and after every manual change. You now have a network that reports its own correctness, and you have built the thing you will need in phase three: a way to tell whether a change worked.
Phase three: push, narrowly
Only now, and start with the most boring possible change. An SNMP community. A syslog destination. A banner.
Push it to one device, then to a few, then to a class. Use the validation from phase two to confirm nothing moved. Build up.
The key discipline: never push something you cannot validate afterwards, and never push to everything at once. Batch size is the safety mechanism and the tooling supports it directly.
What makes network devices different
Configuration is one blob. Unlike a server where files are independent, a device configuration is a single interdependent document. Changing one line can affect another section.
There is no undo on a broken change to your own path. If you misconfigure the management interface, you have lost the device. Use commit-confirm where the platform supports it: the change reverts automatically unless you confirm within a timeout. This feature exists precisely for this and it is underused.
Out-of-band access is your seatbelt. If you are automating at any scale, console server access to everything is not optional. Check it works before you need it, not after.
The place it pays off hardest
Not the core. The edge: hundreds of access switches with configurations that have drifted for a decade, where a human doing it consistently is impossible and a machine doing it is trivial.
Also: audits. An auditor asking whether a control is applied everywhere is a week of work by hand and a single command once you have phase one.
The realistic timeline
Phase one in a month. Phase two over a quarter. Phase three cautiously after that, and it may take a year before the team is comfortable pushing to the core.
That is fine. The value from phases one and two alone — configuration history, drift visibility, inventory — justifies the effort before you change a single line on a device.