Connect. Secure. Manage.
Cisco ASA Migration
Plan a migration from Cisco ASA to Secure Firewall, reviewing rule conversion, NAT, VPN dependencies and differences that require redesign.
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 ASA migration is a policy and service transition, not merely a hardware replacement. Existing ASA configurations can contain years of NAT rules, VPN dependencies, object groups and exceptions that need interpretation before they move. MCI Network Services assesses the current service, designs the supported target and carries out a staged migration with application testing and a practical recovery plan.
Defined trust
Make access boundaries explicit rather than relying on an assumed internal network.
Controlled access
Connect identity, policy and network enforcement to the services people actually use.
Evidence for change
Test the intended security outcome and retain useful operational records.
Establish what the ASA is doing today
We inventory interfaces, routing, address translation, access rules, remote-access and site-to-site VPNs, administrative controls and any special operating mode. The customer identifies the applications and external organisations that depend on the device. A configuration export is the starting point, not a complete explanation of the service.
We also review usage and ownership. Some rules may be unused, while others support occasional processes that will not appear in a short observation period. We distinguish candidates for removal from confirmed obsolete entries. The customer approves any reduction in access so that a migration does not unintentionally become an undocumented security-policy redesign.
Standards & partnerships
Confidence in the team behind your network.
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
Choose a target that supports the requirements
The proposed Cisco platform and management model are checked against the functions actually required. Feature equivalence is not assumed. A supported migration utility may help translate configuration, but it does not guarantee that every feature, policy interaction or operational workflow transfers unchanged.
We identify differences that need a design decision, including NAT behaviour, inspection, VPN authentication, interface layout and logging. Licensing and software compatibility are reviewed before the target is procured or staged. The customer receives a gap register explaining what will be preserved, what changes and which requirements need another solution.
A useful starting point
Not sure where to start?
Bring the requirement. We will help you define the engineering work.
Translate policy with context
Objects and rules are mapped to the intended traffic path rather than copied without review. We examine which addresses a rule matches before and after translation and how return traffic reaches the correct stateful device. A syntactically valid conversion can still produce a different result when NAT order or routing assumptions change.
We also review broad exceptions introduced during past incidents. Where the customer authorises cleanup, those changes are separated and tested. Combining too many unrelated policy changes with a platform cutover makes fault isolation harder. The migration plan identifies the minimum changes needed for the target and any improvements deliberately deferred until the new service is stable.
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 ↗Prepare VPN and identity dependencies
Remote-access clients, certificates, authentication services and partner VPN peers can require coordinated changes. We identify their owners and agree how each connection will be validated. A firewall migration can appear successful for ordinary internet traffic while a rarely used partner tunnel or remote-user group remains broken.
Certificates and secrets are handled through approved secure channels. We plan any change in public addresses, DNS names or trust chains before the window. Client software and profile compatibility are checked separately from the firewall configuration so that users are not asked to solve an endpoint migration during the network cutover.
Stage the new service and rollback
We prepare the target configuration, compare it with the approved mapping and exercise representative traffic where a test environment is available. Physical interfaces, cabling and management access are documented. The staging record identifies what has been tested and what can only be validated against the live external service.
Rollback includes the old device, cabling, routing and any provider-side changes. We define a decision point and the time needed to return to the previous state. Some sessions will need to reconnect even when the network path is restored, so application owners are involved in the recovery plan rather than expecting a configuration backup to solve every consequence.
Cut over with a defined acceptance matrix
The change sequence separates basic forwarding, application access, VPNs and inspection checks. Engineers verify the expected translations and return paths before declaring a service restored. Denied traffic is tested as well as permitted traffic so that the migration does not obtain apparent success by broadening access.
For resilient designs, we exercise agreed failover scenarios and observe the effect on representative sessions. Any test that cannot safely be performed is recorded as unverified. The final acceptance is based on evidence from the actual service, not solely on the migration tool's completion report.
The observation period also checks less frequent workflows identified during discovery, such as scheduled transfers and supplier maintenance. Where those cannot run during the cutover window, they receive a named follow-up test and owner. A successful first morning of browsing is not a reason to discard the recovery plan prematurely.
Retire legacy access and records safely
After the agreed observation period, we remove obsolete credentials, management allowances and unused equipment through the customer's process. Required configuration and audit records are retained appropriately. MCI can then support the target through Cisco Secure Firewall services, with the new policy ownership, software lifecycle and escalation responsibilities made clear in the handover.
Technical references
- Secure Firewall Migration Tool documentation — Cisco / Cisco Meraki
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.