Free IOS to NX-OS Translation Tool — Why I Built It and How It Works

If you’ve ever migrated a campus or data center from IOS to NX-OS, you know the drill. You’re staring at a running config that’s been copy-pasted and tweaked for a decade, and now you need to make it work on a Nexus platform that does everything slightly differently.

Interface naming changes. STP syntax changes. HSRP moves to a completely different command structure. Features that were on by default in IOS suddenly need explicit activation in NX-OS. And you’re doing this across dozens — maybe hundreds — of switches, each with their own accumulated config drift.

Every network engineer I know does this the same way: manually. Line by line. Maybe with a notepad open on a second monitor listing the syntax differences they’ve memorized. Maybe with a spreadsheet if they’re organized. And inevitably, something gets missed. A spanning-tree portfast becomes a forgotten spanning-tree port type edge. A standby group doesn’t get translated to hsrp. An ACL that worked fine on IOS throws an error on NX-OS because the syntax rules are subtly different.

It’s tedious, error-prone, and it’s 2026. We shouldn’t still be doing this by hand.

Where This Started

I’m Brad McCloskey, CCIE #34678. I’ve been in networking for 26 years, and I’ve done my share of platform migrations. But the one that really drove this home was a major migration at a large venue — going from NX-OS back to IOS.

That project involved converting the entire network infrastructure — every switch, every config. The stakes were high. Downtime wasn’t an option. And the sheer volume of configuration that needed to be translated accurately between the two platforms was massive.

Early on, I started building a spreadsheet mapping every command difference between IOS and NX-OS. Feature activation requirements. Edge cases where the translation wasn’t one-to-one. Syntax that looked similar but behaved differently. That spreadsheet grew into a comprehensive reference document covering hundreds of command mappings.

After the project wrapped, I kept thinking about how many engineers are doing this same translation work right now — in either direction — on their own, without that reference. So I built it into a tool. I started with IOS-to-NX-OS since that’s the more common migration path in the industry, and the command mapping works the same way regardless of which direction you’re going.

What the Translator Actually Does

The IOS to NX-OS translator at ciscotools.dev takes a block of IOS configuration and converts it to valid NX-OS syntax. You paste your config in, and you get a translated config out.

But it’s not doing simple find-and-replace. That’s what makes it different from a regex script you’d hack together in an afternoon.

The translator understands IOS configuration hierarchy. It knows that when you’re translating interface configs, it’s not just about swapping interface GigabitEthernet for interface Ethernet — it needs to handle the entire interface context, including switchport modes, trunk configurations, and access settings that may need restructuring for NX-OS.

Here’s what it handles:

Interface configurations — naming conventions, switchport syntax, descriptions, speed/duplex
VLANs — VLAN database entries and interface VLAN assignments
Spanning Tree — portfast to port type edge, BPDU guard, STP mode translations
HSRP and VRRP — the complete restructuring from IOS standby commands to NX-OS hsrp/vrrp command blocks
Access Control Lists — numbered and named ACLs with the syntax adjustments NX-OS requires
Routing protocols — OSPF, BGP, and EIGRP with their respective NX-OS configuration differences
Port-channels — LACP and static channel-groups with the NX-OS feature lacp activation
SNMP — community strings, trap receivers, and v3 configurations
NTP — server and peer configurations
Logging — syslog destinations and severity levels
AAA — authentication, authorization, and accounting configurations

Critically, it also generates the feature activation commands that NX-OS requires. This is one of the biggest gotchas engineers hit during migrations — you paste in a perfectly valid OSPF config, but NX-OS won’t accept it because you haven’t run feature ospf first. The translator identifies which features your config requires and includes those activation commands at the top of the output.

What It’s Not

This isn’t a magic “press button, migrate network” tool. It translates configuration syntax. It doesn’t know your network topology, it doesn’t validate that your design makes sense on Nexus hardware, and it doesn’t replace the engineering judgment you need for a real migration.

What it does is eliminate the grunt work. Instead of spending hours translating syntax line by line, you spend minutes reviewing and validating a translated config. You’re still the engineer making the decisions — the tool just handles the mechanical translation so you can focus on what actually matters.

The Other Tools

While I was at it, I built a few other tools that I kept wishing existed:

Config Diff — paste two configs side by side and get a clean, structured diff. Useful for change validation, troubleshooting, and figuring out what actually changed between two versions of a config.

Config Sanitizer — strips passwords, SNMP community strings, and other sensitive data from configs before you paste them in a forum post or share them with a vendor. Anonymizes IP addresses too.

Template Manager — build and manage reusable config templates with variables. Useful for standardizing deployments across multiple sites or devices.

All free. No login. No account required.

Try It

The translator and all the other tools are live at ciscotools.dev. Paste a config in, see what comes out.

If you find something that doesn’t translate correctly, or there’s a feature mapping I missed, I want to hear about it. These tools get better with feedback from engineers who are actually using them in production migrations.

And if you’re staring down a major IOS-to-NX-OS migration and want hands-on help from someone who’s been through it — reach out. That’s what I do.