NetPilot

Network Migration Lab

Rehearse a vendor switch migration on a mirror lab — test the new CLI, validate translated configs, prove failover first.

Watch Demo
app.netpilot.io

See It in Action

Watch NetPilot build a multi-vendor lab from a single description — the same loop a migration rehearsal runs on.

Why migrations get rehearsed in a lab

~2 min
from configs to a runnable mirror of both vendors
9+
network OSes in one lab — any ContainerLab-compatible NOS on enterprise
Free
AOS-CX simulator image from HPE's Aruba Support Portal — no image license needed to start
$5,600
average cost of network downtime per minute (Gartner)

A migration is the highest-stakes form of change. Validating a config change on the vendor you already run? Network Change Validation covers that workflow; for agent-run traffic, impairment, and convergence tests, see the Network Testing Lab.

How NetPilot differs for vendor migrations

Translation is the easy half of a migration. NetPilot runs both vendors side by side, validates the translated configs on real NOS code, and lets you rehearse the cutover before the window.

Both sides in one lab

The current network and the target vendor run side by side — the agent builds both from your real configs in ~2 minutes.

The alternative

DIY EVE-NG / GNS3 migration rigs take days of image hunting and wiring before the first translated config ever loads.

Translation validated, not trusted

Translated configs load onto running NOS code; the agent diffs behavior against current state and flags what the converter missed.

The alternative

Conversion tools stop at syntax — netconverter.ai and HPE's online translator hand you a config nobody has ever booted.

Cutover rehearsed, not improvised

Parallel-run the vendors, move segments one at a time, fail links, and time each cutover step before the window.

The alternative

For most teams, the first end-to-end run of the migration plan is the production maintenance window itself.

Multi-vendor by design

9+ network OSes and growing in one lab — Aruba AOS-CX and Dell OS10 via BYOI on Signature & Enterprise; SSH to every CLI.

The alternative

Cisco CML is the reference for official Cisco images but single-vendor — a vendor swap needs both sides running.

The migration rehearsal loop, in product

Configs in, evidence out. The agent builds both sides, translates and validates, and rehearses the cutover with you — real CLIs one SSH away at every step.

Import both sides of the migration

Describe the current network and the target vendor in plain English, or paste sanitized configs from the gear being retired. The agent designs both topologies and deploys them on real NOS images in ~2 minutes.

app.netpilot.io

Translate, load, and diff behavior

The agent translates the configs to the target NOS, loads them on running images, and compares behavior against the current-state baseline — VLANs, routing adjacencies, spanning tree, failover — flagging what a syntax converter cannot see.

app.netpilot.io

Rehearse the cutover, keep the evidence

Move segments, fail links, time each step, and practice rollback — then walk into the maintenance window with a rehearsed plan and CLI-evidenced results. SSH into any device to verify by hand.

app.netpilot.io

Migrations you can rehearse

Each of these is a real migration job — cross-vendor, generational, firewall, and storage. Describe yours in plain English and the agent builds the rehearsal lab.

Cisco → Aruba core refresh

Translate IOS to AOS-CX — VLANs and trunks, StackWise to VSX, RPVST to MSTP — and validate the translated core on a running AOS-CX image (BYOI, Signature & Enterprise) before hardware ships.

Comware / ProCurve retirement

Retiring HP Comware or ProVision/ProCurve gear? Rebuild the config logic on the successor NOS in the lab and verify the parts no converter maps cleanly.

ASA → FortiGate firewall swap

Rebuild ASA policy as FortiGate policy and prove equivalent behavior — NAT, inspection, HA failover — with real traffic in the lab before the swap.

Catalyst 3850 → 9300 refresh

Generational refreshes break in the details — stacking behavior, defaults that shifted between IOS-XE trains. Stage the 9300-side config and diff it against the 3850 baseline.

iSCSI / storage failover validation

Storage traffic is the migration's highest-stakes passenger. Model the iSCSI path on the new switching layer (Dell OS10 via BYOI, Signature & Enterprise) and prove failover before data rides it.

Parallel-run old + new vendor

Run both vendors in one lab, bridged the way your transition will be — verify trunking, spanning tree, and gateway redundancy across the boundary, segment by segment.

Build the mirror from real data, not a hand-typed approximation: NetBox, Nautobot, and Nornir connectors are built in — the agent reads your NetBox/Nautobot source of truth and runs read-only show commands against your live network, minutes after you add a connector from the chat. They're the starting point: with Signature & Enterprise, NetPilot connects to anything MCP-enabled.

NetPilot vs migration alternatives

Head-to-head across DIY lab stacks, translation SaaS, Cisco CML, and NetPilot. Converters keep the fast first pass; CML keeps official Cisco images — NetPilot owns the rehearsal: both vendors running, behavior diffed.

Primary use case
NetPilot
Agent-built migration rehearsal — both vendors in one lab
DIY EVE-NG / GNS3
Hand-built labs on your own hardware
netconverter.ai
Cisco-to-Aruba config translation SaaS
Cisco CML
Cisco-platform labs on official images
Config translation
NetPilot
Agent translates — then validates it on running NOS
DIY EVE-NG / GNS3
Manual — spreadsheet mapping
netconverter.ai
Fast automated Cisco → AOS-CX conversion
Cisco CML
Not a translation tool
Validates on running NOS code
NetPilot
Old and new side by side, behavior diffed
DIY EVE-NG / GNS3
Real images — wired by hand over days
netconverter.ai
Stops at translation — the output never boots
Cisco CML
Cisco NOS only
Old + new vendor in one lab
NetPilot
9+ NOSes and growing — BYOI for the rest
DIY EVE-NG / GNS3
BYOI both sides, hand-wired
netconverter.ai
No lab
Cisco CML
Single-vendor
Time to first migration lab
NetPilot
~2 minutes from configs
DIY EVE-NG / GNS3
Days to weeks of setup
netconverter.ai
Minutes — but conversion only
Cisco CML
Install + licensing first
Cisco image fidelity
NetPilot
Cisco IOL via BYOI
DIY EVE-NG / GNS3
Depends on the images you source
netconverter.ai
No lab
Cisco CML
Official Cisco images — the reference
Cost model
NetPilot
Free tier + enterprise plan
DIY EVE-NG / GNS3
Free and offline — your hardware, your time
netconverter.ai
Web SaaS, translation only
Cisco CML
Free 5-node tier; $199/yr for 20 nodes

Where NetPilot fits vs migration alternatives

Pick DIY lab stacks, translation SaaS, and Cisco CML when you need:

  • •DIY EVE-NG / GNS3 for a free, fully offline rehearsal rig on hardware you own
  • •netconverter.ai and HPE's online translator for a fast first-pass config conversion
  • •Cisco CML for Cisco-only labs on official Cisco images

Pick NetPilot when you need:

  • •Agent builds current-state and target-state labs from your real configs in ~2 minutes
  • •Translated configs validated on running NOS code — behavior diffed, not just syntax-checked
  • •Parallel-run, failover, and cutover-order rehearsal across both vendors in one lab
  • •9+ network OSes and growing — FortiGate via BYOI; Aruba AOS-CX and Dell OS10 via Signature & Enterprise custom vendor support
  • •CLI-evidenced results for the change board — SSH into any device to verify by hand

Verdict:Translation tools hand you a config; a migration needs proof it works. NetPilot is the agent-run choice for rehearsing the vendor swap — both vendors running, behavior diffed, cutover practiced — before the maintenance window.

Frequently Asked Questions

Common questions about rehearsing a vendor migration in a lab

A network migration lab is a rehearsal environment for a network migration — a vendor swap, a hardware refresh, or a platform retirement — where the current network and the target network run side by side as virtual devices so the migration can be tested before the maintenance window. Typical uses: verifying that translated configs actually behave on the new NOS, learning the new vendor's CLI on a running device, proving failover and gateway redundancy on the new platform, and timing the cutover steps. NetPilot is an AI-native migration lab: the agent builds both sides from plain English or sanitized configs in ~2 minutes on real network OS images, and every device keeps a real CLI via SSH.
Yes. A virtual network lab runs the same network OS code your switches run, so migration behavior — routing, VLANs, spanning tree, failover — is testable without racking a single device. In NetPilot you describe the current and target networks in plain English (or paste sanitized configs) and the agent deploys a runnable multi-vendor mirror on real NOS images in ~2 minutes: the outgoing vendor's config on one side, the translated config on the other. You rehearse the migration there — verify the translated configs, run failover, practice the cutover order — and touch real hardware only when the window opens. Real CLIs stay one SSH away for hand verification.
Run them. A translated config that parses is not a config that works — interface naming, VLAN semantics, spanning-tree defaults, and failover mechanics all differ between vendors. The reliable check is behavioral: load the translated configs onto the target vendor's real NOS in a lab, bring up the same adjacencies, and compare behavior against the current network — routing tables, VLANs and trunks, gateway redundancy, failover timing. In NetPilot the agent builds current-state and target-state labs from your real configs, applies the translation, diffs the behavior between them, and flags mismatches; you SSH in to confirm the ones that matter by hand. Conversion tools like netconverter.ai and HPE's online config translator stop at the translation — the lab is where you find out whether it works.
Yes, as a bring-your-own-image NOS on the Signature and Enterprise plans: custom vendor support covers Aruba AOS-CX, Dell OS10, and any other ContainerLab-compatible image — built for you, running alongside the other vendors in your migration. HPE distributes the AOS-CX simulator image free through the Aruba Support Portal (an ASP account is required), so the image itself does not need a paid license. Nokia SR Linux, FRR, and Linux are built in, and Cisco IOL, Juniper cRPD, Arista cEOS, Palo Alto, and FortiGate are self-serve BYOI on Pro — 9+ network OSes and growing.
Yes — parallel-run is a first-class migration scenario. Build one lab holding both environments: the outgoing vendor's switches with current configs and the incoming vendor's with translated configs, interconnected the way your cutover plan will bridge them. Then prove the interop that parallel operation depends on — VLAN trunking and spanning tree across the vendor boundary, gateway-redundancy handoff, routing adjacencies between old core and new core — and practice moving segments one at a time with a rollback path at each step. The agent rewires the lab conversationally ('move access-pair 3 behind the new core'), so every phase of the cutover plan gets rehearsed, not just the end state.
Yes. NetPilot is a cloud-hosted network sandbox: an isolated, disposable environment running real network OS images — 9+ and growing — where you build and break topologies without touching production. What distinguishes it from a generic sandbox is the agent: describe the network in plain English and it designs the topology, writes per-vendor configs, deploys in ~2 minutes, and validates the result, with real CLIs via SSH on every device (an on-prem option exists on the enterprise plan for air-gapped environments). For migration work the sandbox holds both sides — outgoing and incoming vendors in one lab — so the cutover gets rehearsed there instead of improvised in the window.
Scope. Change validation tests a config change to the network you already run — a BGP policy edit, an ACL update — against a mirror lab before it ships. A migration lab tests a change of platform: a different vendor's NOS with different syntax, defaults, and failover mechanics, and a multi-week cutover plan rather than a single change window. The mechanics overlap — both run real NOS code in a mirror lab — but migration rehearsal adds config translation, side-by-side old/new behavior comparison, interop between the two vendors during the transition, and cutover-order practice. NetPilot covers both jobs: this page is the migration lane; the Network Change Validation page covers the config-change lane.

Related resources

Cisco to Aruba (AOS-CX) Migration Lab

The full walkthrough — IOS-to-AOS-CX translation table, VSX design mapping, and lab validation before cutover.

Switch Migration Checklist

The rehearsal-first checklist — inventory, feature mapping, translation, lab validation, parallel-run, rollback.

Aruba CX Simulator & Lab Options

Every way to run AOS-CX virtually — the official simulator, EVE-NG, GNS3, and the cloud route compared.

Network Change Validation

The config-change lane — mirror-lab pre/post snapshot validation for BGP, ACL, and routing changes.

AI Network Testing Lab

The agent runs the tests — traffic generation, impairments, QoS, convergence, NRFU, and cutover rehearsal.

Rehearse Your Network Cutover

Why lab-tested changes still blow the window — and how a timed rehearsal catches it first.

Rehearse the migration before the window

Import configs from both vendors, get a runnable mirror lab in ~2 minutes, and walk into cutover with evidence.

Try It Free