VLAN Migration Planner

Introduction:

A VLAN cutover is rarely just a new number on a switch port. The change can move printers, cameras, phones, wireless access points, office workstations, and uplinks into different broadcast domains, and each affected device may depend on DHCP, access control lists, monitoring labels, voice settings, or wireless controller mappings that must already be ready.

Virtual LANs separate Ethernet traffic inside a switching domain. An access port normally places one endpoint into one VLAN, while an 802.1Q trunk can carry many VLANs across a link by tagging frames. Native VLAN handling adds a special case: untagged traffic on a trunk is associated with the configured native VLAN, so both ends of the link must agree or the trunk can behave unpredictably.

Good migration planning keeps the maintenance window honest. A long list of ports is easier to review when it is split into small waves, with validation pauses after each wave and extra time for critical endpoints or trunks. That pattern reduces the number of devices touched before the team has evidence that DHCP, ARP, MAC learning, application checks, and spanning-tree state still look right.

Two planning mistakes cause many VLAN cutovers to run long. The first is treating all ports as equal even though a trunk, access point, or critical application port needs more checking than a normal workstation. The second is counting command time but not validation time. A migration may be fast to type and still unsafe if the team does not pause long enough to prove that the new VLAN is usable and that the old path can be restored if needed.

A VLAN migration worksheet is a planning aid, not a live switch audit. It can expose missing values, risky VLAN choices, window pressure, and unclear rollback conditions, but it cannot confirm that the VLAN exists on every switch, that the DHCP scope is active, or that a peer trunk already allows the right VLANs.

How to Use This Tool:

Start with the approved change window and the ports in scope, then use the result tables to decide which rows are ready for a runbook and which need owner review.

1. Set Window length to the approved minutes for each named window. Then set Ports per wave, Base change time, and Validation per wave to match how your team stages and checks switchport changes.
2. Enter the Expected native VLAN before pasting trunk or uplink rows. A native VLAN of 1, or a planned VLAN list that includes the expected native VLAN, will create review pressure for trunk work.
3. Paste Port migration rows in the visible column order: port, endpoint, old VLANs, new VLANs, window, role, criticality, and note. VLAN cells can use separators and compact ranges such as 120-124.
4. Use Load sample as a format reference only. Use Normalize CSV after rough pasting when blank window, role, or criticality cells should be filled with default values for easier review.
5. Open Advanced when the change has critical applications, trunk pruning policy, VLAN 1 exceptions, or a rollback rule that must be carried into the checklist.
6. Fix anything listed under Check migration inputs before treating the output as final. Missing endpoint names, invalid VLAN tokens, matching old and new VLAN lists, and unapproved VLAN 1 use all require attention.
7. Read Readiness Brief first, then use Port Wave Plan, VLAN Change Matrix, Validation Checklist, and Window Load Map to review sequencing, repeated VLAN movements, owner actions, and the busiest window.

Interpreting Results:

Readiness Brief is the approval summary. It checks row count, window fit, VLAN ID use, native VLAN posture, trunk scope, and rollback wording. Treat it as the first stop during change review because it collects the items most likely to block approval.

Port Wave Plan is the execution order. A row can have a timing estimate even when it is marked for review, so do not let the minute count imply approval. The row status should be clean, and the wave should fit inside the named window, before it becomes part of the active runbook.

The main false-positive result is a clean worksheet for a network that has not been checked. The planning output can say the row is ready while the live environment is still missing an SVI, DHCP scope, allowed VLAN, native VLAN match, firewall rule, or application owner signoff.

Technical Details:

IEEE 802.1Q tagging uses a VLAN identifier to associate Ethernet frames with a logical network. In common switch administration, usable VLAN IDs are treated as 1 through 4094, while platform and design rules decide which IDs should carry users, management, native VLAN traffic, or special services.

Access-port migrations are usually bounded by endpoint validation. Trunk and uplink migrations have broader impact because the allowed VLAN list, native VLAN, spanning-tree state, and peer configuration can affect many endpoints. A safe timing model therefore gives different weights to access, voice, access point, trunk, and uplink rows rather than counting every port as one identical unit of work.

Formula Core

The planner estimates each row, then adds shared validation time and buffers at the wave level.

Rule Core

Rows are parsed as port, endpoint, old VLANs, new VLANs, window, role, criticality, and note. The old and new VLAN lists are expanded, checked, deduplicated, sorted, and displayed as compact ranges when possible.

Bounds and Outputs

Accuracy and Privacy Notes:

The calculation is deterministic and based on the rows and settings entered in the page. It does not poll switches, read controller state, discover live VLANs, or verify that a port exists. Use it to prepare and review the worksheet, then confirm the live switching domain with normal operational tools.

Pasted rows are processed in the browser session. Avoid adding passwords, shared secrets, or unnecessary personal data to notes, exports, or copied runbook text. Treat endpoint names, port labels, and VLAN plans as operationally sensitive information when sharing the generated files.

Advanced Tips:

• Set Ports per wave lower for trunks, uplinks, phones, and access points. Smaller waves reduce the number of endpoints touched before each validation pause.
• Use distinct window names in Port migration rows when the work is split across closets, buildings, or maintenance periods; the load map compares each named window with the same budget.
• Keep Expected native VLAN aligned with the approved trunk standard before reviewing trunk rows. A mismatch between the worksheet and the switch standard can hide the wrong exception.
• Choose Hold old VLANs through burn-in when endpoint validation needs time after the window, and choose pruning only when the change record explicitly includes same-window cleanup.
• Raise Critical-row buffer for application-owner signoff, AP controller checks, or voice registration checks that cannot be completed during the normal validation pause.
• Use VLAN Change Matrix to find repeated old-to-new movements before cutover; repeated movements often point to shared DHCP, ACL, monitoring, or firewall work that should be confirmed once for the group.

Worked Examples:

A five-row closet migration with a 180-minute window and 3 ports per wave creates 2 waves. The sample-style mix includes access ports, an access point, a critical trunk, and a voice pair. The busiest window can remain inside budget because only one trunk and one critical row need the larger buffers.

Reducing the same plan to a 45-minute window changes the interpretation. The worksheet still produces waves and tables, but Readiness Brief reports over-budget windows and Window Load Map shows which named window exceeds the available minutes. The fix is not a formatting change; the change record needs fewer ports, a larger window, or another window.

A row such as sw03 Gi1/0/7,,1,1,Window C,access,standard,missing endpoint and VLAN 1 needs review for several reasons: endpoint is blank, old and new VLAN lists match, and VLAN 1 is not allowed without an explicit exception. Fix the endpoint and VLAN movement, or document the exception only if the approved change allows it.

FAQ:

Glossary:

VLAN

A virtual LAN identifier used to separate Ethernet traffic inside a switching domain.

Access port

A switch port that normally carries one endpoint VLAN for a workstation, printer, camera, or similar device.

Voice pair

A port plan where phone registration and data VLAN reachability both matter on the same physical link.

Trunk

A link that can carry multiple VLANs and needs allowed-list, native VLAN, and spanning-tree checks.

Native VLAN

The VLAN associated with untagged traffic on an 802.1Q trunk for platforms that use native VLAN behavior.

Wave

A small group of port changes completed before a validation pause inside the same named maintenance window.

Rollback trigger

The stop condition that tells the team when to revert the active wave before touching later rows.

References:

• IEEE 802.1Q-2022, IEEE Standards Association, 2022.
• 802.1Q - Virtual LANs, IEEE 802.1 Working Group, 2014.
• VLAN Commands, Cisco, 2025.
• VLAN Configuration Guide, Cisco.