Français
English
Español
DeutschWhy an IPAM migration rarely fails because of the tool
Migrations that go wrong almost always follow the same script: the file is imported as-is, 300 duplicates and 80 overlapping subnets surface, the team loses confidence in the new tool, and six months later the spreadsheet is still there — alongside the IPAM.
The problem is not the import. The problem is that a spreadsheet allows what an IPAM refuses: one address on two rows, a mask inconsistent with its range, a VLAN written “VLAN 12”, “vlan12” and “12” across three tabs. These approximations are invisible in Excel and blocking on import — which is precisely where an IPAM adds value, but it also means that cleanup is not a step before the migration: it is the migration.
If you are still weighing whether to leave the spreadsheet rather than how, the article Why Excel is no longer enough to manage IP addresses covers that question first.
Before migrating: three decisions to make
Three trade-offs shape everything else. Settling them before opening the first CSV saves you from redoing the import three times.
What is the scope of the first batch?
Migrating the entire addressing plan at once is the most common reflex and the riskiest. A pilot site, or one well-understood range, lets you validate the target hierarchy before applying it to everything else.
Who arbitrates doubtful data?
There will be addresses nobody can confirm are in use. You need a rule decided upfront — for example “unidentified after a scan and 30 days of observation = released” — and one person who makes the call.
On what date does the spreadsheet die?
As long as the file remains editable, it stays the unofficial source of truth. Setting a freeze date, announcing it and holding to it is what separates a migration from permanent double entry.
The six steps of a controlled migration
Freeze and snapshot the existing plan
Set the file to read-only, archive a dated copy, and announce that every new request goes through the target channel. Without a freeze, you are migrating a moving target.
Clean and normalise
Deal with duplicates, overlaps, inconsistent masks and non-standard labels. This is the longest step, and the one that determines the final quality.
Define the target hierarchy
Blocks, subnets, ranges, organisations, sites, VRFs: decide the structure before importing, because reworking it afterwards costs far more.
Import in batches
Import containers first (organisations, sites, blocks), then subnets, ranges and addresses. The order matters: subnets and ranges must be attached to their parent. In teemIP, an IP address can still be created without an associated subnet, which helps recover incomplete data progressively.
Reconcile against the field
Compare the imported repository with reality: IP discovery, DNS zones, DHCP leases, ARP tables. This is where you measure the real gap between the file and the network.
Lock down governance
Permissions, request workflows, an owner per range, audit. Without this step the IPAM degrades within months and becomes a spreadsheet with a better interface.
Cleaning the file: the six anomalies that block an import
These anomalies appear in almost every addressing plan kept in a spreadsheet. Handling them before the import avoids mass rejection and repeated round trips.
| Anomaly | How to spot it | Decision to make |
|---|---|---|
| Address listed several times | Sort on the IP column, or apply conditional formatting for duplicate values. | Keep the most recent or best-documented row, archive the other. |
| Overlapping subnets | Sort by network address and check that each range ends before the next one starts. | Trace the subnetting history before deciding: an overlap often hides a range genuinely in use. |
| Mask inconsistent with the range | Recompute the network and broadcast addresses from the declared mask. | Trust the actual device configuration, not the file. |
| Non-standard labels | Filter the VLAN, site and organisation columns: variants show up immediately. | Pick a naming convention and apply it before the import, not after. |
| Missing or implicit status | Empty cells, colours, or comments used as a status. | Convert every colour code into an explicit value: reserved, allocated, free, unidentified. |
| No owner recorded | Owner column empty or pointing at someone who has left. | Attach ownership to a team or department rather than an individual. |
Importing: the order that avoids rejections
An IPAM validates structural dependencies. In teemIP, a subnet must be attached to a block and a range to a subnet; an IP address can, however, be created without an associated subnet. This flexibility lets teams recover data progressively while preserving a consistent hierarchy for dependent objects. The import order below nonetheless remains the safest route:
- Organisations and sites — the top-level containers.
- IP blocks, IPv4 and IPv6, with their organizational attachment.
- Subnets, with mask, gateway and status.
- Ranges (DHCP, reserved, static) inside the subnets.
- IP addresses, with status, DNS name and comment.
- Links to CIs, once the CMDB is populated.
Each IP object also accepts a requester — the person behind the request — and as many contacts as needed, people or teams. These links can be filled in as the migration progresses; they never block the first import.
One practical point: import a small batch first — fifty rows is enough — to validate column mapping, separators and encoding. Files exported from a localised Excel commonly raise two classics: the semicolon as a separator, and Windows-1252 encoding that breaks accented characters. teemIP lets you pick the encoding at import time (UTF-8, ISO-8859-1…), so there is no need to reconvert the file beforehand; either way, it is better to find these details on fifty rows than on four thousand.
Reconciling against the field
The file describes what the team believes it knows. The network describes what exists. The gap between the two is often the most useful discovery of the project, and sometimes the most uncomfortable.
Three sources let you measure it without heavy instrumentation: DNS zones, which reveal the addresses actually named; DHCP leases, which show what is active; and an IP discovery sweep, which reports what answers. Cross-referencing these three sources with the imported repository produces three lists: what matches, what exists but was never documented, and what was documented but no longer responds.
The third list is the one that frees up addressing capacity. It is often the argument that justifies the project to management: in an addressing plan kept in a spreadsheet for several years, a significant share of the addresses marked as used no longer are.
Locking down so you never go back to the spreadsheet
A correctly populated but freely editable IPAM degrades just as fast as a shared file. What holds over time is the write rules, not the quality of the initial import.
Four mechanisms are enough to stabilise the situation: permissions scoped by perimeter rather than blanket write access, a single address-request channel that leaves a trace, an identified owner per range, and a periodic audit comparing the repository with the field. That is exactly what a spreadsheet cannot offer — and why a migration is not judged on import day, but six months later.
This lockdown pays off most when the IPAM is linked to the CMDB: an address attached to a device, a service and an owner becomes auditable. That subject is developed in IPAM, CMDB and NIS2, and the IPAM & CMDB page details how the two repositories fit together.
How long it really takes
Duration depends far less on the number of addresses than on the state of the starting file and the number of people you need to involve to arbitrate doubtful data. A well-kept plan of 2,000 addresses migrates faster than a 500-address plan documented by five people across three tabs.
The orders of magnitude observed on this kind of project place installation and configuration at a few days, cleanup and import at two to six weeks depending on data quality, and field reconciliation at one to two months — that last phase being mostly a matter of team availability rather than technique.
Frequently asked questions about migrating an addressing plan
Can an Excel file be imported directly into teemIP?
Import uses the CSV format, which every spreadsheet exports. teemIP provides a guided import with column mapping to the data model fields, encoding selection (UTF-8, ISO-8859-1…) and a preview before validation. The point of attention is not the format but data consistency: a clean CSV imports without difficulty, whereas a CSV containing overlaps will be rejected row by row.
Does everything have to be cleaned before importing, or can it be fixed afterwards?
Structural anomalies — subnet overlaps, inconsistent masks, organisation hierarchy — must be handled before the import, because they determine the tree. Descriptive information — comments, owners, DNS names — can be completed afterwards, as reconciliation progresses. The simple rule: what defines the structure is settled first, what documents it can be filled in later.
What should be done with addresses whose purpose nobody knows?
Import them with an explicit status such as “unidentified” rather than deleting them or marking them free. They then enter the reconciliation cycle: IP discovery, DNS, DHCP. Those that answer none of these sources after an observation period defined in advance can be released, with a record of the decision.
Can the migration be staged, or does everything have to switch at once?
Batch migration is clearly preferable: a pilot site or range lets you validate the target hierarchy and the mapping before generalizing. The only constraint is to freeze the already-migrated scope in the spreadsheet, otherwise the two repositories diverge immediately and the team loses confidence in both.
How do you migrate from phpIPAM or another IPAM rather than from Excel?
The logic is the same, with one advantage: the data is already structured and CSV or API export is native. The work then focuses on mapping the data models — particularly the notions of organisation, site and VRF, which do not always overlap. The phpIPAM and teemIP comparison details these scope differences.
How long should a full migration take?
From a few weeks to a few months depending on the state of the starting data and the number of teams to involve. Address volume is rarely the limiting factor: it is the quality of the initial file and the availability of the people able to arbitrate doubtful cases that determine the real duration.
Going further
Public sources used
An Excel addressing plan to take over?
Tell us the state of your file: we help you scope the cleanup, the import order and the migration path.
Scope my IPAM migration