The uncomfortable reality
A familiar scene in enterprise data centers: someone pulls up NetBox in a capacity planning meeting to show the available rack space. The numbers look good, plenty of room for the new deployment. Then someone from operations mentions that the servers installed last month were never registered.
That is an architecture problem, not a process problem.
Manual IPAM/DCIM updates don’t scale, and they never have. Once you rely on people to update inventory after every change, you have accepted that your source of truth will drift from reality within weeks. Sometimes days.
In regulated industries the drift is a compliance risk as well as an inconvenience. Auditors don’t accept “we think this is accurate” as documentation.
What actually works
Better procedures won’t fix it and neither will more disciplined staff. The way out is to accept that infrastructure components already know their own state, and to build pipelines that harvest it automatically.
Your switches know which MAC addresses are on which ports. VMware vSphere knows every VM, its resource allocation, and which host it runs on. Proxmox tracks its own inventory in real time. The data is already there. It just doesn’t flow to where you need it.
The architecture is simple enough:
Source systems (switches, hypervisors, hardware) → extraction layer → transformation and validation → target systems (source of truth, DCIM)
The concept is the easy part. The details are where the work is: handling conflicts, managing historical data, keeping the whole thing idempotent, and building audit trails that hold up to compliance requirements.
A practical implementation approach
Where the data lives
Different components expose their data differently.
Network switches (Juniper, Cisco, Arista) give you LLDP/CDP neighbor information, MAC address tables and interface statistics over NETCONF, REST APIs, or SSH/NAPALM. That tells you what is physically connected where.
VMware vSphere exposes its full inventory through pyVmomi or the REST API: VMs, hosts, clusters, datastores, and the relationships between them.
Proxmox has a clean REST API for VM and container inventory, including resource allocation and node placement.
Hardware management interfaces (iLO, iDRAC, IPMI) give you serial numbers, model information and health status straight from the metal.
Prefect for orchestration
I have stopped using cron jobs and custom schedulers for this. Prefect gives infrastructure pipelines what they actually need: dependencies between tasks, automatic retries with backoff, proper logging, and a UI to see what happened.
A typical flow has six stages:
- Extract: pull the current state from each source system
- Transform: normalize into a common schema, resolve naming conventions
- Validate: check for conflicts, impossible states and data quality problems
- Diff: compare against the current IPAM/DCIM state to find what changed
- Apply: update the target systems with full audit logging
- Verify: confirm the changes landed
Never blindly overwrite. The diff step is what catches the cases where automated data contradicts a manual entry that represents planned future state or a deliberate override.
Conflict resolution is the hard part
What happens when the pipeline finds a server in rack A and NetBox says rack B?
Business logic matters more than code here, and there are four reasonable options. Trust the source, so automated data wins and the manual entry gets corrected. Trust the target, so nothing gets overwritten and a human reviews it. Go by timestamp and let the most recent update win. Or score your sources by confidence and weight them accordingly.
In practice I use a hybrid. High-confidence sources like switch port mappings and hypervisor inventory overwrite automatically. Lower-confidence data like IP assignments and custom fields gets flagged for review.
Audit trails
Every pipeline run produces before and after snapshots, change attribution showing which source triggered which update, timestamps aligned to the time the source system reported, and rollback for the entire batch.
That record changes what you can say when someone asks how you know a rack diagram is accurate. The documentation is reconciled from live switch data on a schedule, and the audit log shows it.
Technology choices that matter
Python is still the practical choice for infrastructure automation. There are libraries for every source system, operations teams can read the code, and it works both with Ansible and on its own.
For the intermediate data store, PostgreSQL or DuckDB depending on scale. DuckDB is very good where you are doing heavy transformations before pushing to the target IPAM/DCIM.
NetBox is the de facto standard for IPAM/DCIM. It has a full REST API, GraphQL support, and a data model that was clearly thought through for network-centric infrastructure.
Nautobot is the alternative worth knowing. It forked from NetBox in 2021 and has moved toward automation execution: a jobs framework, an app ecosystem, and GraphQL built in from the start rather than added later. If your source of truth also has to run the automation, that changes the calculation. If you mainly want clean documentation with the largest community behind it, NetBox is the safer default.
dcTrack is strong on physical data center management: rack elevations, power chains, capacity planning. A network source of truth (NetBox or Nautobot) plus dcTrack for physical and power covers most enterprise needs.
What this looks like in practice
Organizations that do this typically end up with documentation that stays accurate, because drift gets caught by the pipeline instead of discovered during an incident. Manual reconciliation largely disappears, and the time that went into cross-checking systems by hand goes back into engineering work. Audits get easier, because the pipeline keeps a complete change log. And incident response gets faster: “what’s connected to this switch port?” becomes a query instead of an investigation.
Getting started
If you already know your IPAM/DCIM accuracy is a problem, start small. Pick one source; network switches are usually the highest-value place to begin. Build the extraction and get data flowing into a staging area. Validate manually and spot-check against physical reality. Then implement the sync, starting with read-only reporting before you enable writes. Add further sources one at a time.
Day one doesn’t have to be perfect. What matters is getting the pipeline architecture in place, because that is what makes continuous improvement possible.