Device42 Migration Best Practices: Getting Your Asset Data Right
Device42 is a powerful CMDB and DCIM platform, but a successful migration requires more than just uploading a spreadsheet. Here is what the preparation actually looks like.
Why Device42 Migrations Are Different
Device42 sits at the intersection of DCIM and CMDB. Unlike pure DCIM platforms that focus exclusively on physical infrastructure, Device42 tracks the full lifecycle of an asset — from physical location and power connectivity through to software licensing, service dependencies, and cloud resource relationships. This breadth makes it one of the most powerful tools in the enterprise IT portfolio. It also means that a Device42 migration is more complex than a pure DCIM import.
The complexity comes from the data model. Device42 organises assets into Buildings, Rooms, Rows, and Racks — a four-level physical hierarchy. It tracks devices, virtual machines, IP addresses, and network connections as separate but related object types. And it has its own auto-discovery engine that can populate many of these objects automatically — which is both an advantage and a complication when you are migrating from a manual inventory.
The Auto-Discovery Question
Before you start preparing your migration data, you need to decide how much of your Device42 population will come from auto-discovery versus manual import. Auto-discovery is accurate and comprehensive for networked devices that are reachable from the Device42 appliance. It will correctly identify the vendor, model, serial number, and IP address of most servers, network devices, and storage arrays.
But auto-discovery has gaps. It does not discover passive infrastructure — PDUs, patch panels, cable trays, blanking panels. It may not reach devices in isolated network segments. And it does not know the physical location of a device — it can tell you the IP address and hostname, but not which rack and U position the device occupies.
The practical approach is to use auto-discovery for networked devices and manual import for everything else. This means your import data should focus on physical location assignments, passive infrastructure, and devices that auto-discovery cannot reach.
Normalising Your Source Data
Device42's import format is more flexible than NetBox's or dcTrack's, but it still requires consistent data. The most important normalisation steps are:
Hardware model standardisation. Device42 matches imported devices against its hardware model library. If your source data has "Dell PowerEdge R640" and the library has "PowerEdge R640" (without the "Dell" prefix), the match will fail. Check Device42's hardware model naming conventions before you format your CSV.
Building and room hierarchy. Every device must reference a building and room that already exists in Device42. If your source data has location strings in a free-text format, you need to parse them into the building/room/row/rack hierarchy before import.
IP address deduplication. Device42 treats IP addresses as unique objects. If your source data has the same IP address appearing on multiple records (which happens when data has been copied between spreadsheets), the import will create conflicts. Deduplicate IP addresses before import.
Status mapping. Device42 uses a controlled vocabulary for device status: "in service", "not in service", "planned", "retired". Map your source status values to these before import.
The Import Sequence
Like other DCIM platforms, Device42 requires objects to be imported in dependency order. The sequence is: Buildings → Rooms → Racks → Hardware Models → Devices → IP Addresses → Network Connections.
Do not try to import everything in a single pass. Import each object type separately, verify the results, and then move to the next level of the hierarchy. This makes it much easier to identify and fix errors without having to re-import the entire dataset.
Handling the CMDB Layer
If you are migrating to Device42 specifically for its CMDB capabilities, you will need to import not just physical assets but also service relationships, software licenses, and business application mappings. This data rarely exists in a structured format in source inventories — it typically needs to be gathered through interviews with application owners and service desk teams.
Plan for this as a separate workstream from the physical asset migration. Complete the physical asset import first, then layer in the CMDB relationships once the asset foundation is solid.
Post-Import Validation
After the import, validate a random sample of records against the source data. Check that physical locations are correct, that hardware models matched correctly, and that IP addresses imported without conflicts. Run Device42's built-in data quality reports to identify any records with missing required fields.
The goal is to catch data quality issues before users start relying on Device42 as their source of truth. A post-import validation exercise that takes a day is far less expensive than discovering data quality problems six months later when the platform is in production use.