How to Migrate from Excel to a Real IPAM/DCIM

Every network team that still tracks infrastructure in Excel eventually hits the same wall. Someone opens the file to answer a simple question, the file is wrong, and the quiet trust that held the whole system together breaks. You stay on the spreadsheet anyway, because migrating feels like the bigger risk. The tabs have multiplied, half the columns are empty, three different people have their own copy, and nobody can say with certainty which version of the device list reflects what is actually in the racks. So the file stays, and the gap between your documentation and your network keeps growing.

A real IPAM/DCIM solves the model problem, but the model was never the hard part. The hard part is the data. Most spreadsheet migrations fail not because the destination platform is weak, but because the source data was never audited, normalized, and reconciled before it moved. The good news is that the journey follows a repeatable sequence, and most teams can finish it in days rather than weeks. This guide walks through that sequence end to end, from auditing what you actually have to retiring the spreadsheet for good, whether you land on Obelinf or one of the other platforms that appear in the comparison below.

At a Glance: The Migration Options

Once you decide to leave Excel, your options split into four paths.

Know What You Have Before You Move It

Migration starts with an audit, not an import. Before you move a single row, take inventory of every file, tab, and stray sheet that currently acts as documentation. Work through each one and ask what it actually tracks: devices, IP allocations, cables, circuits, VLANs, power feeds, serial numbers. Most teams discover that their documentation is scattered across several files, some maintained weekly, some abandoned eighteen months ago with a former manager’s name still in the owner column.

Label every tab as live, stale, or dead. Only live data gets migrated. Stale data gets a decision, either verify it against reality or drop it. Dead data gets archived somewhere outside the migration entirely. This triage is what separates a migration that cleans your data from one that just moves the mess, and it tells you the true scope of the project, because the file count on your desktop is usually not the same as the number of things you actually track.

Export each live sheet to CSV and inspect it outside Excel. Watch for merged cells, formulas that generate values instead of storing them, hidden rows, and columns where the same entity is named differently in different places. If your IP address tracking tab exists, compare its column structure against the IP Address Spreadsheet CSV template, which shows what a clean export looks like and gives you a target schema to normalize toward.

Clean the Data Before You Import It

The most common migration mistake is importing the spreadsheet’s mess and calling the job done. Normalize before you import, because the destination platform will not guess what your free text entries mean. A device row with a missing rack, a site name spelled three different ways, or a status column mixing “active”, “Active”, and “YES” will either fail to import or create duplicates and orphans the moment the data lands.

Start with naming. Pick one canonical name for every site, rack, device, and VLAN, and apply it everywhere the name appears. Then enforce values: decide which fields are required and fill them, decide the vocabulary for status fields, and drop columns that nobody uses, because every empty column you carry over is debt you will pay in every future export. Deduplicate by serial number, MAC address, or IP address, whichever uniquely identifies each record type, and resolve collisions before import rather than after.

The destination platform’s CSV template is your schema. If you normalize toward it in the spreadsheet first, the import becomes a mechanical step instead of a debugging session. For datasets too large to clean by hand, a script that transforms the export into the template format is a better use of an afternoon than weeks of manual row editing.

Import in the Right Order

Import in dependency order, and the platform’s referential integrity does the rest. Sites come first, because racks belong to sites. Racks next, because devices sit in them. Devices after that, along with their interfaces, because subnets and addresses hang off real hardware or at least off a clear allocation hierarchy. Subnets and IP addresses then, and cables and circuits last, because they reference interfaces and devices from the earlier passes.

Each pass creates records that the next pass references. Import out of order and you either get failures or, worse, silently broken relationships that surface months later when someone traces a cable and finds it attached to nothing. Most platforms accept CSV for the smaller passes and a REST API for the larger ones, and the API is repeatable, which matters when you need to rerun an import after fixing a data problem. If you are bringing over thousands of devices, the device inventory fields are the ones worth capturing, and batching imports means a bad row fails loudly in one pass instead of corrupting the whole load.

Reconcile the Sheet with Physical Reality

Importing is not verification. The spreadsheet and the physical network have drifted, sometimes for years, and every row you imported inherits that drift. After the import, walk the data against reality. Spot check racks: does the device list match what is in front of you? Compare IP allocations against active leases or ARP tables. Check cable labels against the interfaces they are supposed to connect. Fix every discrepancy in the destination platform, not back in the sheet, because the destination is now the source of truth and it has to be right from day one.

This reconciliation pass is where trust gets rebuilt, and it is also where your team starts to feel the difference. The questions they ask every day, where is this device, what is plugged into this port, who changed this subnet, are the exact questions the spreadsheet answered slowest. Once the answers live in a platform with search, the verification loop shortens from hours to minutes, and the discrepancies you find during the walk are the last ones that will ever be hiding in your documentation.

Make the Cutover Stick

Cutover fails in the first week more often than in the migration itself, and the reason is almost always the same: the spreadsheet never went away. A second source of truth always wins, because it is what people are used to, so you have to make the spreadsheet physically inconvenient to use. Rename it with a retired suffix, revoke write access, move it to an archive folder, and announce a date after which answers come from the platform and nowhere else.

While you are at it, give the team reasons to prefer the new tool. Search that returns answers in seconds, a network topology view that renders from the data instead of a hand drawn diagram, a Changelog that shows who changed what without anyone having to write a note. The moment someone needs an answer and gets it faster than the old file ever delivered, the migration stops being an edict and becomes an obvious improvement. Keep the old file accessible for reference during the transition, but make it read only from day one, because the first person who edits it reopens the door to drift.

From Spreadsheet Rows to a Living Source of Truth

Obelinf was built for exactly this migration. The platform ships with CSV templates for the records that come out of a spreadsheet, devices, racks, IP addresses, cables, and circuits, so your normalized exports land in a structure designed for them rather than a generic grid. For the larger passes, the REST API handles imports in bulk, and once the data is in, the spreadsheet’s weaknesses become the platform’s strengths.

Records are linked: a device knows its rack, its site, its interfaces, and its cables, and the topology view renders that connectivity automatically. Every change lands in an automatic changelog, so the audit trail you could never produce from a file now writes itself. Search works across every entity and attribute, which is the entire reason teams eventually abandon Excel in the first place. The migration is a one time project, and the payoff is permanent: a few days of auditing, normalizing, importing, and reconciling converts a file nobody trusts into a source of truth that answers questions, proves changes, and stays current as a side effect of the work your team does anyway.

When you are ready, sign up for free at obelinf.com and import your first sheet this week. For the full picture of where this fits inside a larger move, see the infrastructure migration guide.