Verify a migration from Oxidized, RANCID or SolarWinds NCM to rConfig with an AI agent

Verify a migration from Oxidized, RANCID or SolarWinds NCM to rConfig with an AI agent

The import worked, rConfig shows a few thousand devices, and the old tool is due to be switched off. The question nobody wants to answer by hand: is everything really in rConfig, and is it backing up? An agent with the old archive on disk and rConfig connected over MCP can check every device in an afternoon.

Best for: the weeks after a migration, before the old tool is retired. Tools: rConfig, the old tool’s archive (an Oxidized or RANCID Git repository, or an export from NetMRI or SolarWinds NCM), an agent that can read local files (Claude Code, Codex CLI, Cursor, VS Code). rConfig tools used: get_devices, get_device, get_latest_config, search_configs.

What to check, in order

1. Coverage: every device in the old tool exists in rConfig, matched by hostname or IP.
2. Backups: every device in rConfig has a recent successful backup (last_config_at) and a status of Reachable, not Unreachable or Config Failed.
3. Content: for a sample of devices per vendor, the configs say the same thing, allowing for expected differences.

Coverage and backups matter most. A device that’s missing or failing in rConfig is a device with no backups once the old tool is gone.

The prompt

The Oxidized repository is checked out in ./oxidized-configs, one file per device.

1. List every device in it, then find each one in rConfig by name (use get_devices). Report devices missing from rConfig.
2. For devices that are in rConfig, report any whose last_config_at is more than 2 days old or whose status isn’t Reachable.
3. For five devices per vendor, compare the Oxidized file with rConfig’s latest running config. Ignore secrets (rConfig obfuscates them), timestamps, and comment lines. Report real configuration differences only. Write the results to migration-report.md.

An illustrative summary:

Devices in Oxidized: 1,284   Found in rConfig: 1,279
Missing from rConfig (5): par-acc-31, par-acc-32, ... (all in the PAR-ACCESS group)
No backup in 2+ days (12): mostly Fortinet, status: Unreachable
Content sample (40 devices): 38 match; 2 differ (lon-fw-01 has 3 extra
address objects in rConfig, added after the Oxidized repo stopped updating)

Expected differences

Tell the agent about these up front, or it will report them as problems:

• Secrets: rConfig obfuscates passwords and keys in what it returns. Lines with secrets will always differ.
• Collection commands: Oxidized models and RANCID scripts filter output their own way (removing changing counters, adding comment headers). rConfig stores the output of the commands in its templates.
• Time: the old tool stopped collecting at some point. Differences dated after that are real changes, not migration errors.

Limits to know

• Name matching. If hostnames changed during the migration, give the agent the mapping or match on IP address.
• Large estates. Coverage and backup checks use device metadata only and scale well. Keep content comparison to a sample.
• Exports from commercial tools. For SolarWinds NCM and NetMRI, export the device list and latest configs to files first; the agent reads files, not the old tool’s database.

Related reference

• Oxidized import
• RANCID import
• SolarWinds NCM import
• NetMRI import