/
Imports and Migrations

Imports and Migrations

NMS Prime supports multiple ways to import data from external systems. In practice, there are two main paths: use an existing built-in importer, or implement a custom integration for a source system that is not yet covered. This makes NMS Prime a flexible migration platform for broadband operators that need to bring customer, provisioning, property, or service data into a single OSS/BSS environment.

Quick summary: NMS Prime already includes several import commands via php artisan, supports CSV-based imports as a general fallback, and can also be extended for custom source systems or automated workflows. A public showcase related to automated workflows is available here: https://www.youtube.com/watch?v=FcJ1duu3gyo.

Import approaches

When migrating from “any system”, the best approach depends on the source data format, data quality, and how often the transfer must run.

  • Built-in importer commands: Best when the legacy system already matches one of the known source systems supported by NMS Prime.

  • Generic CSV import: Best for one-time migrations or when the legacy system can export structured CSV files.

  • Database-based import: Best when the source system exposes a directly readable database and field mapping is stable.

  • API or workflow automation: Best when data should flow continuously or semi-automatically between systems.

  • Custom importer development: Best when the source system is proprietary or has unusual business rules.

Rule of thumb: If the source system can export clean CSV or provides database access, an import is usually straightforward. If business rules, product logic, or provisioning structures differ heavily, a custom mapping or staged migration is usually the safer option.

Built-in import commands

NMS Prime already ships with a useful set of import commands. These cover both generic data import and source-specific migrations.

Command

Purpose

Typical source

Notes

Command

Purpose

Typical source

Notes

import:apartments

Import node, realty, and apartment data from CSV

CSV export

Useful for property-related migration scenarios

import:avp

Import customers from CSV and add TV tariff

CSV export

Specialized importer

import:csv

Import from one single CSV

Generic CSV

Described as aligned first to Momentum data and intended to be adapted for future CSV imports

import:km3

Import km3 data

km3 system

Source-specific importer

import:knm

Import customers and properties from 3 CSV files extracted from KNM

KabelNetManager

Combines multiple source files

import:netuser

Import all provisioning data from a NetUser database

NetUser database

Database-driven migration path

import:nms

Import NMS Prime database

Another NMS Prime instance

Useful for consolidation or environment migration

import:pinet

Import data from Pinet/Navision MSSQL database

Pinet/Navision MSSQL

Database-driven importer

import:quickline

Import either product or customer data from Quickline as CSV

Quickline CSV

Supports different import scopes

import:thuega

Import customer data from Thüga CSVs

Thüga CSV files

CSV-based source-specific importer

import:tv

Import customers from CSV and add TV tariff

CSV export

Specialized tariff-oriented importer

These commands show that NMS Prime is not limited to one import style. It can handle customer migration, provisioning data, property structures, and cross-system transitions.

What “import from any system” usually means

In real migration projects, “any system” does not mean a magical universal connector. It usually means NMS Prime can ingest external data as long as there is a workable extraction and mapping strategy.

  • Source extraction: Export the relevant records from the old system via CSV, SQL, or API.

  • Field mapping: Match legacy fields to NMS Prime entities such as contracts, modems, MTAs, phone numbers, realties, apartments, QoS, or products.

  • Transformation: Normalize addresses, identifiers, MAC formats, phone data, tariff names, and status values.

  • Validation: Detect missing mandatory fields, duplicates, invalid relations, and inconsistent provisioning attributes.

  • Controlled import: Run test imports first, verify object counts and relations, then execute the production migration.

For many operators, the real project effort is not the file transfer itself but the cleanup and mapping of legacy data into a clean target model.

Important context: NMS documentation and service material explicitly state that NMS supports import of existing provisioning data from previously used systems, with current implemented support including km3, NetUser, and CSV data. Additional import routines can be implemented if needed.

Recommended migration pattern

  1. Identify the target entities



    Decide what must be migrated: customers, contracts, services, modems, telephony objects, property data, products, invoices, or provisioning settings.

  2. Choose the best entry path



    Use a built-in importer if available. Otherwise prefer import:csv or a source-specific adaptation if the source can export structured files.

  3. Prepare staging data



    Clean duplicates, standardize formats, and define stable keys for linking records across files.

  4. Run a test import



    Import into a test environment first. Compare record counts and spot-check relations such as contract-to-modem or realty-to-apartment assignments.

  5. Validate provisioning impact



    Check whether imported data is only administrative or also affects live provisioning, config generation, DHCP, telephony, or billing.

  6. Execute production cutover



    Run the import in a planned window, verify results, and keep rollback backups.

php artisan import php artisan import:csv php artisan import:nms php artisan import:netuser

Migration safety: Always work from a backup and test in a non-production environment first. NMS Prime documentation also emphasizes creating database backups before destructive or large-scale changes.

Automation and extensibility

If a one-time import is not enough, NMS Prime can also fit into broader automation scenarios.

  • Workflow automation: The showcased n8n video suggests an orchestration pattern for network operators, useful for syncing events or records between systems.

  • API-based integration: NMS Prime exposes an API for creating, modifying, and deleting core objects such as contracts, modems, MTAs, phone numbers, and QoS objects.

  • Custom module development: If a legacy platform requires a dedicated connector, NMS Prime’s modular Laravel-based architecture supports creating new modules and migrations.

This means there are three practical integration layers: direct importer commands, API-driven synchronization, and custom application logic.

Use importer commands for bulk migration, one-off onboarding, or repeatable file/database imports from known sources.

Use the API when data must be created or updated continuously from CRM, order portals, or external automation platforms.

Best-fit guidance

Situation

Recommended option

Why

Situation

Recommended option

Why

You already use a supported legacy source like NetUser, Pinet/Navision, KNM, km3, Quickline, or Thüga

Use the matching import:* command

Fastest route with less custom work

Your old system can export CSV but has no dedicated importer

Start with import:csv

Good baseline for mapping and adaptation

You need ongoing sync with CRM, order portal, or another OSS

Use API and workflow automation

Better for repeatable, event-driven integration

Your source model is unusual or highly customized

Build a custom importer/module

Safer for preserving business logic and relations

Bottom line: NMS Prime can import from many systems in practice because it combines ready-made importers, generic CSV handling, API access, and an extensible architecture for custom connectors.

References