When the spreadsheet stops being trustworthy
The new branch needs a subnet by tomorrow. Excel shows a free /24, a Cisco switch still carries an undocumented VLAN, and Zabbix already sees an address inside that supposedly unused range. Before touching the MikroTik VPN, someone has to establish which record is authoritative. Creating the VLAN is straightforward; knowing whether the change is safe is the difficult part.
Use a hypothetical company with five branches, 40 physical and virtual servers in total, 60 Cisco switches, 15 MikroTik routers and 10 ESXi hosts. Several VLANs, WAN/VPN links, Zabbix and Ansible complete the picture. These are design scenarios, not claims about a client deployment or a measured benchmark.
A duplicate address in isolated VRFs can be intentional; the same duplication in one routing domain can cause an IP conflict. A stale serial number misleads replacement planning. Missing cable records turn a failed uplink into a rack-by-rack search. An unrecorded emergency CLI change creates configuration drift: actual state no longer matches the approved design.
A central model exposes inconsistencies and supplies stable automation inputs. It does not stop an engineer assigning an address outside the process, repair a failed link or decide whether an emergency change should become policy. Selecting the software must include assigning data owners, defining a change path and agreeing reconciliation rules.
Review baseline and evidence boundaries
The documentation baseline checked on 6 November 2026 is NetBox Community 4.7.4 and Nautobot open source 3.2.8. NetBox Labs products and Network to Code commercial editions are identified separately. Device42 is a commercial appliance; its documentation index lists 19.09.00, but that release page returned 403. Device42 statements below use accessible current feature documentation, not a verified 19.09.00 installation or guaranteed bundle entitlement.
No comparative product installation or performance test was performed. Staffing, deployment and economic recommendations are engineering judgments under stated assumptions. Pin App versions against compatibility matrices: an App feature is not automatically a core feature or compatible with every release.
Seven terms that lead to different architectures
DCIM, Data Center Infrastructure Management, models physical placement: a rack position, a cable path or a circuit termination. IPAM, IP Address Management, models address space, allocations and routing contexts. A spreadsheet can record either; preserving their relationships consistently is harder.
A CMDB, Configuration Management Database, relates configuration items to services: payroll depends on a VM, an operating system and a database. IT Asset Management follows purchase, ownership, warranty and retirement. One switch can be an asset, a configuration item and a DCIM device; those views answer different questions.
Discovery collects observations through SNMP, SSH or hypervisor APIs. An Infrastructure Source of Truth stores authoritative decisions: approved prefixes, roles and intended VLAN membership. Network automation consumes those decisions, renders a plan and executes it through a runner. Discovering a VLAN establishes that it exists, not that it is authorised.
NetBox starts with a detailed infrastructure model. Nautobot combines a network model with an extensible automation platform. Device42 prioritises discovery and related inventory/CMDB records. Comparing only their inventory screens hides the decision that matters.
NetBox: organise the design before automating it
NetBox natively models IPv4/IPv6 prefixes and addresses, VLANs, VRFs, sites, racks, devices, interfaces and cables. Circuit records associate providers with terminations. Virtualisation objects describe clusters, VMs and interfaces. Recording a VM is a model capability, not proof of live vCenter synchronisation.
The value appears when Ansible requests active access switches at one site and receives management addresses, roles and context through REST or an inventory integration. Native configuration rendering combines templates with context; deployment belongs to an external executor or custom integration. GraphQL is also native. Claiming that only Nautobot offers it would be wrong.
Core NetBox is not a full discovery engine, a network monitor or a ready-made multi-vendor configuration deployment service. NetBox Labs offers separate Discovery and Assurance products; assess licensing and ingestion separately. Plugins/scripts can add collectors, but their maintenance becomes part of your platform.
Assign ownership at field level. The network team owns prefixes and roles; the virtualisation team supplies VM identity. An import job proposes observed serial changes without overwriting approved roles. Define stale-data deadlines and review exceptions, otherwise the source of truth becomes a better-looking spreadsheet.
NetBox scope and desired-state philosophy
Nautobot: make the workflow a maintained product
Nautobot began as a fork of NetBox 2.10.4 and developed its own model and lifecycle. It is not a skin over an existing NetBox database. Native REST, GraphQL, Jobs and Git data sources supply extension points. Jobs run Python logic through workers; useful workflows still need code, permissions, credentials and failure handling.
Golden Configuration is a separately installed open-source App. Documented workflows include intended configuration generation, backup, comparison, remediation and deployment. Nornir-based paths exist; Ansible is an integration choice, not a mandatory dependency for every workflow. Device Onboarding is another App with a platform matrix, not universal zero-touch discovery.
Current documentation separates Professional, Enterprise and managed Cloud from the open-source core. Supported discovery, packaged operations and additional commercial Apps require an edition check. Free Jobs and Golden Config do not imply every advertised commercial automation package is free.
For the reviewed Nautobot 3.2.8 baseline, the published matrices cover Golden Config 3.0.x and Device Onboarding 5.5.x. Device Onboarding release notes also list 5.6, while the compatibility table stops at 5.5; do not infer an unlisted combination. Device42 ADM requires Enterprise Application Discovery enabled in the license, plus the discovery job option and sampling configuration.
A VLAN change across 100 Cisco switches
Suppose VLAN 230 must reach 24 access switches out of 100. Select targets by location, role and lifecycle status. Validate VLAN scope, reserved IDs, uplink paths and exclusions. Render a per-device plan from versioned Jinja templates and retain both the template commit and input-data snapshot.
A native Job can orchestrate validation. A compatible Golden Config App supplies intended-state/compliance functions. An Ansible/AWX runner can execute vendor tasks through a custom Job-to-runner adapter passing an immutable plan ID. Native Job approval controls exist; the organisation must still define approvers, protected changes and maintenance windows. A technical approval is not an ITSM policy.
Recheck the snapshot, capture configuration, verify management reachability and start with one canary. Compare VLAN/trunk state afterwards and continue in small batches with stop conditions. IOS/IOS XE behaviour and module support need testing on the actual release. Ansible check mode alone cannot prove a trunk change is safe.
Rollback needs a tested inverse change or platform-specific restore procedure, out-of-band access and explicit abort rules. Database transactions cannot undo CLI commands already accepted by switches. RouterOS execution needs tested collections/API adapters; the reviewed onboarding matrix does not establish equivalent MikroTik support.
Nautobot stack and fork history
Git sources and code execution trust
Device42: establish what is actually there
Consider another hypothetical estate: 200 VMs, 20 physical servers, several ESXi hosts, Cisco networking and mixed Windows/Linux servers. Inventory is incomplete. Recreating it manually may cost more engineering time than a discovery subscription. Device42 deserves a pilot here because observations and relationships are the initial bottleneck.
Start with explicit vCenter endpoints and a dedicated account allowed to view the required host/VM inventory. The documented default is HTTPS port 443; each vCenter must be added separately. Hypervisor discovery supplies host/VM inventory relationships. Guest software and process dependencies require corresponding OS-level discovery and sufficient permissions.
Supported network devices expose identity, interfaces, VLANs and address/port associations through SNMP. Neighbour information depends on exposed CDP/LLDP data and credentials. Prefer read-only SNMPv3 with ACLs. A discovered MAC is not a guaranteed cable map: hypervisors, phones, trunks and stale tables complicate interpretation.
Linux/UNIX discovery uses SSH, including keys; selected data requires scoped sudo commands. Windows has documented WinRM and WMI paths with platform-specific permissions. Do not assume unrestricted domain administration is required by default. Test documented permissions on a representative host, record unavailable fields and expand access only for an approved requirement.
Dependency mapping uses observed service/communication evidence. It helps assess migration and incident impact, but a nightly batch absent during the observation window can be missed. Business ownership, criticality and approved retirement dates still need validation. Hardware lifecycle and warranty records support asset management; discovery cannot infer procurement decisions or guarantee every contract detail.
Agentless does not mean credentialless. Pilot one range, place collectors according to segmentation, schedule concurrency and exclude fragile devices. Test account lockout and certificate validation; protect process/software data and audit credential use. Device42 also supports agent-based methods. Its IPAM/DCIM views are useful, but discovered occupancy is not an approved address allocation.
VM discovery: scope and credentials
SNMP discovery: fields and constraints
Linux SSH discovery and privileges
Discovery access, scope and operational requirements
Feature comparison without misleading checkmarks
Native means reviewed core capability; Plugin-Based means an installed extension; Integration-Based means an external system or custom adapter. Commercial denotes a paid product/entitlement. Not Available is scoped to the named core function; Not Verified means the evidence does not establish support. Combined labels are intentional. These paths do not imply equal effort or maturity.
| Feature | NetBox Community 4.7.4 | Nautobot OSS 3.2.8 | Device42: current appliance docs |
|---|---|---|---|
| Licensing | Native: Apache-2.0 core; Commercial services separate | Native: Apache-2.0 core; Commercial editions separate | Commercial: annual device-based subscription |
| IPAM | Native: IPv4/IPv6, prefixes, VRFs | Native: IPAM; migration semantics differ | Commercial / Native: IPAM |
| DCIM | Native: racks, devices, cables, circuits | Native: racks, devices, connectivity | Commercial / Native: DCIM |
| CMDB | Integration-Based: service CMDB; core network model | Integration-Based / Plugin-Based: service CMDB | Commercial / Native: CMDB relationships |
| Automatic Discovery | Not Available in core; Integration-Based / Commercial collectors | Plugin-Based: Onboarding; Commercial discovery packages | Commercial / Native: scheduled discovery |
| Network Automation | Native rendering/scripts; Integration-Based deployment | Native Jobs; Plugin-Based Golden Config; Integration-Based runners | Integration-Based: API to external automation |
| Configuration Compliance | Plugin-Based / Integration-Based; no turnkey core engine | Plugin-Based: Golden Config; data validation is distinct | Not Verified: equivalent intended-config engine |
| VMware Integration | Native VM model; Integration-Based vCenter sync | Native VM model; Integration-Based / App-specific sync | Commercial / Native: hypervisor discovery |
| Cisco Integration | Native inventory; Integration-Based execution | Plugin-Based onboarding per OS; Integration-Based execution | Commercial / Native: supported SNMP/UCS/ACI paths |
| MikroTik Integration | Native inventory; Integration-Based RouterOS execution | Integration-Based execution; onboarding parity Not Verified | Not Verified: model-specific discovery parity |
| Ansible Integration | Integration-Based: inventory/API collections | Integration-Based: collections and Job-to-runner adapter | Integration-Based API adapter; official collection Not Verified |
| REST API | Native | Native | Commercial / Native |
| GraphQL | Native | Native | Not Verified: supported public GraphQL |
| Git Integration | Native synchronized data; Integration-Based CI | Native data/Jobs sources; Integration-Based CI | Integration-Based export/API; Native sync Not Verified |
| High Availability | Integration-Based: redundant app, DB/Redis design | Integration-Based: documented distributed HA design | Commercial / Native: warm backup/restore standby |
| Multi-Site Management | Native sites/locations | Native hierarchical locations | Commercial / Native: locations and collectors |
| Scalability | Integration-Based: DB/workers/query tuning; benchmark locally | Integration-Based: DB/Celery/job tuning; benchmark locally | Commercial: appliance/collector sizing; benchmark locally |
| RBAC | Native object permissions | Native object permissions and Job controls | Commercial / Native role controls |
| Backup & Restore | Native DB tools + Integration-Based recovery runbook | Native DB tools + Integration-Based recovery runbook | Commercial / Native appliance manager |
| Maintenance Complexity | Integration-Based operations: Python, PostgreSQL, Redis, plugins | Integration-Based operations: Python, DB, Redis/Celery, Apps/Jobs | Commercial appliance operations, collectors and credentials |
| Total Cost of Ownership | No core fee; engineering time; Commercial support optional | No core fee; workflow ownership; Commercial editions optional | Commercial subscription plus operations and integration |
The classification labels remain in English for procurement matching; row explanations are localised. A Not Verified entry does not mean an integration is impossible. Ask for a demonstration against your exact hardware, RouterOS version and required fields. Device42 feature availability also needs confirmation in the quoted bundle.
The work that starts after installation
Installation and database responsibility
For a VMware team, a Device42 appliance may be the shortest route to a working UI. Credentials, firewall paths and reconciliation still dominate time to useful data. NetBox needs Python/Django, PostgreSQL, Redis and workers. Nautobot supports PostgreSQL or MySQL with Redis/Celery. Current stack docs list PostgreSQL 15+ for NetBox, and PostgreSQL 14+ or MySQL 8.0.11+ for Nautobot. Verify pinned-release requirements instead of reusing an old installation guide.
Device42 manages its internal database within the appliance lifecycle; its internal engine/version was not verified here. Do not assume direct database editing or self-managed database administration is supported. Obtain supported sizing and recovery procedures for the evaluated build.
Upgrades are compatibility projects
A lightly extended NetBox has fewer compatibility surfaces than a platform with many custom Jobs and Apps. This is an architectural judgment, not a measured installation race. Stage upgrades with pinned dependencies, schema migrations and plugin checks. Nautobot also needs Job imports, queues, App models and dispatchers tested: a working web UI does not prove workers can execute automation.
Device42 uses vendor update packages and appliance procedures. Check Main Appliance/Remote Collector compatibility and back up first. Packaging reduces installation work but does not eliminate maintenance windows. After schema changes, rollback across all three generally requires matching pre-upgrade data and files, not merely an older container image.
Backup, restore and availability
For NetBox/Nautobot retain consistent database dumps, uploaded media, configuration, secret keys, custom code and dependency locks. Restore in isolation with matching versions; test relationships, counts, permissions and representative API queries. Redis is not the authoritative inventory backup. Restoring queues blindly may replay stale work.
Device42 Appliance Manager provides scheduled/on-demand backup and restore. Restore documentation requires identical source and destination versions. Its warm HA periodically restores backups into a standby appliance, so recovery has backup-age exposure and takeover time. It is not synchronous active-active HA or a zero-data-loss promise.
Redundant web processes alone are insufficient. NetBox/Nautobot HA also requires database failover, Redis/task design, shared media, load balancing and prevention of duplicate scheduled writes. Measure API latency, database growth, queue delay, scan duration and recovery time with real workloads. Device count alone is not a product scaling limit.
NetBox data/configuration/media recovery
Nautobot database and worker requirements
The inventory platform is a privileged system
Separate inventory readers, data editors, Job operators and platform administrators. NetBox/Nautobot provide object permissions; test site/team boundaries in both UI and API. Device42 REST enforces configured roles and documents Basic and Token authentication. Use TLS and scoped service identities; inventory access should not inherit an engineer’s unrestricted administrator role.
Store device credentials in a supported secrets backend or runner vault, not custom fields, Git templates or logs. Nautobot secret-provider abstractions require a configured provider; installing the application does not deploy a vault automatically. Restrict runner access, redact configuration backups and rotate secrets independently of inventory records.
Git sources supplying Jobs are executable code. Restrict repository definitions and protected branches; review dependencies and isolate workers. Native change logs help, but the full audit must join the ticket, approved plan, data snapshot, template commit, runner identity and post-check results. A database change log alone does not prove which commands reached a router.
Five estates, five different starting points
A. One site, five servers, ten network devices, one engineer
A minimal NetBox is the first candidate if address allocation and cabling already cause mistakes. With stable records and rare changes, a controlled register may cost less than another service. Start with prefixes, management interfaces and ownership. Device42 is difficult to justify solely for 15 inventory entries unless audit obligations or expensive discovery gaps change the economics.
B. Five branches, 50 servers and 100 network devices
With VMware, Zabbix and existing Ansible playbooks, NetBox is a strong default when reliable inventory is missing. Keep the proven runner and supply authoritative targets. Choose Nautobot if the team can maintain Python Jobs and recurring shared workflows such as onboarding/compliance. Device42 earns a case when time spent finding unknown VMs and dependencies exceeds subscription and discovery operations costs.
C. Fifty branches, 500 servers, 1,000 network devices and multiple data centres
Separate infrastructure, network and DevOps teams need field ownership and change contracts before another dashboard. NetBox remains a credible network/DCIM authority at this scale; count alone is not a migration argument. Nautobot fits a platform team owning reusable Jobs, queues, tests and App upgrades. Device42 can supply discovery/service relationships alongside either through a deliberately governed reconciliation boundary.
Pilot branch RBAC, concurrent imports, long Jobs and recovery. Agree data/API contracts and an availability target for the source of truth itself. Cached approved plans and emergency procedures matter when the central model is unreachable during a network incident.
D. Years of undocumented legacy infrastructure
Begin with scoped discovery if hosts cannot even be enumerated. Device42 is a reasonable commercial pilot using vCenter, one server subnet and one network segment. Queue uncertain observations for reconciliation, define identity keys, resolve duplicates and verify owners. Promote approved fields into NetBox or Nautobot. Importing every observation as desired state legitimises existing drift.
E. Automation-first: GitLab, Ansible, Zabbix and Oxidized
Choose one authority for intended network data: NetBox if its model/integrations work, Nautobot if a maintained Jobs/App platform is needed. GitLab holds reviewed templates, playbooks and policy tests. Render from a pinned template commit plus a data snapshot, attach the diff to a merge request and require approval before a protected runner executes.
Ansible/AWX applies Cisco and RouterOS tasks with tested platform modules. VMware automation is a separate API path with its own permissions. Zabbix checks reachability and service health before/after changes. Oxidized independently polls supported network devices and commits retrieved configuration into restricted Git storage; verify model/transport support for the actual Cisco OS and RouterOS release.
Scheduled comparisons normalise volatile lines and compare observed Oxidized backups with approved rendered configuration. Golden Config is an optional compliance implementation. Timestamp drift records rather than importing drift as policy. Retain the last approved configuration and tested inverse/restore actions. Canary, batch limits, out-of-band access and explicit abort rules make rollback operational; a successful backup alone does not.
What the ownership bill actually contains
NetBox Community and Nautobot core use Apache-2.0 without a core software fee. Managed services, commercial editions and support are separate purchases. Device42 publishes annual device-based subscription licensing; no verified price for this estate was available. Obtain a quote defining counted devices, VMs, modules, collectors, HA, support and renewals instead of inventing per-node figures.
Estimate three years of subscription/support, compute/storage/backup, deployment/data cleansing, training, upgrade rehearsals, integration development and ongoing credential/data ownership. Use local labour rates and measured pilot hours. Open source can be cheaper with an existing platform team and more expensive when one engineer maintains custom importers after hours.
Measure time saved answering an operational question: which services fail if this switch is replaced? Count wrong records and manual reconciliation, not only collected objects. Iranian organisations should also verify contractual access to subscriptions, support and updates; a global pricing page does not establish a usable purchasing path.
Decide around the work you need to remove
Keep NetBox when authoritative IPAM/DCIM is the main need and current Ansible/GitLab workflows are maintainable. More data centres increase the need for governance; they do not make NetBox obsolete. Moving a clean model to Nautobot solely for a feature already delivered by your runner replaces proven integration with migration risk.
Choose Nautobot when maintained Jobs and compatible Apps remove recurring work and a team owns them as a product. It is not universally a better NetBox. Choose Device42 when unknown infrastructure/service relationships are the bottleneck and measured value funds the cost. Its IPAM/DCIM capabilities do not automatically replace your NetBox schema, plugins and automation contracts.
Combining Device42 with one source of truth is sensible with explicit field authority. Match stable platform identities plus serial/instance UUID where appropriate; do not rely solely on mutable hostnames. Preserve observation timestamps, reject ambiguous matches and make writes idempotent. Two bidirectional truth systems without conflict rules create another reconciliation incident.
| Estate / sites / devices | Need / budget / technical team | Recommendation / operational complexity |
|---|---|---|
| 1 site; 5 servers + 10 network devices | Low change; tight budget; one engineer | Minimal NetBox if errors justify operations; otherwise controlled records first |
| 5 sites; 50 servers; 100 devices; VMware/Zabbix/Ansible | Inventory needed; existing runner; moderate complexity | NetBox default; Nautobot for owned recurring workflows |
| 50 sites; 500 servers; 1,000 devices; multiple DCs | Dedicated teams; RBAC/HA; platform budget | NetBox or Nautobot by workflow ownership; Device42 for justified discovery gaps |
| Legacy estate; counts unknown | High discovery; security/data stewards available | Device42 pilot, approved data into one source of truth |
| Automation-first; GitLab/Oxidized/Ansible; mixed vendors | Frequent changes; Python owners; higher complexity | Nautobot if Jobs/Apps save work; retain NetBox if the pipeline solves it |
Run a time-boxed pilot with agreed acceptance criteria: reconcile a representative branch, prove one approved change and rollback, restore the platform in isolation and measure ownership effort. Record unmatched assets and unsupported platforms as failures to resolve. If the candidate does not improve these outcomes, its longer feature list is not a reason to migrate.
Questions to settle before migration
Can an existing NetBox database be used directly by Nautobot?
No. Treat the move as a data and integration migration. Map identities, IPAM semantics, custom fields and plugin objects; test API consumers and reconcile record counts before cutover. Retain a read-only copy and a tested return path.
Does discovery remove the need for a source of truth?
It supplies observations. Approved ownership, address reservation and intended configuration still need an authority and reconciliation policy. A discovered exception can be legitimate or unwanted; the collector cannot decide the business rule.
Should a mixed Cisco and MikroTik fleet choose Nautobot automatically?
No. Test the exact OS, module/driver and operations required. A strong Cisco onboarding path does not prove RouterOS parity. Keep platform-specific execution and rollback tests regardless of the central inventory product.
What must a Device42 pilot prove before purchase?
Prove credential-scoped coverage, identity matching and dependency usefulness on representative assets, then test restore and price the required entitlements. A large discovered-object count alone does not demonstrate reduced investigation time.
Official references and practical next reading
Official sources are linked beside the supported claims. Existing Meet AJ guides below cover implementation details. Commercial entitlements, model-specific MikroTik discovery parity and Device42 GraphQL remain verification items, not assumed features.
MikroTik RouterOS 7 networking
