Migrating a legacy campus network takes more planning than replacing aging switches.

The existing environment may contain years of network changes, application dependencies, security rules and workarounds. Some will be documented. Others may only surface when the migration is underway.

A VLAN may extend across several buildings. An application may rely on a specific subnet. A printer may still use a static IP. A wireless network may depend on the existing routing design. Building systems may share infrastructure with corporate IT while being managed by another team.

All of these details can affect the migration.

That makes legacy campus network migration a planning exercise as much as an infrastructure project.

The team needs to understand what can move, what needs coordination, how the old and new environments will operate together, and how each phase will be validated.

This is where much of the work happens before the first production cutover.

Start With the Existing Network

Before deciding how to migrate the campus, build a clear picture of the network already in place.

Years of changes can leave behind VLANs, IP ranges, routing rules, security policies, wireless dependencies and applications tied to specific network conditions.

Some will be documented.

Others may only surface during the migration.

Current Cisco guidance for brownfield SD-Access migrations recommends collecting information about the existing topology, configurations, IP addressing, DHCP, common services, segmentation and wireless requirements before migration.

The same discipline applies to broader campus network modernization.

Start by mapping the environment.

Then identify the dependencies.

Build a dependency map

At minimum, document:

• Core and distribution connectivity

• Access switches and uplinks

• VLANs and subnets

• DHCP scopes

• Routing

• Wireless

• Authentication

• Firewalls and ACLs

• Critical applications

• Data-center connections

• Voice

• CCTV

• Access control

• IoT and building systems

• Monitoring and management platforms

Then map the relationships between them.

That second layer is often where the important information appears.

Legacy Networks Carry Years of Decisions

A campus network that has been running for years rarely looks exactly like its original design.

Applications have changed.

Buildings have changed.

Users have changed.

Security requirements have changed.

The network has adapted along the way.

That can leave configurations that still work but are difficult to explain.

Look for the things that are easy to miss

Static IP addresses

A device may not use DHCP because it was configured manually years ago.

Extended VLANs

A VLAN may carry traffic between buildings or network closets.

Layer 2 dependencies

Some applications or devices may still depend on Layer 2 adjacency.

Old routing rules

A route created for an earlier application may still be part of the traffic path.

Authentication dependencies

Network access may depend on RADIUS, 802.1X or another identity system.

Non-IT systems

Cameras, access control, building management and other connected systems may have different owners and different change requirements.

These dependencies can influence both the network migration strategy and the order in which different parts of the campus are migrated.

Design the Coexistence Period

A brownfield migration creates a temporary state where the existing and new environments operate together.

That period needs its own design.

You need to know:

• Which areas remain on the legacy network

• Which areas move to the new network

• Where routing happens

• How shared services are reached

• How traffic moves between environments

• Which security policies apply at the boundary

• How the transition is monitored

Cisco's current SD-Access guidance describes several ways to connect traditional and new environments during migration, including Layer 2 handoff and phased migration.

The same principle applies to other campus architectures.

Define the transition boundary before the rollout begins.

Choose the migration unit carefully

A VLAN may seem like an obvious unit for migration.

It may span multiple buildings or switches.

Moving only part of that environment can leave the same logical network divided between two architectures.

Cisco's guidance highlights the challenges of migrating VLANs that span multiple traditional switches.

The migration unit could instead be:

• A network closet

• A floor

• A building

• A group of switches

• A defined endpoint population

The right choice depends on the network's dependency structure.

Check IP Addressing Before It Becomes a Constraint

IP addressing can influence the migration sequence more than expected.

The target architecture may be ready, but existing applications and devices may depend on the current addressing scheme.

Applications can have hard-coded addresses.

Devices can have static configurations.

Security policies can reference existing subnets.

DHCP scopes can serve multiple areas of the campus.

Cisco specifically identifies IP addressing and DHCP scope management as areas that should be assessed during brownfield SD-Access migration planning.

Treat addressing as a migration dependency.

Classify endpoints by migration effort

A practical approach is to group endpoints based on how easily they can move.

Low dependency

Standard user endpoints using DHCP.

Moderate dependency

Printers, managed devices and applications requiring coordinated changes.

High dependency

Legacy applications, OT systems, building systems or devices where renumbering could affect operations.

This classification can help determine which areas should move early and which need additional planning.

Bring Wireless Into the Same Plan

Wireless is often managed as a separate workstream.

During a campus migration, its dependencies overlap heavily with the wired network.

Access points rely on the wired infrastructure.

Controllers provide network services.

Users move between buildings and floors.

Some environments also have roaming requirements that cross migration boundaries.

Cisco's current guidance addresses wireless migration and roaming considerations as part of an existing campus transition to SD-Access.

So include wireless when defining each migration phase.

Ask:

• Which access points move with the phase?

• Which controller or management system supports them?

• What happens to roaming users?

• Do SSIDs remain unchanged?

• Does IP addressing change?

• How will wireless performance be validated?

The wireless design should be part of the migration plan from the beginning.

Choose the Right Migration Strategy

There is no single campus network migration strategy that fits every environment.

The choice depends on the campus layout, existing hardware, available space, application dependencies and tolerance for change.

Building-by-building migration

One building or defined campus area moves at a time.

This can keep the scope of each change manageable.

It works particularly well when network and building boundaries align.

Cisco identifies building-by-building and closet-by-closet approaches as options for brownfield migration.

Incremental migration

The new architecture is introduced piece by piece while some existing infrastructure remains operational.

This can work well where a full parallel deployment is difficult.

It also allows the team to learn from each migration phase.

Parallel migration

The new network is built alongside the existing one.

Users and infrastructure then move across in stages.

The main benefit is a clearer rollback path because the previous environment remains available during the transition.

The trade-off is additional infrastructure, including rack space, power and cabling. Cisco identifies these considerations in its current migration guidance.

Hybrid migration

Large campuses may use different approaches in different areas.

One building may use parallel deployment.

Another may move incrementally.

A hybrid approach can make sense when the campus has different infrastructure conditions across locations.

The migration method should follow the environment.

Use the Pilot to Test the Real Environment

A migration pilot should tell you whether the new architecture works with actual campus dependencies.

Test the basics first:

• DHCP

• DNS

• Authentication

• Internet access

• Data-center access

• Critical applications

• Wireless

• Voice

• Printers

• Security policies

• Monitoring

• Logging

Then test the systems specific to that campus.

If a building has specialized equipment, include it.

If an application has a known network dependency, test it.

If users move between buildings, test those paths.

Choose a representative pilot

The easiest building may not give you enough information.

A useful pilot should be manageable while still representing the types of dependencies found elsewhere.

The objective is to find problems while the change is still contained.

Then use those findings to improve the next phase.

Define Rollback Before the Cutover

"Rollback if required" is not enough.

Before each migration phase, define:

• What triggers rollback

• Who makes the decision

• How long the team has to decide

• Which configuration is restored

• How users return to the old network

• How the old path is validated

• What happens to changes made during the migration window

A parallel deployment can simplify rollback because the existing environment remains available. Cisco identifies this as one of the advantages of the approach.

Incremental migrations also need a recovery plan.

The team should know the recovery path before the migration window begins.

Validate More Than Connectivity

A network can be available while users are still experiencing problems.

Validation should therefore cover several areas.

Connectivity

Check access to:

• Business applications

• Internet

• Data centers

• Shared services

• Other campus locations

Performance

Check:

• Latency

• Packet loss

• Throughput

• Application response

• Wireless performance

Security

Check:

• Authentication

• Segmentation

• ACLs

• Firewall policies

• Guest access

• Security monitoring

Operations

Check:

• Device visibility

• Monitoring

• Alerts

• Logs

• Configuration backup

• Troubleshooting workflows

Document the results after every phase.

If the first migration identifies a problem, adjust the process before moving the next area.

Plan the Retirement of the Legacy Network

The migration has another important phase after the new infrastructure goes live.

Legacy infrastructure needs to be retired deliberately.

Otherwise, old VLANs, monitoring rules, configurations and devices can remain in the environment long after their original purpose has disappeared.

For each legacy component, establish retirement criteria such as:

• No active endpoints

• No application dependency

• No required routing

• No security dependency

• No monitoring dependency

• Configuration backup completed

• Business owner approval

Then remove it.

A legacy network modernization project should include decommissioning from the start.

What a Real Campus Modernization Looks Like

Arche's IIM Kozhikode project is a useful example because the existing environment was assessed before implementation.

The engagement included a technical audit, user profiling, geographic mapping, multi-vendor compatibility assessment and cost-benefit analysis. The implementation then moved through simulation, pilot testing, core deployment and sequential deployment across academic blocks, administrative buildings and hostels.

The project also integrated existing and new campus infrastructure.

That is relevant to brownfield campus network migration because the transition between environments had to be considered as part of the implementation.

The resulting environment supported more than 3,000 active ports and 1,000 active users. The case study also describes SDN-based policy automation and automated policy enforcement.

Read the IIM Kozhikode campus networking case study

A larger enterprise example comes from Siemens.

Arche's project involved approximately 35,000 endpoints, with enterprise networking, data-center networking, WAN and software-defined networking as part of the modernization. The case study describes phased endpoint migration and Cisco SDA within the campus architecture.

See the Siemens network modernization case study

These projects show how migration planning becomes part of the network design itself.

A Practical Legacy Campus Network Migration Checklist

Before the first production cutover, the team should be able to answer these questions.

Current network

• Do we have an accurate topology?

• Which VLANs exist?

• Where is each subnet used?

• Which devices use static IP addresses?

• Which applications depend on existing IP ranges?

• Which workloads depend on Layer 2?

Target network

• What is the new routing model?

• How will segmentation work?

• What changes for wired users?

• What changes for wireless users?

• How will security policies be enforced?

• How will shared services connect?

Migration

• What is the first migration unit?

• Why was it selected?

• How will the old and new networks coexist?

• What is the migration sequence?

• Which dependencies need to move together?

Testing

• Have critical applications been tested?

• Has authentication been tested?

• Has wireless been tested?

• Have security policies been tested?

• Is monitoring working?

Rollback

• What triggers rollback?

• Who makes the decision?

• How quickly can the previous state be restored?

• Has the rollback process been tested?

After migration

• When can legacy infrastructure be retired?

• Which documentation needs updating?

• Which monitoring rules need removing?

• Who owns the new environment?

If several answers are still unclear, the migration plan needs more discovery before the production cutover.

How Arche Can Help With Campus Network Modernization

A successful campus network upgrade starts with a clear understanding of the existing environment.

Arche's networking practice covers network design, intelligent routing, unified connectivity and network management, alongside broader network modernization services.

Explore Arche's network solutions

For a migration project, the work can be structured around:

Assessment → dependency mapping → target architecture → migration planning → deployment → validation → operations.

The exact sequence depends on the campus.

The important part is having that sequence defined before the first cutover.

Frequently Asked Questions

What is a legacy campus network migration?

It is the process of moving an existing operational campus network to a newer architecture or infrastructure while keeping users, applications and services running.

What is the biggest challenge in a campus network migration?

Understanding dependencies is one of the biggest challenges. VLANs, IP addressing, applications, wireless, authentication, security policies and non-IT systems can all affect the migration sequence.

What is brownfield network migration?

Brownfield migration means modernizing an existing operational network rather than building a completely new network from scratch.

Should I replace the entire campus network at once?

Not necessarily. Building-by-building, incremental, parallel and hybrid approaches can be used depending on the environment. Cisco's current guidance describes parallel and incremental migration as different approaches with different operational and infrastructure requirements.

How do you migrate a campus network without disrupting users?

Use dependency mapping, controlled coexistence, testing, phased deployment and a defined rollback process. The specific approach depends on the existing and target architectures.

What should I check before a campus network upgrade?

Start with topology, VLANs, IP addressing, DHCP, routing, applications, wireless, authentication, security policies, monitoring and hardware capability.

Why is IP addressing important during network migration?

Existing applications and devices may depend on current addresses or subnets. Changes to IP addressing and DHCP can therefore affect the migration sequence.

Can old and new campus networks run together?

Yes. The specific coexistence method depends on the target architecture. During SD-Access migration, for example, Cisco documents Layer 2 handoff as one transition method.

What should a network migration rollback plan include?

It should define the rollback trigger, decision owner, recovery steps, configuration backups, user movement and validation of the restored environment.

How long does a campus network migration take?

There is no reliable single timeframe. It depends on campus size, endpoints, applications, existing infrastructure, target architecture and migration method.

Ready to Modernize Your Campus Network?

Know what you're moving before you move it.

Talk to Arche about your campus network modernization plan