VLAN Migration Planner

Ports{{ resultsReady ? computation.values.port_count : '—' }} Windows{{ resultsReady ? computation.values.window_count : '—' }} Review flags{{ resultsReady ? computation.values.issue_count : '—' }}

Wave visual unavailable.

Window length:

Each named window is checked against this budget.

minutes

Ports per wave:

Smaller waves reduce the endpoints touched before validation.

ports

Expected native VLAN:

Trunk rows receive an explicit native-VLAN check.

Base change time:

Voice, AP, trunk, uplink, multi-VLAN, and elevated-risk rows add time.

minutes

Validation per wave:

Added once per wave, not once per port.

minutes

Port migration rows:

Roles: access, voice, ap, trunk, uplink. Criticality: standard, high, critical.

Columns: port, endpoint, old VLANs, new VLANs, window, role, criticality, note.

Rollback trigger:

Write an observable condition the change team can apply.

Critical-row buffer:

Use only for explicit extended validation time.

minutes

Add same-window trunk pruning:

Off is neutral; enable only when old VLAN removal belongs in the approved window.

Allow VLAN 1 exception:

Leave off unless the approved change record explicitly accepts VLAN 1.

{{ computation.values.runbook_brief }}

Wave	Seq	Port	Endpoint	Role	VLAN move	Risk	Minutes	Note / status	Copy
{{ row.wave }}	{{ row.sequence }}	{{ row.port }}	{{ row.endpoint }}	{{ row.role }}	{{ row.movement }}	{{ row.risk }}	{{ row.change_minutes }}	{{ row.note_status }}

VLAN movement	Ports	Windows	Roles	Highest risk	Flags	Next action	Copy
{{ row.movement }}	{{ row.port_count }}	{{ row.windows }}	{{ row.roles }}	{{ row.highest_risk }}	{{ row.issue_count }}	{{ row.action }}

Phase	Check	Evidence	Owner action	Copy
{{ row.phase }}	{{ row.check }}	{{ row.evidence }}	{{ row.action }}

A VLAN migration changes where endpoint traffic belongs at Layer 2. Moving an access port may look like a one-line configuration change, but the service path can also depend on DHCP, routing interfaces, access-control lists, trunk allowed lists, wireless mappings, voice settings, spanning tree, and monitoring.

The safest unit of work is a small wave followed by validation. A wave limits the number of endpoints affected before the team pauses, checks service, and decides whether to continue or roll back. The maintenance window must include both change time and those validation gates.

Port roles create different risks:

Access port: Usually carries one endpoint VLAN and often needs link, address, reachability, and application checks.
Voice or access point: May carry more than one service and can require registration, Power over Ethernet, SSID, or voice-VLAN validation.
Trunk or uplink: Can affect many downstream devices. Both ends need consistent allowed VLANs, native VLAN expectations, and spanning-tree state.

IEEE 802.1Q uses VLAN identifiers to separate bridged traffic. Operational platforms commonly accept VLAN IDs from 1 to 4094, although specific devices reserve some values. VLAN 1 and native VLAN behavior deserve explicit approval because defaults and untagged traffic handling can differ by platform and design.

A runbook needs observable stop conditions. “Rollback if there are problems” is too vague during an outage. A useful trigger names the failing check and count, such as two endpoints losing DHCP or an unexpected spanning-tree topology change after the active wave.

Time estimates are planning buffers, not outage guarantees. Discovery delays, configuration deployment, convergence, endpoint renewal, authentication, and manual troubleshooting may take longer than the row model predicts. The final plan should be reviewed against actual switch configuration and an approved change record.

How to Use This Tool:

Paste one row per physical port, then size waves around the approved validation and rollback process.

Set the Window length, maximum Ports per wave, expected native VLAN, base minutes per port, and validation minutes added to every wave.
Enter each port as eight comma-separated fields: port, endpoint, old VLANs, new VLANs, window name, role, criticality, and note. Separate multiple VLANs with pipes, spaces, semicolons, commas, or a valid range.
Write an observable Rollback trigger. Add a critical-row buffer only when the approved plan reserves extra time per critical port.
Leave Add same-window trunk pruning off unless old VLAN removal is explicitly approved for the same window. Leave the VLAN 1 exception off unless the change record accepts it.
Resolve every flagged row before using the schedule. Then compare Port wave plan, VLAN change matrix, Validation checklist, and the window load against the real runbook.

Interpreting Results:

Ready to review means no row flags were found and no window estimate exceeds its budget. It is not approval to execute. Review rows takes precedence whenever any port has a parsing, role, VLAN, or policy flag. Window over budget appears only when rows are otherwise clean and at least one window total is greater than its budget.

Read the busiest window as an estimate of planned work, validation, and configured buffers. A total equal to the budget still fits; only a total strictly greater than the budget is over. Issue counts are counts of flags, not counts of affected ports, so one row can contribute several issues.

Confirm the generated movement and wave sequence against live interface state before change approval. Pasted inventory can be stale, and the planner does not query switches, controllers, DHCP servers, routing tables, or spanning-tree topology.

Technical Details:

The model normalizes roles and criticality, parses VLAN lists, assigns a change estimate to each row, groups rows by named window in input order, and splits each group into fixed-size waves. It then adds validation and risk buffers before comparing the summed window time with the budget.

Formula Core

Each port estimate starts with the base time multiplied by a role factor. A criticality increment and a two-minute multi-VLAN increment are added before rounding up to a whole minute.

\begin{matrix} T_{port} & = & ⌈ base \times role factor + risk extra + multi-VLAN extra ⌉ \\ T_{wave} & = & \sum T_{port} + validation + 3 \times trunks + critical buffer \times critical rows \\ T_{window} & = & \sum T_{wave} \end{matrix}

Role factors and criticality increments
Classification type	Value	Timing adjustment
Role factor	Access	1.00×
	Voice pair	1.35×
	Access point	1.30×
	Trunk	1.85×
	Uplink trunk	2.10×
Criticality extra	Standard	0 min
	High	3 min
	Critical	6 min

The multi-VLAN extra is two minutes when either the old or new list contains more than one VLAN. Every trunk or uplink adds three minutes to its wave after row estimates. Validation is added once per wave. The critical buffer is multiplied by the number of critical rows in that wave.

Rule Core

VLAN tokens may be individual IDs or ascending ranges. Valid IDs are 1 to 4094. A single range may span at most 129 IDs because a difference greater than 128 is rejected. Values are deduplicated, sorted, and compressed for display.

Port-row validation and readiness rules
Check	Flag or result
More than eight CSV fields	Extra CSV columns
Missing port, endpoint, old VLAN, or new VLAN	A separate missing-value flag for each problem
Unparseable or out-of-range VLAN	Invalid old VLAN or invalid new VLAN
Unknown role or criticality	Flagged, then treated as access or standard for timing
Old and new VLAN sets are identical	Old and new VLANs match
VLAN 1 present without the exception	VLAN 1 needs an approved exception
Trunk-like row with expected native VLAN 1	Native VLAN 1 on trunk scope
Expected native VLAN appears in a trunk target list	Native VLAN appears in target list
Window total greater than budget	Over budget; equality still fits

Rows stay in their original order within each named window. Waves contain 1 to 50 ports and are numbered separately per window. The model accepts at most 200 non-empty rows, a 15- to 1440-minute window, 1 to 120 base minutes per port, and 0 to 240 validation minutes per wave.

Planning and Privacy Notes:

The calculations run in the browser and do not contact network devices or send the pasted inventory to a server-side planner. Treat endpoint names, ports, notes, and rollback details as operationally sensitive and follow the organization's policy for browser use, exports, and shared runbooks.

Timing factors are local planning assumptions, not vendor performance guarantees.
Role recognition does not prove the actual switchport mode.
The native VLAN check uses one expected value and cannot compare both ends of a trunk.
Same-window pruning is a checklist choice; it does not validate burn-in or remove configuration.

Worked Examples:

Five ports across two windows

Using the supplied five-row sample, 180-minute windows, three ports per wave, six base minutes, and 12 validation minutes produces two waves with no row flags. Window A totals 38 minutes. Window B contains one critical trunk and one voice pair; its row estimates total 31 minutes, validation adds 12, and the trunk buffer adds 3, giving 46 minutes. The result is Ready to review, which still requires live-state checks and change approval.

References:

IEEE 802.1Q-2014: Bridges and Bridged Networks, IEEE Standards Association, 2014.
Configure VLAN Trunking, Cisco.
Troubleshoot Spanning Tree PVID and Type Inconsistencies, Cisco.

VLAN Migration Planner

{{ summaryTitle }}

How to Use This Tool:

Interpreting Results:

Technical Details:

Formula Core

Rule Core

Planning and Privacy Notes:

Worked Examples:

Five ports across two windows

References: