Cisco & Meraki specialists. Across the UK.
+44 203 196 6566 · option 1sales@proxar.co.uk

Connect. Secure. Manage.

Campus Gateway Migration

Plan a move to Campus Gateway-based wireless traffic handling, using a scoped pilot and explicit rollback points for affected SSIDs and client groups.

Cisco Partner since 2009 Projects & ongoing support

Illustrative Cisco Meraki wireless access point in a modern office
Your network. Properly considered.Design · Implementation · Support
1,000+

Devices supported
across the UK

20+

Client locations
supported

Nearly 8 Tbps

Traffic handled
at peak time

3 min

Average
response time

Average response is not a resolution time or a contractual guarantee. Support scope and response commitments are agreed for each engagement.

Campus Gateway migration changes where supported wireless traffic enters the campus network. We plan from your actual starting point, whether distributed forwarding or a controller-based setup. Feature checks and a staged cutover protect service continuity. The existing system stays available until the agreed replacement behaviour has been shown to work.

01

Coverage and capacity

Design Wi-Fi around the spaces, devices and traffic that depend on it.

02

Secure access

Align authentication, segmentation and guest access with the wider network.

03

Measured performance

Validate roaming, interference and user experience instead of relying on signal bars.

Document the current wireless service

We inventory the access points, controllers or dashboard networks, software and client services that currently exist. The review captures authentication, addressing, guest access, discovery needs and operational integrations. It also identifies the apps whose behaviour must be preserved. A migration based only on equipment counts can miss a specialised service that is small in scale but important to the business.

The current forwarding path is recorded for each relevant wireless service. Some traffic may leave locally, while other traffic follows central or guest-specific arrangements. We compare those paths with the proposed Campus Gateway design and identify what will change. This helps the customer distinguish a supported migration aim from an assumption that every previous function will behave identically on the new architecture.

Illustrative Cisco and Meraki network rack in a modern office
01The office network: switching, uplinks and structured cabling.
Cisco PartnerCisco Partner
Cisco MerakiCisco Meraki
ISO 9001Quality management
ISO 27001Information security
Cyber EssentialsCyber Essentials
Cyber Essentials PlusCyber Essentials Plus

MCI Network Services is operated by Proxar Ltd. Certifications apply to the certified legal entity and the scope of its certificates. View accreditation information

Confirm compatibility and the target design

The proposed access-point, gateway and firmware combination must support the required service. We check current platform guidance and identify hardware or software prerequisites before scheduling the cutover. Any supported change of device operating mode is treated as a clear project step with its own implications, not as a setup toggle assumed available on every model.

The target architecture defines management ownership, client termination and upstream integration. We review which features can be retained, which need redesign and which are outside the chosen platform’s supported scope. The customer approves those differences before rollout. Our Campus Gateway architecture service can establish this baseline where the migration request begins with a desired product rather than an agreed operating design.

Illustrative Cisco and Meraki network operations centre with monitoring displays
02Visibility, monitoring and operational control.

A useful starting point

Not sure where to start?

Bring the requirement. We will help you define the engineering work.

Talk to a specialist

Prepare the network before moving clients

Switching, routing, firewall and identity prerequisites are completed and checked before production wireless services move. We check the gateway’s upstream links, the transport from access points and the intended client VLANs. DHCP, DNS and security policy are tested from the target service position. So a missing dependency does not become visible only after the old path has been withdrawn.

The preparation also covers dashboard assignment and admin access. Equipment and networks must be under the correct ownership, with a recovery route that does not depend solely on the component being changed. We retain the current setup and identify which temporary settings are needed for coexistence. Every temporary exception has a purpose and a planned removal point rather than becoming undocumented permanent infrastructure.

Illustrative Cisco and Meraki equipment in organised data-centre racks
03Data-centre connectivity with clear physical and logical boundaries.

Pilot a complete user journey

The pilot includes representative access points, clients and apps, chosen to exercise the important path and policy differences. We test fresh connection, authentication, address assignment, normal work and mobility where required. Results are compared with the current service baseline, not only with whether the new gateway reports itself healthy.

We investigate material differences before expanding the rollout. A client that receives a different address or security policy may still browse successfully while a specialist app fails later. The acceptance plan therefore includes the relevant app owners and prohibited paths that must remain blocked. Exceptions are documented with their business effect and owner, rather than hidden inside a general description of a successful pilot.

Illustrative Cisco and Meraki fibre network rack with structured cabling
04Fibre, switching and the physical path behind the service.

Control coexistence and rollback

During transition, the old and new forwarding arrangements may exist at the same time. We set out which access points and services use each path and how clients behave when moving between them. Roaming across the migration boundary is assessed clearly. A common network name does not by itself guarantee consistent authentication, addressing or app continuity across different architectures.

Rollback planning accounts for device assignment, operating mode, software and upstream setup. The previous platform must remain usable for the agreed recovery procedure. We establish checkpoints and stop conditions, including who can authorise a pause. Where a later migration step changes the practical rollback options, that point is explained in advance rather than discovered after the team has passed it.

Illustrative Cisco Meraki wireless access point in a modern office
05Cloud-managed wireless for modern workplaces.

Retire the old dependencies and update operations

Completion includes reconciling the final estate, removing obsolete temporary routes or permissions and updating monitoring and support records. We check whether the earlier controller or network still provides any guest, discovery or management function before retiring it. An apparently unused appliance should not be removed solely because its main access points have moved elsewhere.

MCI can combine this work with Campus Gateway deployment and a separately scoped management service. Provide the current wireless architecture, site constraints and critical client needs. We will define a staged transition and acceptance record that makes the change understandable, with the new service supported by evidence rather than an assumption that central termination alone guarantees a successful migration.

Illustrative Cisco and Meraki network rack in a modern office
06The office network: switching, uplinks and structured cabling.

Technical references

Illustrative Cisco and Meraki network operations centre with monitoring displays
07Visibility, monitoring and operational control.

Talk to a specialist

What does your network need next?

Tell us what you are planning, changing or trying to improve. We will help define a practical next step and the engineering scope.

+44 203 196 6566

Choose option 1

sales@proxar.co.uk

UK-wide service.
Most of our engineers are based in Kent, with a focus on London, Sussex, Essex and Berkshire.

Existing customers should use their agreed support and escalation channels. This form is for service enquiries, not a monitored emergency ticket.

Tell us what you need.

A short outline is enough. Please do not include passwords or sensitive network details.

Thank you. Your enquiry has been submitted.

We’ll use these details to respond to your enquiry. Please leave out passwords and sensitive network information. Read our privacy notice.