Migrating from SolarWinds IPAM to LightMesh

Network teams increasingly need IPAM data that works everywhere: in CI/CD pipelines, across cloud environments, and integrated with security tooling. If you’re running SolarWinds IP Address Manager and looking to modernize, this guide walks you through migrating to LightMesh—a solution that preserves the IPAM fundamentals you rely on while adding the portability and automation capabilities modern networks demand.

This is a practical migration walkthrough. It compares the two platforms, explains how to extract and clean your data, map your organizational structure, import and validate, and plan a rollback if anything goes wrong. It also covers DHCP, DNS, cloud discovery, and integrations so the migration does not stop at subnet import.

Why Replace SolarWinds Now?

SolarWinds IP Address Manager has served many organizations well for traditional on-premises network management. However, as networks expand into AWS, Azure, and hybrid architectures, teams are discovering gaps:

• Cloud visibility: SolarWinds was not built for dynamic cloud networking.
• API limitations: Modern automation requires robust, developer-friendly APIs.
• Data portability: IP metadata should enrich logs, security events, and your CMDB.
• Operational speed: Manual workflows cannot keep pace with cloud-native deployments.

LightMesh addresses these gaps while maintaining the core IPAM capabilities your team depends on. The migration path below is the same one we walk customers through, adjusted for the size of their estate and the integrations they use.

LightMesh vs SolarWinds: Feature Comparison

Core IPAM Capabilities (Both Platforms)

Both SolarWinds and LightMesh deliver essential IPAM functionality:

• IPv4 and IPv6 subnet management.
• VLAN, VRF, and site organization.
• DHCP and DNS awareness.
• IP address tracking and reservation.

Where LightMesh Pulls Ahead

The table above reflects our qualitative assessment of the two products based on typical deployments we see. Treat it as a starting point, not a benchmark. Your exact experience depends on the SolarWinds modules you have deployed, the size of your estate, custom fields, and integrations. Verify any capability that affects a go/no-go decision against the current SolarWinds IPAM documentation and the LightMesh documentation.

Migration Workflow Overview

The migration has seven stages. The diagram below shows the order, decision points, and rollback path.

flowchart TD
    A[Inventory SolarWinds IPAM] --> B[Export subnets, addresses, DHCP/DNS references]
    B --> C[Clean and normalize data]
    C --> D[Map hierarchy and metadata to LightMesh]
    D --> E[Import into LightMesh]
    E --> F{Validation passes?}
    F -->|No| G[Fix data and re-import]
    G --> E
    F -->|Yes| H[Run parallel operation]
    H --> I{Cutover trigger met?}
    I -->|No| H
    I -->|Yes| J[Make LightMesh authoritative]
    J --> K[Archive SolarWinds export and retain read-only access]

Step 1: Prepare and Inventory

Before exporting anything, document your current state:

• Identify managed spaces: List all IPv4/IPv6 subnets, VLANs, and VRFs.
• Confirm authoritative sources: Note which DNS zones and DHCP scopes SolarWinds manages versus references.
• Plan your LightMesh structure: Decide on organization hierarchy, site naming, and tagging conventions.

If you have never used LightMesh before, read Migrate from SolarWinds to Tidal’s Modern IPAM Solution for a shorter overview and LightMesh for product context.

Step 2: Export from SolarWinds

SolarWinds provides export capabilities under Settings → IP Address Management → Export. See the SolarWinds export documentation for the current steps.

Export Considerations

Plan your exports in batches rather than one giant dump:

• Subnets first: Export the subnet tree separately from individual addresses. A single export often omits parent-child relationships or flattens the hierarchy.
• IP addresses and reservations next: Export active addresses, reservations, and DHCP lease records. Decide whether you need historical lease data; LightMesh does not require it for a cutover, but it can be useful for audit context.
• DHCP scopes separately: SolarWinds may store DHCP scopes as a different object type. Export scope names, ranges, exclusions, and server associations explicitly.
• DNS zones and records: If SolarWinds tracks DNS zones, export zone names and record sets. LightMesh will reference these, but your DNS infrastructure typically remains authoritative.
• Custom fields and ownership: Export any custom fields, ownership attributes, and comments you want to preserve as LightMesh tags.

Expect CSV quirks: multi-line descriptions, inconsistent quoting, trailing spaces, and mixed date formats. Open each export in a text editor or script before importing so you can catch encoding or delimiter issues.

Step 3: Clean and Normalize Your Data

Clean exports before importing to ensure a smooth transition:

• Remove duplicates: Identify and consolidate duplicate subnet or address entries. SolarWinds sometimes contains overlapping records from repeated discovery jobs.
• Mark stale records: Flag retired or reserved addresses appropriately. Do not import decommissioned hosts as active.
• Standardize naming: Ensure consistent CIDR notation, VLAN names, and site codes. For example, choose one format for VLAN identifiers and site abbreviations and apply it everywhere.
• Normalize CIDR notation: Convert subnets to a uniform prefix length (10.0.0.0/24, not 10.0.0.0 255.255.255.0).
• Map custom fields: Convert SolarWinds custom fields to LightMesh tags. Keep the mapping documented so you can reverse it if needed.

A small spreadsheet with source field, target tag, and example values will save time during import and future audits.

Step 4: Map Hierarchy and Custom Metadata

Hierarchy Mapping

SolarWinds organizes objects into groups and sites. LightMesh uses organizations and sites. A typical mapping looks like this:

If your SolarWinds deployment uses nested groups, decide whether to flatten them into tags or create nested organizations in LightMesh. Document the decision and share it with the team running the import.

Custom Metadata Mapping

SolarWinds custom fields often carry ownership, cost center, environment, or application context. In LightMesh these become tags. A one-page mapping table is enough for most migrations:

• Source field name.
• Target LightMesh tag key.
• Cardinality (single value vs. multiple values).
• Example values.

Keep the mapping under version control. If the first import reveals bad source data, you can adjust and re-run without guessing.

Step 5: Import into LightMesh

With clean data ready, import into LightMesh:

1. Create your hierarchy first: Set up organizations and sites before importing subnets.
2. Import subnets and addresses: Use LightMesh’s import feature.
3. Add DHCP/DNS mappings: Import scope and zone references.
4. Apply tags and ownership: Assign metadata for operational context.

For a visual walkthrough of the import process, see the SolarWinds migration overview and the import tutorial video embedded there.

Step 6: Validate the Migration

Before cutover, verify completeness:

• Compare counts: Subnet totals, free capacity, reserved blocks.
• Spot-check critical networks: Validate production, management, and security subnets.
• Verify references: Confirm DHCP scope and DNS zone mappings are intact.
• Test API access: Ensure integrations can query the new system.

Import Validation Checklist

Run the spot-checks with a network engineer who knows the live topology. Automated counts catch bulk errors, but only a human spot-check catches wrong hierarchy or mislabeled VLANs.

Step 7: Cutover and Rollback Planning

Once validated, make LightMesh your source of truth:

• Update change management workflows to use LightMesh.
• Redirect automation to pull from LightMesh APIs.
• Decommission SolarWinds IPAM (keep exports archived for reference).

Rollback Planning

Never cut over without a rollback path. At minimum:

• Keep SolarWinds read-only until the first successful change cycle in LightMesh.
• Archive the final pre-cutover export with a timestamp and checksum.
• Define cutover trigger conditions: validation checklist passes, two engineers sign off, and a rollback window is scheduled.
• Define rollback trigger conditions: more than a defined threshold of missing subnets, broken DHCP/DNS references, or failed automation queries.

The following decision tree summarizes the rollback logic.

flowchart TD
    A[Validation checklist passes] --> B{Two engineers sign off?}
    B -->|No| C[Fix blockers and re-validate]
    C --> A
    B -->|Yes| D[Enter read-only parallel operation]
    D --> E{Automation queries succeed for 24-48h?}
    E -->|No| F[Investigate and fix, or trigger rollback]
    E -->|Yes| G[Make LightMesh authoritative]
    G --> H{Critical error within rollback window?}
    H -->|Yes| I[Restore SolarWinds from archived export and redirect automation]
    H -->|No| J[Complete cutover and archive final state]

DHCP and DNS During Migration

DHCP

DHCP is usually a reference source, not the IPAM itself. During migration:

• Export DHCP scopes and server associations from SolarWinds.
• Import scope references into LightMesh so subnet views show live utilization.
• For live lease synchronization, deploy the LightMesh Windows Discovery Agent. Read LightMesh DHCP Integration: Always Know What Is on Your Network for how lease data stays current inside LightMesh.

The DHCP servers themselves generally do not move. LightMesh becomes the planning and visibility layer while the existing DHCP infrastructure continues to issue addresses.

DNS

DNS records remain authoritative on your DNS servers or cloud resolver. In LightMesh:

• Import forward and reverse zone references.
• Link subnets to the zones that serve them.
• Use LightMesh search to resolve which DNS zone answers for an IP or subnet.

If SolarWinds was acting as your DNS server, that is a separate infrastructure migration. Most teams keep BIND, Windows DNS, or a cloud resolver and only migrate the IPAM layer.

Cloud Discovery During Migration

AWS

LightMesh connects to AWS using a read-only cross-account IAM role with external ID validation. After the on-prem IPAM data is imported, connect your AWS accounts so LightMesh discovers VPCs, subnets, and IP allocations automatically. See LightMesh + AWS: Secure Subnet Discovery and Unified IPAM at Scale for the setup steps.

Typical migration order:

1. Import on-prem data from SolarWinds.
2. Validate hierarchy and tags.
3. Connect AWS accounts to LightMesh.
4. Reconcile cloud CIDRs against the imported plan to find overlaps or undocumented ranges.

Azure

The Azure integration uses a read-only service principal. It discovers VNets and subnets across subscriptions. See LightMesh + Azure: Real-Time IPAM and VNet Visibility in Minutes for the setup.

If you already documented Azure ranges in SolarWinds, treat the first LightMesh sync as a reconciliation pass. Any CIDR in Azure but missing from SolarWinds should be added to the plan before cutover.

Integrations During Migration

Modern IPAM is only useful if it feeds the tools that consume it. Plan integrations early:

• CI/CD pipelines: Use the LightMesh GraphQL API to request and release IPs during deployments.
• Infrastructure as Code: Query available subnets from Terraform or Ansible before applying changes.
• SIEM and log enrichment: Push IP ownership, service context, and location into security tooling so alerts include network context.
• CMDB: Keep configuration items in sync by pulling from LightMesh as the source of truth.

LightMesh is built for teams that need IPAM data in CI/CD pipelines, cloud environments, and security tooling—without the export-and-reimport overhead legacy IPAM imposes.

Next Steps by Reader Stage

If you need help mapping your specific environment, contact our team for a personalized assessment.

Resources to Get Started

• SolarWinds Migration Guide — Detailed technical walkthrough.
• SolarWinds to LightMesh overview — Shorter introduction to the switch.
• LightMesh + AWS integration — Cloud discovery and IPAM at scale.
• LightMesh + Azure integration — Real-time VNet visibility.
• LightMesh API documentation — Reference for automation and integrations.
• Contact our team — Personalized migration assessment.

Have questions about your specific migration scenario? Contact our team for a personalized assessment.