IPAM Import Formatter

The IPAM Import Formatter transforms IP address data into the specific CSV and field formats required by popular IP Address Management systems like NetBox, phpIPAM, and Infoblox. Paste your source data in any common format -- CSV from a spreadsheet, an export from another IPAM, or semi-structured text -- select your target platform, and get a validated, ready-to-import file without manual column renaming or value translation.

Understanding IPAM Data Migration

Migrating address data into an IPAM system should be straightforward, but in practice it is one of the most frustrating tasks in network operations. Every IPAM platform has its own CSV schema: NetBox wants a prefix column with CIDR notation, phpIPAM expects subnet and mask in separate columns, and Infoblox uses a header row that starts with header-network followed by address* and netmask*. Get any of these details wrong and the import fails with a cryptic error message, sending you back to the spreadsheet to fix formatting, rename columns, and try again.

The problem gets worse when you are migrating between platforms. An export from phpIPAM does not import cleanly into NetBox, because the column names, status values, and network notation are all different. A phpIPAM status of 1 (active) needs to become active in NetBox. A network stored as two separate columns (subnet + mask) needs to merge into a single CIDR prefix column. Doing this manually for hundreds or thousands of subnets is tedious and error-prone -- one mistyped subnet mask or missing required field can cause the entire import to fail.

This formatter handles all of that automatically. You paste your source data, select the target platform, map any ambiguous columns, and get properly formatted output with validation warnings for anything that would cause an import error. It knows the schema requirements for each supported platform, translates status values between systems, and normalizes network notation to match what the target expects. What used to take an afternoon of spreadsheet gymnastics now takes about thirty seconds.

How to Format Data for IPAM Import

1. Paste your source data in any common format (CSV, tab-separated, or structured text from spreadsheets or other IPAM exports)
2. Select the target IPAM platform (NetBox, phpIPAM, Infoblox, or generic CSV)
3. Map your source columns to the target system's required fields using the column mapper
4. Preview the transformed output and review any validation warnings
5. Copy or download the formatted CSV ready for import

IPAM Platform Format Examples

NetBox Import Format

prefix,status,vrf,tenant,site,description
10.1.0.0/24,active,Production,Engineering,NYC-DC1,Server VLAN
10.1.1.0/24,active,Production,Engineering,NYC-DC1,User VLAN
10.1.2.0/24,reserved,Production,Marketing,NYC-DC1,Future expansion
172.16.0.0/22,active,Corporate,IT,HQ,Office network

phpIPAM Import Format

subnet,mask,description,vlanId,masterSubnetId,nameserverId
10.1.0.0,255.255.255.0,Server VLAN,10,,1
10.1.1.0,255.255.255.0,User VLAN,20,,1
10.1.2.0,255.255.255.0,Future expansion,30,,1
172.16.0.0,255.255.252.0,Office network,100,,2

Infoblox CSV Import Format

header-network,address*,netmask*,comment,EA-Site,EA-Environment
network,10.1.0.0,255.255.255.0,Server VLAN,NYC-DC1,Production
network,10.1.1.0,255.255.255.0,User VLAN,NYC-DC1,Production
network,10.1.2.0,255.255.255.0,Future expansion,NYC-DC1,Production
network,172.16.0.0,255.255.252.0,Office network,HQ,Corporate

When to Use the IPAM Import Formatter

• IPAM platform migration -- convert exported data from your old IPAM system into the exact format required by the new platform without manual CSV editing
• Bulk subnet onboarding -- import hundreds of subnets from a planning spreadsheet into your IPAM system in a single operation instead of adding them individually through the UI
• Multi-source consolidation -- combine address data from spreadsheets, router configs, and cloud platform exports into one normalized import file
• Data validation before import -- catch invalid CIDR notation, missing required fields, and duplicate entries before attempting the import, avoiding cryptic error messages from the IPAM system
• Portable backup creation -- export your address plan in a standardized format that can be imported into any IPAM platform
• Automation pipeline integration -- generate IPAM-ready CSV files from scripts or network discovery tools for automated ingestion

How IPAM Import Formatting Works

Column Mapping

Each IPAM platform expects different column names, data types, and value formats:

Validation Checks

The formatter validates your data before generating output:

• CIDR syntax -- verifies each network address is properly formatted and the host bits are zeroed for the given prefix
• Required fields -- ensures all mandatory columns for the target platform are populated
• Duplicate detection -- flags duplicate subnet entries that would cause import conflicts
• Value constraints -- checks that status values, VLAN IDs, and other fields use values the target platform accepts

Practical Advice for IPAM Data Migration

The single most important step in any IPAM migration is data cleanup before the import. The formatter will catch formatting errors, but it cannot fix semantic problems like outdated descriptions, incorrect VLAN assignments, or subnets that no longer exist in production. Before running the conversion, review your source data and remove or correct stale entries. Importing dirty data into a new IPAM system just moves the mess from one platform to another.

When importing hierarchical subnet structures, order matters. Most IPAM systems build parent-child relationships automatically based on CIDR containment, but they need to see the parent before the child. Import your largest allocations first -- the /16 and /20 aggregate blocks -- then import the smaller /24 and /28 subnets in a second pass. Some platforms handle this automatically regardless of order, but doing it in two passes is safer and avoids dependency errors in platforms that are strict about hierarchy.

After the import completes, always verify the results. Spot-check a representative sample of subnets in the new IPAM system to confirm that addresses, masks, descriptions, and VLAN assignments imported correctly. Run a count comparison: if your source had 347 subnets, the IPAM should show 347 subnets. Any discrepancy means something was silently dropped during import, usually due to a validation rule that the formatter did not flag. Catching these gaps immediately is far easier than discovering them months later when someone looks up a subnet and finds it missing.

Frequently Asked Questions

Can I convert between IPAM platforms directly?

Yes. Export from your source platform, paste the data into the formatter, select the target platform, and the tool handles the column renaming, value translation, and format conversion automatically. This is the most common use case for IPAM migrations.

What if my source data has columns the target platform does not support?

Unmapped columns are excluded from the output. The tool only generates columns that the target IPAM platform recognizes. You can optionally include extra columns as custom fields or extensible attributes if the target platform supports them.

How do I handle hierarchical subnet relationships during import?

Most IPAM platforms automatically build the hierarchy based on CIDR containment. Import the parent subnets first (e.g., /16 blocks), then import the child subnets (e.g., /24 blocks). The IPAM system will nest children under their parents automatically.

What happens if my source data contains invalid CIDR notation?

The formatter flags invalid entries during the validation step. Common issues include host bits that are not zeroed (like 10.1.1.5/24 instead of 10.1.1.0/24), invalid octet values, and missing prefix lengths. You can fix these in your source data and re-run the conversion, or the tool can auto-correct host bit issues by computing the canonical network address.

Does the formatter handle VRF-aware imports?

Yes, if your source data includes VRF information. NetBox supports VRF as a first-class field, so the formatter maps VRF names directly. For platforms that do not have native VRF support, VRF information can be included in description fields or custom attributes.

Related Tools

• Subnet Plan Diff - Compare old vs new subnet plans
• Address Plan Generator - Generate an IP address plan CSV template
• VLSM Report Generator - Generate printable VLSM allocation reports
• VLAN-to-Subnet Mapper - Map VLANs to subnets with CSV input/output
• Change Impact Report - See what overlaps if a new subnet is added
• Duplicate Subnet Detector - Find duplicate subnets in an IP plan