Migration should reduce risk, not create it
An ISP billing migration touches customers, balances, invoices, routers, RADIUS, payments, support, and staff habits. The safest path is to coexist first, prove a narrow workflow, then move more operations after the team has evidence.
What to prepare
- Customer records and contact details.
- Plans, tariffs, and service packages.
- Account balances, deposits, credits, and unpaid invoices.
- Router and NAS mappings.
- RADIUS users, groups, and policy names.
- Payment methods and reconciliation rules.
- Support history and open issues.
- Inventory and assigned equipment when available.
Coexistence rollout
| Phase | Goal | |---|---| | Import | Load customers, plans, balances, and service identifiers. | | Connect | Attach MikroTik, FreeRADIUS, UISP, payment, or custom connectors. | | Prove | Run one workflow such as paid customer restoration in parallel. | | Expand | Add support, field service, inventory, and more billing actions. | | Cut over | Make ISPAgents the operating source of truth after validation. |
Cutover checklist
- Confirm every active subscriber has a service identifier.
- Confirm every plan maps to an access policy.
- Confirm overdue and paid states produce the expected network action.
- Confirm support can see billing and access evidence.
- Confirm finance can reconcile payments and statements.
- Confirm rollback steps are documented before changing production access.
FAQ
Can ISPAgents import from CSV or Excel?
Yes. CSV and Excel import are part of the migration path because many small ISPs keep key operating data outside the billing system.
Can we keep Splynx running during testing?
Yes. Coexistence is the preferred path. ISPAgents can prove selected workflows before the operator decides to cut over more operations.