Every five to seven years a familiar line item reappears in the network budget. The campus switches have reached end of support, the maintenance renewal has become difficult to justify, and it is time to refresh. The exercise usually runs as a procurement: count the ports, match the specifications, compare the discounts, place the order, schedule the cutover windows.
What rarely gets asked during that exercise is whether the architecture being purchased is the one the organization wants to be operating in 2033. Yet that is precisely what is being decided. A switching estate bought this year will still be carrying policy, still shaping how segmentation gets implemented, and still determining how many consoles an engineer has to open to answer a question, long after everyone involved in the purchase has moved on to other work.
The Decision Nobody Treats as a Decision
The refresh cycle has a peculiar property. It is the most predictable event in campus networking and the one least likely to be used as an opportunity. Because the trigger is hardware reaching end of support, the question forms as a hardware question, and the answer requiring the least explanation is to buy the current generation of what is already installed. That path is defensible, the risk is understood, and the team knows how to execute it.
The difficulty is that the path also renews everything else. Switching, access control, and firewall policy stay in separate management planes. Zero Trust enforcement continues to stop where it stopped before. The campus design remains something that lives partly in documentation and partly in the memory of two or three engineers. None of that is on the invoice, and none of it changes for another five to seven years.
Increasingly, this collides with a second timeline. Segmentation and least-privilege requirements are arriving from the security side of the organization at precisely the moment the switching estate is coming up for renewal. One is a policy problem and the other is a hardware budget, and network teams are being asked to reconcile them in the same quarter. Doing that with a like-for-like refresh means solving the policy problem later, separately, and usually with another product.
The Costs That Never Appear on the Purchase Order
Hardware is the visible number, which is why it dominates the evaluation. The costs that determine what the estate is actually worth to operate sit elsewhere.
Start with management planes. A mixed-vendor campus with separate switching, access control, and security products means the same intent has to be expressed more than once, in more than one system, in more than one policy language. Every one of those expressions is a place where drift can begin, and drift is where troubleshooting time goes. When an engineer has to open three consoles to establish why a device cannot reach an application, the cost is not the license for the third console. It is the hour, repeated across a year, across a team.
Then consider concentration risk. Campus designs accumulate exceptions, and the reasoning behind them is rarely written down completely. Over a few refresh cycles the result is an estate that works but that nobody feels safe modifying. That is a real operational cost, and it grows quietly, because it only becomes visible when the person who understood the design leaves.
Software-Defined Networking Stopped at the WAN Edge
The WAN went through this transition roughly a decade ago, and the outcome is now unremarkable. Enterprises expect to define intent centrally, push it through templates, bring new sites up without configuring devices individually, and remain independent of any particular transport. Those expectations are so established that they are no longer treated as innovations. They are simply what a WAN is.
Then the same organization walks into the wiring closet and none of it applies. Provisioning is per device. Policy is local. Adding capacity is a hardware exercise. Visibility stops at the boundary of whichever product is being examined.
It is worth being honest about why the transition stopped where it did. The WAN had an unmistakable, quantifiable pain in circuit cost, which made the business case straightforward to write. The pain in the LAN is diffuse, spread across many small inefficiencies and difficult to attribute to any single line item. Switching has also been sold as a hardware category for thirty years, which shaped how it gets budgeted and who gets consulted.
What Changes When One Fabric Reaches the LAN Edge
Versa Secure SD-LAN extends the VersaONE software-defined fabric from the WAN into the campus and branch LAN, running LAN, WAN, SSE, and SASE on one operating system. That single architectural fact is what separates this from unifying separate products after purchase, and it is the point worth dwelling on, because the practical consequences follow from it directly.
Policy written and tested for the WAN applies in the LAN rather than being rebuilt there. There is no second policy language, no second place for the same intent to live, and therefore no drift between the two. Management stays in VersaONE and Concerto, so the team is not learning a second console or building a second skill set. Provisioning becomes central instead of per device, with Zero Touch Provisioning, Dynamic Smart Ports, and template-based service definitions turning site turn-up into a template exercise. Zero Trust and microsegmentation are enforced as close to the endpoint as the deployment allows, which means the segmentation requirement is satisfied by the fabric rather than by a product layered on top of it.
The model is also software-defined and hardware-flexible, which changes the economics of scale. Capacity gets added when a site needs it rather than when a vendor generation dictates, and the estate is no longer tied to a proprietary set of protocols, platforms, and connection options. For an organization already running Versa in the WAN, this is an expansion of a known architecture rather than the introduction of a new one, which is a materially different risk profile from evaluating and staffing an unfamiliar switching platform.
Sequencing a Refresh Without a Forklift
The most common objection to changing the model during a refresh is that it sounds like a larger project than a like-for-like replacement. It does not have to be. Because the LAN runs on the fabric and management already in production, sites can be brought across in phases, following the budget and the support calendar rather than dictating them. A reasonable sequence starts where support has lapsed or where a segmentation requirement is most acute, and each subsequent wave inherits the policy and templates the first established, so the effort curve falls rather than repeats.
The Refresh Is the Only Moment You Get
Nothing about a campus network forces the question of architecture except the refresh. Between cycles the estate is expensive to change and there is rarely a trigger to justify the disruption. That is what makes this window worth using deliberately.
The hardware is being replaced regardless. Doing it on a unified, software-defined fabric changes the operating model at the one point where change was already scheduled, and satisfies the segmentation and Zero Trust requirements from the platform the organization has already deployed rather than through a separate procurement. The alternative is not avoiding a decision. It is making the same decision again, by default, for another five to seven years.
Learn more about how Versa can help with your next LAN refresh cycle here.
