Connect. Secure. Manage.
SD-Access Migration
Move a traditional Cisco campus towards SD-Access through a staged plan for site readiness, endpoint transition and rollback at each change boundary.
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.
SD-Access migration moves an existing campus towards a Cisco fabric while keeping the business able to operate through the transition. The difficult work is often coexistence: old VLANs, new virtual networks, retained applications and several teams’ change windows. MCI Network Services plans and delivers staged migrations with clear ownership at every boundary, explicit rollback criteria and acceptance tests that reflect the customer’s actual users and devices.
Cisco-focused engineering
Design around the platform, traffic and failure behaviour you actually operate.
Change with evidence
Use pre-checks, acceptance criteria and a documented route back.
Operational handover
Keep the configuration, diagrams and responsibilities understandable after delivery.
Define the destination before the cutover sequence
The approved target design should identify fabric roles, addressing, policy and external handoffs. Without that baseline, a migration can become a series of urgent exceptions that never converge on one coherent architecture. We review the design and record unresolved decisions before turning it into an implementation plan.
The current network is then mapped against the target. We identify which devices can be retained, which require software or hardware changes and which services are outside the migration scope. These distinctions are important for both budgeting and accountability. A campus fabric project does not automatically replace every connected server, firewall or wireless system.
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
Find dependencies that cross migration boundaries
Applications may depend on fixed addresses, local broadcasts, multicast, non-standard discovery or an old gateway location. We work with service owners to identify those requirements and decide how they will be handled during coexistence. Quiet or infrequently used systems should not be ignored simply because they produce little traffic during a short observation period.
Identity and endpoint onboarding are examined separately. Managed laptops, phones, printers and operational devices may need different preparation. Certificates, authentication policies and fallback arrangements must be ready before users move. A successful infrastructure pilot is not sufficient if the endpoint population in the next building is materially different.
A useful starting point
Not sure where to start?
Bring the requirement. We will help you define the engineering work.
Choose manageable migration units
A migration unit might be a wiring cabinet, floor, building, endpoint class or application group. We choose boundaries that allow useful testing and practical reversal. Moving too much at once makes fault isolation harder; moving too little can prolong complex coexistence. The plan balances those risks against the available maintenance windows.
Each wave has an entry checklist, implementation steps and an acceptance decision. Dependencies on customer teams and external suppliers are named. The schedule includes time for observation and corrective work, not only the configuration commands. This makes it easier to stop a rollout safely when a pilot exposes an unexpected application dependency.
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 ↗Control routing and gateway ownership during coexistence
Old and new networks must have a clear view of which system owns each subnet and gateway at each stage. We review route exchange, temporary handoffs, DHCP behaviour and return paths. Unplanned overlap can create intermittent connectivity that looks like an endpoint problem but is actually a routing ambiguity.
Temporary Layer 2 extensions or policy exceptions are documented with removal conditions. They may be justified to support a transition, but they should not silently become permanent architecture. The final migration stage includes retiring those arrangements and verifying that the intended fabric boundaries are now the only operational design.
Make rollback achievable
A rollback plan states what will be restored, by whom and within which decision window. It includes external routing and security changes as well as the fabric configuration. We verify that the previous equipment, addressing and management access remain usable for as long as rollback is required.
Some changes cannot be reversed by pasting back a configuration file. Endpoint state, controller provisioning and software transitions may require additional steps. Those limitations are assessed before the cutover. The customer should know when the practical choice becomes forward recovery rather than a quick return to the old network.
Validate users, applications and policy
Acceptance covers onboarding, addressing, shared services, application access and the restrictions that should remain in place. We use representative endpoints from the migration unit rather than relying on an engineer’s test laptop alone. Wireless mobility and specialist traffic are included where they form part of the agreed scope.
The observation period looks for intermittent faults, unexpected policy denials and missing operational visibility. We record the result of each test and identify any accepted limitation. A wave is not complete merely because no user complained during the first few minutes after the change.
Close the old environment properly
Decommissioning includes obsolete routes, temporary policies, unused credentials and superseded documentation. The operations team receives the new topology and an investigation path for fabric-specific incidents. We also review monitoring, backups and software lifecycle responsibilities so the deployment can be maintained after the project team leaves.
MCI can deliver a complete migration or support an internal team through selected waves. Fabric design and SD-Access troubleshooting are available as related engagements. Provide the current topology, target scope and maintenance constraints to establish a migration plan that the business can approve with a clear understanding of risk.
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.