Free planning tool
Cisco ASA to NSX Migration Estimator
How long it really takes to move a Cisco ASA rule base onto the vDefend Distributed Firewall - how many rules you'll actually rebuild, how many application waves it takes, and what sets your end date.
We don't ask for and won't accept firewall configuration through this site. Everything below is calculated in your browser from the numbers you enter.
Most of your ASA rule base isn't going to the distributed firewall
That single fact reshapes the plan. On a typical estate we expect 30% of access-list entries to be dead, shadowed or duplicated, and of what remains only part belongs on the distributed firewall at all.
60%
Distributed Firewall
East-west rules between virtual machines - the bulk of a segmentation project.
32%
Gateway Firewall
North-south rules, plus anything that needs NAT.
8%
Somewhere else
VPN, inspection, physical workloads - not an NSX problem to solve.
Indicative shares of the retained rule base before your own answers adjust them.
Build your micro-segmentation estimate
Only the ACE count really matters. Everything else is pre-filled with the assumptions we use on a typical UK enterprise estate, so you can jump to the results and refine afterwards.
Step 1 of 5 - Your ASA estate
Count the lines, not the access lists. show access-list | include elements gives it quickly. Not sure? A mid-size pair usually lands between 1,500 and 5,000.
1 if single-context.
How long does a Cisco ASA to NSX migration take?
The rule count is the number everyone reaches for, and it is the least useful one in the plan. What decides your end date is how many applications can sit in monitoring mode at once and how long each one has to soak before you enforce. An estate with 3,000 access-list entries and ten application owners who can review flow logs weekly finishes far sooner than a smaller estate where two people are trying to sign off every application in the business.
A realistic programme runs in eight phases: discovery and rule-base analysis, security policy design, NSX and vDefend platform enablement, a pilot application, the application waves themselves, a soak tail after the final wave, ASA decommissioning, and hypercare. The estimator models each separately and then applies uplifts for the things that reliably slow this work down - multi-context ASAs, regulated scope, missing dependency documentation, identity-based rules, and remote-access VPN.
Typical estate benchmarks
| Estate profile | Waves | Typical elapsed time |
|---|---|---|
| 1,200 ACEs, 25 applications, flow data available | 13 waves | 30–36 weeks |
| 3,200 ACEs, 60 applications, partial flow data | 30 waves | 54–60 weeks |
| 3,200 ACEs, 60 applications, Security Intelligence | 30 waves | 44–50 weeks |
| 8,000 ACEs, 150 applications, no flow data | 75 waves | 100+ weeks |
Why rationalisation is the biggest lever
Every ASA rule base of any age carries rules for hosts that were decommissioned years ago, rules shadowed by a broader entry above them, and near-duplicates added by different engineers on different change tickets. On the estates we work with, a quarter to a half of the access-list entries fall into one of those categories. Rebuilding them in NSX carries the mess forward and doubles the work.
Deleting them safely is the hard part, and that needs evidence. With vDefend Security Intelligence or Aria Network Insight watching real traffic, you can prove a rule has not matched in months. Without any flow data, every deletion is an argument, and the safe answer is always to keep the rule - which is why estates with no flow source consistently run longest in this model.
Monitor, soak, enforce - the cadence that sets your timeline
Distributed firewall rules are published in monitoring mode, where they log what they would have blocked without blocking anything. The application sits there for a soak period - two weeks is the sensible default - and the logs are reviewed with the application owner before the rules are enforced. Skip the soak and you will break something at month-end; extend it indefinitely and the programme never finishes.
Because waves overlap in monitoring, the constraint is rarely how fast rules can be written. It is how many applications your business can hold under review at the same time, which is a question about people rather than technology. The estimator tells you which of the two is binding for your estate and what changing it would be worth.
What the distributed firewall cannot do
The vDefend Distributed Firewall enforces at each virtual machine's vNIC. That is its strength and its boundary. It does not perform NAT, it has no remote-access VPN, and it cannot protect physical or bare-metal servers. Those functions move to an NSX Gateway Firewall, to a separate product, or to a small retained ASA footprint at the edge.
Being honest about that at the start is what separates projects that retire the ASA tier from projects that discover in month nine that four hundred Secure Client users have nowhere to go. Talk it through with us before you commit to a retirement date.
Frequently asked questions
How long does a Cisco ASA to NSX migration take?
For a typical estate of around 3,000 access-list entries and 60 applications, plan on 12 to 15 months end to end at a standard pace. That covers rule-base analysis, security policy design, NSX and vDefend enablement, a pilot, then application waves published in monitoring mode and enforced after a soak, followed by ASA decommissioning and hypercare. The rule count matters far less than how many applications your owners can review and sign off at once.
Can NSX distributed firewall replace a Cisco ASA?
For east-west segmentation between virtual machines, yes - and it does it better, because policy follows the workload rather than sitting at a choke point. But the distributed firewall is not a one-for-one ASA replacement. It does not do NAT, it has no remote-access VPN, and it cannot protect physical or bare-metal workloads. Those functions move to an NSX Gateway Firewall, another product, or a retained edge firewall.
Does NSX distributed firewall do NAT?
No. The vDefend Distributed Firewall is a stateful east-west firewall enforced at each VM's vNIC and it has no NAT capability. NAT in NSX is a Tier-0 or Tier-1 Gateway function. Any ASA NAT rules in your configuration need to be re-homed to a gateway, to a physical network device, or removed entirely if the migration to overlay segments makes them unnecessary.
Does NSX replace Cisco AnyConnect or Secure Client?
No. NSX has no remote-access VPN equivalent, so Secure Client users need a different answer before the ASA can be switched off - a dedicated VPN appliance, a ZTNA service, or a small retained ASA pair at the edge. This is the single most common reason a planned full ASA retirement turns into a reduced-footprint outcome halfway through the project.
Do workloads have to move to NSX overlay segments first?
No. The distributed firewall enforces at the VM vNIC and works on VLAN-backed NSX segments and on vSphere distributed port groups, so you can micro-segment workloads exactly where they sit today. Moving to overlay brings other benefits, but making it a prerequisite is the fastest way to stall a segmentation programme before it starts.
What is vDefend and how does it relate to NSX?
vDefend is the current branding for the NSX security portfolio - Distributed Firewall, Gateway Firewall, Distributed IDS/IPS and Security Intelligence. The technology is the same product line that was sold as NSX Security; the name changed with Broadcom's portfolio restructuring. If your documentation says NSX Distributed Firewall and your licensing says vDefend, they are the same thing.
How many ASA rules will we actually have to rebuild in NSX?
Fewer than you think. On a mature ASA rule base that has not been audited for years, typically 25% to 50% of access-list entries are dead, shadowed, duplicated, or reference decommissioned hosts. With flow data to prove it, that share can be removed rather than rebuilt. This estimator's rationalisation factor is the number that moves most between a web estimate and a real plan, because it can only be settled by reading rules against real traffic.
What is monitoring mode and why does it dominate the timeline?
Monitoring mode publishes distributed firewall rules that log matches but do not block. You leave an application in monitoring for a soak period - typically two weeks - and review what would have been dropped before you enforce. Because each application must soak, and because only so many applications can be under review at once, most programmes are limited by soak capacity rather than by how fast rules can be written.
How long should the soak period be?
Two weeks is the sensible default. It catches daily and weekly batch jobs, weekend backup windows and most reporting cycles. One week misses weekly jobs; anything under a week is only defensible with strong flow data from a tool like vDefend Security Intelligence. Month-end and quarter-end processes argue for a longer soak on finance-adjacent applications specifically, rather than lengthening every wave.
Do we need flow data before starting micro-segmentation?
You can start without it, but it costs you. Flow data - from vDefend Security Intelligence, vRealize/Aria Network Insight, or even NetFlow - lets you delete rules with confidence, build groups from observed behaviour rather than guesswork, and shorten soaks. Starting with no flow source typically adds several months to an estate of this size and pushes far more work into interviews and manual analysis.
Should we translate ASA rules one for one into NSX?
No. A rule-for-rule port is faster to build and it is the version of this project that fails. ASA policy is zone-based and address-based; NSX policy is tag and group based, expressed in application terms and applied per workload. Carrying across the IP-literal structure of an access list gives you the same unmanageable rule base in a new product, and none of the benefit.
What licensing do we need for the NSX distributed firewall?
The distributed firewall requires a vDefend security licence on top of NSX networking entitlement, licensed per protected workload. Distributed IDS/IPS and Security Intelligence are separately entitled. Licensing sits outside this estimate; we can size it with you as part of a scoping conversation.
Related services and tools
VMware Cloud Foundation
Design, build and operate the platform NSX and vDefend run on.
Read moreVCF Design
Network and security design, including NSX topology and firewall policy structure.
Read moreVCF Migration Estimator
Planning the workload move as well? Size the migration alongside the segmentation.
Read moreReady to pressure-test these numbers?
We'll review a redacted ASA configuration at no charge and tell you honestly how much of it needs rebuilding. Thirty minutes, no obligation.