A multi-state healthcare system running more than 40 hospital and ambulatory sites is in active design with us on an Arista AVD rollout scheduled to begin next quarter. Their network refresh is funded, their Arista hardware strategy is settled, and their network team has AVD on the roadmap with a 12-month target. Early in the engagement, their principal network architect asked a question most organizations don't ask until it's too late: should we deploy NetBox first, or AVD first, or can we do them in parallel?
Deploy NetBox first. That's the short answer we gave, and it's the same answer we give every organization in this position, whether it's a multi-state health system, a national financial services firm, or a large distributed retailer. The longer answer, with the numbers and the sequencing that make the case, is what this post covers.
Arista AVD is a productivity multiplier when the data feeding it is clean. It takes declarative YAML intent (VLANs, BGP peerings, MLAG pairs, uplink topology, EVPN overlays) and generates full EOS configurations across a fabric, complete with pre- and post-deployment validation, self-documentation, and integration into CloudVision's telemetry and governance workflows. That represents a fundamental shift for a 40-site healthcare network where the current operational model involves senior engineers typing configurations into individual switches during change windows.
But AVD's output is only as accurate as its input data model, and that's where most organizations encounter problems. The typical starting state in a large network, including this health system's current state, is a patchwork of Visio diagrams, spreadsheets tracking IP allocations, a legacy IPAM tool that hasn't been fully reconciled in years, and institutional knowledge in two or three senior engineers' heads. That is a source of record, not a source of truth. It cannot be queried by an automation pipeline, cannot validate its own consistency, and cannot tell you what's actually deployed today versus what was supposed to be deployed.
When organizations adopt AVD on top of that foundation, the pattern is predictable. The first few weeks look productive, because AVD handles the greenfield parts cleanly. Then the brownfield work begins, and every playbook run reveals data inconsistencies the spreadsheet never surfaced: overlapping VLAN assignments, subnet conflicts from undocumented site migrations, interface descriptions that don't match what's connected, MLAG domain IDs that differ between documentation and reality. Each finding stops automation until someone reconciles it. By month three or four, the team is spending more time chasing data problems than deploying automation.
The health system's network architect had watched this happen to a peer organization during a comparable project. That's why he asked the sequencing question early.
The sequence we walked through with them, and the one we're now executing:
Phase one: NetBox deployment focused on IPAM and rack inventory. NetBox is the open-source Network Source of Truth that Arista's AVD ecosystem, and nearly every modern network automation toolchain, expects underneath. The health system is deploying NetBox self-hosted inside their VMware environment (appropriate for their HIPAA posture), scoped initially to IP Address Management and rack elevations across all 40-plus sites. This phase delivers immediate operational wins (no more "is this IP in use?" tickets) and gives the team a working NetBox environment before the harder data work begins. Our NetBox source-of-truth architecture services handle the deployment, data migration, and integration phases.
Phase two: data reconciliation. This is the phase every organization wants to skip and nobody can. We're auditing existing IPAM data, spreadsheets, and legacy CMDB entries against actual deployed state (pulled from CloudVision telemetry and direct device queries), reconciling conflicts, and loading canonical data into NetBox. For this health system, we've already identified three VLAN conflicts and two overlapping subnets during the first data-load pass, all already in production. Running AVD against that data without reconciliation would have replicated those conflicts across every new leaf at automation speed.
Phase three: device, circuit, and topology modeling. Once IPAM and rack data are trusted, we extend the NetBox model to include devices, interfaces, cables, circuits, and service mappings. This is where NetBox starts to resemble what AVD expects, because Arista's AVD data model for fabric definitions (node types, uplinks, MLAG domains, BGP AS numbers, VLAN mappings) maps closely to NetBox's native object model. The integration pattern (NetBox feeding AVD via an inventory plugin) is well-established and documented.
Phase four: AVD rollout against clean data. With a trusted source of truth in place, AVD work moves fast. Playbooks generate configurations that match deployed reality. Pre-deployment validation works against declared intent rather than aspirational documentation. CloudVision compliance checks have something to compare against. The team can ship their first automated fabric inside a quarter rather than spending two quarters wrestling with inconsistent source data.
Phase five: drift detection and continuous assurance. Once NetBox is canonical and AVD generates configurations from it, continuous validation tools can validate deployed state against declared intent. Every CloudVision telemetry stream becomes a validation check. NetBox Assurance and network drift detection covers this phase in more depth. Broader automation pipeline work (Ansible, Terraform, CI/CD for network changes) is covered in our Network Automation and IaC services.
The health system's original internal plan, before we were brought in, estimated an 8-month AVD implementation timeline with NetBox adoption deferred to "a later phase." The revised plan runs NetBox-first, with the full source-of-truth foundation landing in roughly 10 weeks, followed by AVD work projected at 10 to 12 weeks against clean data. Net timeline is comparable to the original, but with the data foundation in place, the AVD work itself doesn't stall on reconciliation. Their CIO ran the numbers on both paths and signed off on the revised sequence within a week.
More importantly, their drift detection baseline is established before AVD rollout begins. When we start deploying AVD-generated configurations, we'll know immediately if deployed state diverges from intent. Without that baseline, the first AVD-produced misconfiguration would have been invisible until it caused an incident.
Any large multi-site network planning an AVD rollout should run this sequence. It applies regardless of vertical: healthcare systems, financial services firms with hundreds of branches, national retailers, large enterprise campuses. The common factor is scale plus accumulated operational debt.
Where this doesn't fit: small networks where current documentation genuinely is accurate. That's rare in practice but exists, usually in tightly-run shops with under 50 devices. At that scale, AVD and NetBox can legitimately be adopted in parallel.
For the broader modernization context across networking, security, HCI, and observability, our strategic adjacencies and modernization roadmap covers how NetBox and AVD fit into larger transformation projects. For organizations that would rather consume NetBox as a managed service, Source of Truth as a Service is part of our managed solutions portfolio.
In principle yes, in practice no. Teams that run both rollouts simultaneously end up with neither finished on schedule, because every AVD question reveals a gap in the NetBox data that has to be filled before the AVD work can continue. The perceived parallelism is actually serial dependency with extra coordination overhead. Finish NetBox first, then start AVD against complete data.
They work as IPAM, but they don't cover the rack, device, circuit, and topology models that AVD expects. You can integrate a commercial IPAM into NetBox as the upstream IP source, but you still need NetBox (or something with its object model) to feed AVD. Most customers consolidate on NetBox for this reason.
For a 40-plus site network, plan on 8 to 12 weeks for a first usable pass covering IPAM, rack inventory, core devices, and primary circuits. Full data model coverage (every access switch, every patch cable, every power feed) takes longer and isn't strictly required before starting AVD. The sequence matters more than the completeness.
Either works. Self-hosted fits regulated verticals like healthcare and financial services where platform policies require it. NetBox Cloud removes the operational overhead. The choice is usually driven by existing platform policies rather than functional differences.