Switch VLAN and Port Change

Front-load the safety work for a VLAN or port change: identify exactly which port on which
switch, establish what else breaks, book a window, and make sure a known-good config is
saved BEFORE anything changes. Hand the spec to the implementing tech; this skill never
configures a switch.

1. Pin down the physical target — which switch, which port, which site — from the
   documentation (IT Glue / Hudu) switch records and port maps. With no port map, the
   first deliverable is "identify and label the port on site"; never guess a port number
   from memory or convention.

2. Blast radius, in widening circles: (a) what is on the port now — one desktop, or a
   downstream unmanaged switch feeding a whole room; (b) is it an uplink or trunk, since
   trunk changes affect every VLAN riding it; (c) what else shares the VLAN being modified
   (phones, APs, cameras, servers); (d) is spanning-tree or the management VLAN involved —
   a wrong change there severs remote access to the switch. Where a Liongard inspector
   covers the switch platform, read its change history (apply the Inspector Read
   Discipline base skill — confirm the inspector exists and last ran successfully, and
   date any config data you cite).

3. Classify risk: a single access port with one endpoint is low and can be done in
   business hours with the user's consent. Trunk, uplink, management VLAN, or anything
   feeding multiple users needs an after-hours window, with someone reachable on site in
   case remote access is lost.

4. Rollback FIRST, non-negotiable: the spec must require saving the running configuration
   (backup or export) before the change, and must state the rollback action — "restore
   saved config", or the explicit reverse commands. A change request with no captured
   pre-change config is not ready.

5. Assemble the change spec: target switch and port, current state, desired state,
   blast-radius findings, window, rollback plan, verification steps (endpoint gets the
   expected VLAN and DHCP scope, no new spanning-tree events, management access still up).
   Leave it as a note (apply the PSA Note Discipline base skill — plain text, no markdown
   or emojis) and route it for approval if the client's change process requires one.

6. Schedule a follow-up ticket for the agreed window, assigned to the implementing tech,
   carrying a verification note before it closes.

Guardrails: no trunk, uplink, or management-VLAN change without an after-hours window and
a captured pre-change config — decline to mark the spec ready otherwise. When in doubt,
widen the blast radius — an unmanaged switch hiding behind a port is common, so treat a
port whose downstream you cannot confirm as multi-user. Never put switch credentials or
SNMP strings in the ticket; reference documentation by name. If switch documentation does
not exist, say so and make documenting it part of the change.