EfficientIP

Tips for migration between EfficientIP SOLIDserver and LightMesh

EfficientIP SOLIDserver is a DNS-DHCP-IPAM (DDI) platform. Many teams want a dedicated system of record for network addressing and IP planning without replacing DNS and DHCP on day one. This guide covers a practical IPAM-focused migration path from SOLIDserver to LightMesh, aligned with the EfficientIP migration overview on tidalcloud.com.

Multi-campus and hybrid estates often accumulate address divergence and secondary inventories beside production DDI. LightMesh is a focused addressing SoR with read-only discovery (SaaS or self-hosted). It sits beside SOLIDserver for shared planning and audit; it never replaces production DNS or DHCP.

What this migration covers

  • LightMesh is the system of record for network addressing with auditable history along the Network Intelligence path. It is not an “AI IPAM” product or a chat-driven shortcut around IPAM discipline.
  • LightMesh does not push DNS, DHCP, or router configuration to EfficientIP or other infrastructure, and it does not replace SOLIDserver as a full DDI suite.
  • There is no native EfficientIP importer shipped in LightMesh; the path remains export or API extract → map → import → validate.
  • Typical migration path: inventory, export from SOLIDserver, import into LightMesh, validate data, run parallel ops, then use LightMesh as the system of record for IP planning while DNS and DHCP authority stay on SOLIDserver unless you separately re-platform those services (out of scope for this guide).

Why teams migrate IPAM to LightMesh

  1. Complement SOLIDserver DDI — SOLIDserver keeps authoritative DNS and DHCP. LightMesh is the IPAM system of record plus cross-environment visibility for addressing, planning, and audit — including multi-campus and hybrid estates where address space and secondary inventories diverge from the DDI view.
  2. Unbundle IPAM from Smart DDI — Move IP planning and allocation workflows to LightMesh without claiming that LightMesh runs authoritative DNS or DHCP for production clients. Before you declare LightMesh the IPAM SoR, inventory workflows where SOLIDserver IPAM triggers DNS/DHCP provisioning. SOLIDserver often couples IPAM to DDI execution; unbundling is an architecture decision, not only a CSV import.

Migration workflow

Follow these phases in order:

  1. Inventory the SOLIDserver estate (version, modules, writers, custom schema, spaces/overlaps).
  2. Export IPAM data from SOLIDserver to CSV (or spreadsheets you normalize to CSV).
  3. Map SOLIDserver fields to LightMesh entities and custom attributes.
  4. Import using LightMesh bulk import. Start with the import documentation hub.
  5. Validate subnets, allocations, and metadata; resolve overlaps before wider rollout.
  6. Parallel ops — run SOLIDserver and LightMesh together while DNS and DHCP stay unchanged on SOLIDserver; maintain one writable IPAM authority.
  7. System of record for IP planning — establish LightMesh as the working SoR for reservations, assignments, and audit after DDI coupling is accounted for.

Step 0: Pre-export inventory

Before export, capture enough estate context that mapping and authority decisions are deliberate:

  • SOLIDserver version and appliance/deployment model.
  • Modules in use — for example overlay versus authoritative DNS/DHCP, and any security or related products you operate alongside IPAM.
  • Writers — Terraform, REST/SOAP API clients, orchestrators, and other automation that create or change IPAM objects today.
  • Custom classes / custom DB fields that runbooks or reports depend on.
  • IP Spaces / VRF / overlapping-address patterns — including whether the same CIDR appears in more than one realm.

Also list workflows where an IPAM change in SOLIDserver triggers DNS or DHCP provisioning. That inventory drives whether you stay on a complement path or deliberately unbundle IPAM from DDI execution.

Step 1: Export IPAM data from SOLIDserver

Export Spaces, Networks, Addresses, Pools, and related IPAM objects from SOLIDserver, then normalize the results to CSV for LightMesh import. Available reports and API service names can differ by SOLIDserver release; confirm details against EfficientIP documentation for your deployment.

Option A: Export Reports (GUI)

Use SOLIDserver Export Reports under Exporting and Importing Data:

  1. Sign in with a read-only or IPAM-reporting role that can view Spaces, Networks, Addresses, and Pools.
  2. Open Export Reports and run or schedule reports for the IPAM objects you need.
  3. Download results as CSV (or XLSX that you convert to CSV before LightMesh import).

Build one export per object type when a single report cannot combine Networks and Addresses cleanly.

Option B: REST or SOAP list APIs

SOLIDserver exposes IPAM through REST and SOAP APIs. For migration extracts, call read-only list (and where needed, info) services, then serialize results to CSV in a script or integration tool. Target IPAM object families such as Space, Network, Pool, and Address (including IPv4/IPv6 variants as documented for your release).

  1. Use credentials with read-only IPAM scope where possible.
  2. Page through list responses for each object type you need.
  3. Flatten JSON or XML into columns that match the field map below.
  4. Write one CSV per LightMesh import type (subnets, IP addresses, sites, zones) when required by the import templates.

After export

  • Deduplicate overlapping Network and Pool rows before import.
  • Keep a copy of raw exports for audit and rollback comparison.
  • Do not change DNS, DHCP, or router configuration as part of this export step.

Step 2: Map SOLIDserver fields to LightMesh

LightMesh imports expect specific columns per entity type. Map SOLIDserver export columns to native LightMesh fields first; push everything else to custom attributes on the matching entity (Subnets, IP Assignments, Zones, Sites, and so on). Define custom-attribute schema before import when you carry class parameters or custom DB fields.

Typical SOLIDserver IPAM source LightMesh target Import guidance
IP Space / overlapping address realm Zone, Network Container, and/or preserved source-space metadata Keep realms separated; do not flatten overlapping Spaces into one undifferentiated hierarchy.
Network, subnet, or container (CIDR) Subnet Name, subnet CIDR, parent hierarchy. See subnet import.
Pool or child range under a Network Subnet (nested) or parent subnet Model Pools as child subnets when they represent allocatable space; preserve source type in a custom attribute when useful.
Address or host reservation row IP assignment Zone, subnet CIDR, IP address. See IP address import.
Site, location, or region label Site Site import.
Class parameters / custom DB Custom attributes Define schema in LightMesh before import; map each critical parameter or custom DB field deliberately.
SOLIDserver object ID Custom attribute (immutable source lineage) Preserve object IDs as immutable lineage keys for reconciliation and audit.
DNS zone name (reference only) Zone or custom attribute on subnet/IP Document linkage; LightMesh does not become authoritative DNS.
DHCP scope or shared-network name (reference only) Custom attribute Store scope ID or name for operations context; DHCP stays on SOLIDserver.
VLAN, VRF, owner, ticket ID, business unit Custom attributes (or native relationship where available) Create fields in Schema before import; preserve IDs.
Contact or owner name Contact (optional) Contact import when you track owners in LightMesh.

Import subnets and sites before IP assignments so CIDR and zone references resolve. Use custom attributes to preserve SOLIDserver-specific properties that have no native LightMesh column.

Step 3: Import into LightMesh

  1. If you have not already, start a trial with LightMesh.
  2. Log in with a role that can import (Owner, Administrator, or Contributor). See Roles and RBAC.
  3. Use the import documentation hub for file types (.csv, .xls, .xlsx) and links to each entity import guide.
  4. Import a pilot scope (one site, region, or address block), validate row counts and spot-check allocations, then expand.
  5. Optionally enrich with read-only context: DHCP discovery, cloud integrations, or additional CSV imports. These paths ingest operational data; they do not push configuration to SOLIDserver.

Step 4: Validate before parallel ops

  • Compare subnet and IP counts between SOLIDserver exports and LightMesh for the pilot scope.
  • Resolve overlapping CIDRs, duplicate assignments, and orphan IPs — including overlaps that only collide after Spaces are flattened incorrectly.
  • Confirm custom attributes populated for fields your runbooks depend on (class parameters, custom DB, source lineage IDs, source-space metadata).
  • Document known gaps (for example, objects you chose not to migrate yet).

Step 5: Parallel ops checklist

Parallel ops means SOLIDserver continues to serve production DNS and DHCP while LightMesh becomes the system of record for IP planning. Use this checklist during the overlap period:

  • One writable IPAM authority — after cutover of planning, new address intent is written in LightMesh only. Do not keep two independently writable IPAM systems of record. SOLIDserver remains authoritative for DNS and DHCP.
  • DNS unchanged on SOLIDserver — zone files, records, and DNS workflows are not driven or overwritten by LightMesh.
  • DHCP unchanged on SOLIDserver — scopes, options, leases, and failover remain on SOLIDserver appliances or services.
  • Router and forwarding config unchanged — LightMesh does not push routing or interface configuration to network devices.
  • DDI coupling inventoried — workflows where SOLIDserver IPAM previously triggered DNS/DHCP provisioning are redesigned or explicitly retained before LightMesh is declared the IPAM SoR.
  • Authority documented — runbooks state that new reservations and IP planning happen in LightMesh; DNS/DHCP changes still follow SOLIDserver change control until a separate re-platform project.
  • Pilot validated — stakeholders signed off on the pilot scope in LightMesh versus SOLIDserver exports.
  • Automation aligned — scripts and integrations that consumed or wrote SOLIDserver IPAM data are updated or dual-read only where intentional; writers that create address intent target LightMesh after cutover.
  • Rollback path — retain SOLIDserver exports and a written revert plan for the pilot scope if validation fails.

When parallel ops are stable, expand imports region by region. DNS and DHCP authority remain on SOLIDserver unless you run an explicit, out-of-scope DDI cutover project.

Non-goals for this migration

This guide and LightMesh do not cover or promise:

  • Configuration push-back — No DNS, DHCP, IPAM, or router configuration is written from LightMesh into SOLIDserver or network devices.
  • Native SOLIDserver connector — LightMesh does not ship a built-in, bi-directional SOLIDserver sync connector or a native EfficientIP importer. Migration is export, transform, and import (plus optional read-only discovery elsewhere in the product).
  • DDI appliance cutover — Replacing SOLIDserver DNS/DHCP appliances or decommissioning Smart DDI is a separate program, not part of this IPAM migration path.
  • DNS Guardian, DNS Blast, SmartArchitecture, DNS Firewall, or Threat Intelligence (TI) — This guide does not describe EfficientIP security or architecture products. It addresses IPAM data movement to LightMesh only.
  • Full DDI replacement on day one — You can modernize the IPAM layer first and defer DNS and DHCP migration indefinitely.

What LightMesh does not do

  • Act as authoritative DNS or DHCP for production clients.
  • Replace network monitoring or NMS tools (SNMP, flow, or full observability platforms).
  • Replace SOLIDserver as a full DDI suite without a separate customer-led re-platforming effort.

Key benefits of LightMesh IPAM

  • Intuitive interface: Plan and search address space across cloud and on-prem from one place.
  • Advanced planning: Use subnet planning, division, and building tools to design address space before provisioning.
  • Audit history: See who changed a record and when on the IPAM system of record.
  • Cloud and integrations: Connect AWS and Azure, use the API and CLI, and integrate downstream tools without pushing config into SOLIDserver.

Get started with LightMesh today

Ready to try the migration path? Start a trial, import a pilot scope, and validate your data. Register for a trial.

If you have questions during migration, contact Tidal support.

Previous
Next