Updated: June 22, 2026
A CIO at a Hyderabad enterprise tried to modernise the campus network in one weekend. New switches, new architecture, new segmentation, all swapped in a single maintenance window because the business could not spare more downtime than that. By Monday morning, two buildings were offline, the segmentation policy was half-applied, and the rollback took longer than the rollout. The project was technically sound. The approach was not. He had treated a multi-year evolution as a single event.
The opposite failure is more common and quieter. The modernisation that never happens. The network limps along on equipment a year past support, every refresh deferred because nobody can face the size of the job, until an audit finding or an outage forces a panicked, expensive scramble.
Both failures share one cause: the absence of a roadmap. Campus modernisation is not a purchase or a weekend. It is a sequence, and the organisations that do it well move through four clear phases, from an honest audit to a working zero-trust fabric. Here is the roadmap and how to use it.
Campus network modernisation is the planned upgrade of your switching, routing and wireless from an ageing, manually managed network to a current, automated and segmented one, usually built around Cisco SD-Access. It covers the hardware, the architecture, the security model and the way the network is run, not just the boxes.
The word that matters is "planned". Replacing switches as they fail is maintenance, not modernisation, and it leaves you with a patchwork of generations that never quite works as one. Modernisation means moving the whole campus toward a single, coherent target architecture, on a timeline you control, in steps small enough to be safe and large enough to make progress. The destination for most enterprises is a zero-trust fabric where access follows identity rather than the network port. The route there is the four-phase roadmap below.
They fail at the two extremes: too much at once, or nothing at all. The big-bang rebuild, like the Hyderabad weekend, underestimates how much can go wrong when hardware, architecture and policy all change together with no fallback. The endless deferral treats modernisation as a single intimidating expense rather than a phased programme, so it never starts, and the network ages into a liability instead.
Between those extremes sits a third failure that looks like success: buying first and planning later. A CIO approves a stack of switches because a budget window opened, then discovers the architecture they enable does not match the segmentation the security team needs, or the licence tiers are wrong for the routing the design requires. Hardware arrives before the design that should have shaped it. The roadmap exists precisely to prevent these three failures by putting understanding before design, design before purchase, and purchase before a careful, staged migration.
Modernisation moves through four phases, each producing something the next depends on. Skip one, and the later phases wobble.
| Phase | Goal | What you get out of it |
|---|---|---|
| 1. Assess | Understand the current state honestly | Inventory, lifecycle and risk map, a clear baseline |
| 2. Design | Define the target architecture | SD-Access blueprint, segmentation model, sized bill of quantities |
| 3. Deploy | Migrate in safe stages | A working fabric, building by building, with rollback at each step |
| 4. Operate | Run and improve continuously | Monitoring, support, optimisation, a network that stays modern |
This is the same shape as a serious integrator's engagement: assess, design, build and operate. The phases are not bureaucracy. They are the difference between a modernisation you control and one that controls you.
You cannot modernize what you have not measured. The first phase is an audit of the existing campus: every switch and router, its model, its software, its last date of support, how it is configured, and what it connects. It maps the network as it really is, not as the documentation claims, and the two are rarely the same.
The audit answers the questions every later phase needs. What is already past support and must move first? What carries sensitive data and falls under the DPDP obligations now in force, with their May 2027 deadline? Where are the bottlenecks, the single points of failure, the undocumented dependencies that would have turned a migration into an outage? The output is a baseline and a prioritised risk map. A CIO who has this document negotiates from knowledge. One who skips it is designing in the dark, which is how the Hyderabad weekend began.
With a baseline in hand, you design the destination. This phase defines the target architecture, almost always a Cisco SD-Access fabric, with the segmentation model that gives you zero trust: which virtual networks separate corporate, guest and IoT traffic, and which group policies govern what may talk to what inside them. It decides the switch tiers, the licensing, the power and the wireless to match, and turns all of it into a bill of quantities sized to the design rather than to a price list.
This is where the earlier point about buying first bites. Design before you purchase, and every switch you order has a defined role and the right licence tier. Purchase first, and you spend the design phase justifying hardware you already own. The design phase is also where you set the migration sequence, the order in which buildings or floors move, chosen so the riskiest and most outdated parts go first and each step is reversible. Good design makes the next phase boring, which is exactly what you want a migration to be.
Now you build, and the discipline is to do it in stages, not in one heroic cutover. The deploy phase migrates the campus to the new fabric building by building, or floor by floor, following the sequence the design set. Each stage has a defined scope, a maintenance window, a test plan and a way back if something does not behave. The network keeps running on the old and new in parallel until each segment is proven, so a problem in one building never becomes an outage across the campus.
Staged migration is slower to describe and far faster to recover from. The Hyderabad CIO learnt that the expensive way. A phased deployment would have moved one building, confirmed the segmentation and performance, and only then moved the next, so the worst possible failure was one building rolled back overnight, not a campus down on Monday. How much downtime can your business actually absorb in a single window? The honest answer is usually the argument for phasing.
Modernisation does not end when the last building cuts over. A fabric is only as good as the way it is run, and the final phase is continuous operation: monitoring the network, managing the policy, applying updates, renewing licences and support on time, and tuning the design as the campus changes. This is where the telemetry of a modern network earns its keep, feeding the assurance and automation that let a lean team run a large estate.
The operate phase is also what stops you arriving back where you started. A network without disciplined operations ages quietly until it needs the next big modernisation, and the cycle of deferral begins again. Run it well, with monitoring and a clear support model, and modernisation becomes a state you maintain rather than a project you repeat. For many enterprises, this is the phase to hand to a partner with a round-the-clock operations capability, so internal IT can focus on the business rather than the 2 a.m. switch failure.
Start with the assessment, always, and start it before the budget conversation rather than after. The audit is inexpensive relative to the programme, it produces the risk map that justifies the spend, and it stops you buying the wrong hardware. From there, the phases give you natural budget and approval points: assess, then fund the design, then fund the first deployment stage, then the next. You are never asking the board for the whole number at once, and every phase produces evidence that de-risks the following one.
The timing pressure is real. The 2026 wave of end-of-life Cisco equipment and the DPDP compliance deadline in May 2027 both argue for beginning the assessment now, while you can move at a planned pace, rather than later under the gun of an audit finding. A roadmap started early is a programme. Started late, it is an emergency.
This roadmap is not a theory. It is how serious modernisation is actually delivered, and it maps exactly onto how a full-lifecycle partner engages: assess, design, build and operate.
Proactive Data Systems is a 35-year-old system integrator with more than 1,500 customers and a Cisco Preferred Partner in Networking, Security, Collaboration, Cloud and AI, and Services.
We run all four phases under one roof: a lifecycle and risk assessment of your campus, an SD-Access and segmentation design sized to it, a staged migration with rollback at every step, and a 24x7 NOC in India to operate it afterwards. CCIE-led design, networking and security in the same team, and one point of accountability from the first audit to day-two operations.
Wondering where your campus sits on this roadmap, or which phase to fund first? Ask Proactive for a campus assessment. It is the cheapest phase, it produces the plan, and it is the right place for every modernisation to begin.
Proactive, Enterprise Networking Team
We'll get back to you shortly.
