Connect. Secure. Manage.
Cisco EVPN Fabric Migration
Plan a transition from traditional data centre switching to Cisco EVPN, accounting for coexistence, gateway movement and workload dependencies.
Devices supported
across the UK
Client locations
supported
Traffic handled
at peak time
Average
response time
Average response is not a resolution time or a contractual guarantee. Support scope and response commitments are agreed for each engagement.
Cisco EVPN fabric migration moves workloads into a new fabric in planned stages. We check gateway ownership, device links and app traffic at each step. The plan sets points to continue, stop or recover. Temporary routes and extensions have a defined purpose and end point, so they do not become an unmanaged part of the network.
Workload-led design
Start with application, compute and storage dependencies rather than the switch model.
Clear failure domains
Understand which links, devices and sites can fail together.
Operational clarity
Make fabrics, external routing and management responsibilities supportable.
Build a dependency-led migration inventory
We identify workloads, subnets, gateways, security paths and the teams responsible for them. Application dependencies include more than the main client connection: identity, name resolution, backup and management can determine whether a workload remains usable after it moves. Existing setup and observed traffic help build the picture, but app owners confirm the required service relationships.
The inventory distinguishes systems that can move independently from groups that need coordinated cutover. It also records physical and virtual attachment needs and any unsupported legacy equipment. These details influence the migration sequence and prevent the project from assuming that every server can use the same uplink or gateway approach.
Standards & partnerships
Confidence in the team behind your network.
Cisco Partner
Cisco Meraki
Cyber Essentials
Cyber Essentials PlusMCI Network Services is operated by Proxar Ltd. Certifications apply to the certified legal entity and the scope of its certificates. View accreditation information
Establish the target fabric before moving production
The underlay, overlay control plane and tenant model are checked against the approved design. We check addressing, identifiers, route policy, MTU and external network access on the actual Cisco platforms and releases. A fabric with established peers is not automatically ready for all workloads. Representative service tests should show the functions the migration will depend on.
Configuration ownership is agreed with the operations team, especially where a management platform or automation system is involved. We find the authoritative source and the process for handling exceptions. Introducing a new fabric while retaining uncontrolled manual changes across several tools can create uncertainty at exactly the point when reliable state information is most important.
A useful starting point
Not sure where to start?
Bring the requirement. We will help you define the engineering work.
Design coexistence and gateway movement
The old and new networks may need temporary network access during the transition. We set out which Layer 2 segments are extended, where routing occurs and how loops or unintended transit are prevented. Extension has a stated purpose and removal condition. It is not assumed to be harmless simply because only a few workloads remain on the old network.
Gateway movement requires particular care. Supported anycast-gateway behaviour, legacy gateway ownership and endpoint neighbour state are considered together. We plan the change so that duplicate or inconsistent gateway responses do not emerge during coexistence. Return paths through firewalls and translated addresses are reviewed with the security team before app traffic is redirected.
Different environments. The same care.
Built around the work
your network supports.
Finance, banking and the wider private sector. We start with the systems and people that depend on your connections.
Finance & banking
Market-data paths, routing and provider coordination on clients’ behalf.
Financial-market services ↗Offices & multi-site teams
Reliable access between people, workplaces and business applications.
Office network design ↗Data centres & cloud
Network boundaries, workload connections and operational ownership.
Data centre networks ↗Pilot workloads that represent real constraints
The pilot includes a bounded group that exercises important network functions, not only a server with a simple ping test. We check app access, shared services, management and intended isolation. Platform teams confirm host and virtual-switch settings, while the network team checks the relevant endpoint and route state.
Results are used to refine later waves. A successful pilot does not prove that every storage, partner or legacy app will behave identically. We identify differences and preserve appropriate checks for each group. The migration register records current location, gateway state, acceptance evidence and rollback position so that everyone has a shared view of progress.
Execute cutovers with explicit recovery boundaries
Each wave has prerequisites, a change sequence, responsible people and stop criteria. We preserve the pre-change state and confirm alternative management access. The team checks each meaningful step before introducing the next dependency, reducing the chance that several simultaneous changes obscure the cause of a failed test.
Rollback is defined realistically. Reversing network setup may not restore an app that has changed data, addressing or platform state during the cutover. We agree recovery with the app and infrastructure owners and identify any point after which a forward fix is the safer option. These decisions are made before the production window rather than improvised under pressure.
Remove temporary infrastructure and complete handover
After the agreed workload groups are accepted, we remove obsolete extensions, redistribution and unused access where authorised. Documentation, monitoring and setup protection are updated to represent the final fabric. Retired devices and credentials follow a controlled decommissioning process. A migration is not complete while the old network remains an undocumented dependency that no team owns.
MCI can deliver a Cisco EVPN migration programme or assist with architecture review and critical cutovers. Related services include EVPN architecture and data centre relocation networking. Provide the current topology, workload groups and target constraints to begin. The proposal will distinguish network migration tasks from the app and platform work needed for complete service acceptance.
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 6566Choose option 1
sales@proxar.co.ukUK-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.
Please check your name, email and message, then try again.
Your form session expired. Please try again.
Please wait a minute before sending another enquiry.
We could not submit your enquiry. Please call or email us instead.