Choose data centre infrastructure software by checking how it identifies equipment, places it in racks and preserves the records needed for a change. Start with a reliable asset-and-location model, then assess the capacity questions you need to answer. Use the worksheet below to reconcile physical observations, planned moves and the system’s recorded state.
Which records must describe the same physical installation?
Take one piece of equipment and follow its identifiers. Record the physical label, manufacturer serial number, internal asset identifier, site, rack and management reference. Agree which identifier the team uses to locate the record during an incident or a planned move. Keep names and identifiers in separate fields when they serve different purposes.
NetBox represents hardware installed within a site or rack as a device. Documentation. This provides a concrete model to examine during selection. Ask the demonstrator to find an installed device from its physical label and then show its recorded location. Use the same example when reviewing import data, field validation and the proposed change process.
A NetBox rack must belong to a site and may also belong to a location within that site. Documentation. NetBox can record a facility identifier separately from the rack name. Documentation. Consider a colocation environment where the facility operator and the internal team use different labels for the same rack. Preserve both references and establish which one belongs on a work instruction. Ask the person carrying out a move to identify the rack from the instruction before the record is accepted.
How should rack position and capacity be interpreted?
NetBox supports ascending or descending rack-unit numbering. Documentation. Confirm the numbering direction against the actual installation before importing positions. A rack diagram should be compared with the facility’s labels rather than accepted because it looks tidy. Record who checked that correspondence and which racks remain unverified.
For a multi-unit device, NetBox records the lowest-numbered occupied rack unit as its position. Documentation. Make the position convention part of the data dictionary. When a record spans several units, ask the team to explain which value is entered and how the occupied space is represented. Use a deliberately awkward example in the proposed demonstration so the convention becomes visible.
NetBox permits zero-unit devices that do not consume vertical rack space. Documentation. Include equipment that does not fit a simple front-mounted server picture in the evaluation. Ask where the team records a vertically mounted power unit and how it is associated with the installation. Keep the placement convention explicit instead of inventing a rack-unit position merely to satisfy an import column.
Separate the questions of occupied rack space, available power and cooling requirements in the requirements brief. The cited device and rack records establish modelling features; the selection exercise should request additional evidence for any live telemetry, environmental monitoring or capacity calculation you need.
An original asset-and-change reconciliation worksheet
Use this practical checklist to connect a physical inspection with a proposed software record. Complete it before accepting a bulk import or a move record. The table is an original working aid, with fields to populate from your own installation.
| Record boundary | Information to compare | Acceptance question |
|---|---|---|
| Physical identity | Asset label and manufacturer serial number | Can the intended equipment be identified unambiguously? |
| Facility identity | Internal rack name and facility identifier | Do both references point to the inspected rack? |
| Placement | Rack face, position and numbering direction | Does the drawing match the physical label convention? |
| Device structure | Type and expected components | Were the created components checked against the intended device? |
| Planned change | Source, destination and responsible operator | Is the move still planned or already performed? |
| Completion | Observed location and record update reference | Who reconciled the actual installation with the system? |
| Exceptions | Missing label, disputed location or uncertain component | Who owns resolution and what remains provisional? |
Keep planned and observed positions distinct in the working copy. A proposed rack move should not become the recorded installed location just because a planner selected the destination. Define the evidence required to advance the change state and the person authorised to record completion.
Where an import supplies several identifiers, preserve the original reference alongside the chosen system key. Ask how duplicate or conflicting identifiers are reported. Resolve exceptions as individual records rather than silently discarding rows or making up identifiers to obtain a clean import summary.
What happens when a device template changes?
NetBox device types provide components when a device is created. Documentation. Changing a NetBox device type does not retrospectively update the device components. Documentation. Review the distinction between a reusable type definition and the components already present on an installed device record. A type change should prompt a reconciliation question: which components actually changed, and which records need attention?
NetBox recommends putting physical rack attributes on the assigned rack type. Documentation. Use the product’s documented modelling conventions when preparing the initial data dictionary. Review the documentation for the deployed version before deciding which fields belong to a rack instance and which belong to its type. Retain the mapping with the import specification so future maintainers can understand the choice.
NetBox rack records can include a physical serial number and an asset tag. Documentation. Ask the team to show how the physical serial reference differs from the internal asset label. Include a record where the equipment has been renamed but its physical identity remains the same. The exercise should establish how the intended object is found without relying on a remembered hostname.
Hypothetical example: the rack move recorded too early
Imagine a team plans to move a server to another rack and updates the location record before the work occurs. A later operator finds the server in the original position. This hypothetical reconciliation case tests the change process and the evidence required for completion.
Use a synthetic work instruction and two clearly identified rack records in the proposed demonstration. Mark the destination as planned, retain the observed source location and assign a person to confirm the physical move. Ask where an aborted move is recorded and what the next operator would see.
Then introduce a discrepancy in the destination rack’s numbering direction. Compare the planned position with the physical label convention before marking the change complete. Retain the correction and the reason. This keeps a data-quality issue visible rather than allowing a plausible diagram to overwrite the observation.
What should the selection decision leave behind?
Prepare a small set of representative records and the questions each one should answer. Include a conventional rack-mounted device, a zero-unit item and a change in progress. Record the candidate’s demonstrated behaviour separately from features still requiring confirmation, particularly monitoring and capacity calculations outside the cited pages.
The useful output is an agreed model, a reliable import mapping and a process for keeping records aligned with changes. For the wider operational brief, see web development and hosting. Get started with the asset questions, existing data sources and handover responsibilities you want to discuss.
By Spout Team. AI-assisted drafting by Codex using the linked primary documentation.