← Back to Blog

Splynx Alternative: Why ISPs Are Migrating to Veloxiom

Splynx is a capable ISP management platform with a long track record. Most providers who start looking for an alternative are not unhappy with its feature list — they are unhappy with one of four specific things: per-subscriber licence cost that scales faster than revenue, e-invoicing that has to be bolted on for their country, a closed data model that makes custom reporting painful, or a support loop that is too slow when subscribers are offline. This guide covers what to evaluate, how to run the comparison honestly, and how to migrate without a service window.

Be Specific About Why You Are Migrating

Migrating a billing system is the single riskiest operational project a small ISP will undertake. Invoices, tax records, RADIUS credentials and payment mandates all live in the same dataset, and a mistake shows up as either subscribers wrongly disconnected or revenue silently not billed. Before you evaluate anything, write down the two or three problems you actually need solved. If you cannot name them, the safer decision is to stay where you are.

The reasons that genuinely justify the risk usually fall into these categories:

• Licence cost per subscriber. Platforms priced per active subscriber turn growth into an increasing fixed cost. At 500 subscribers it is an annoyance; at 5,000 it is a line item that changes your pricing.
• Country-specific compliance. Greek ΑΑΔΕ myDATA, ΔΙΑΣ direct debit, Italian SDI, Hungarian NAV — these are not optional. If they are handled by a third-party connector, every tax rule change becomes a dependency on someone else's release schedule.
• Data ownership and reporting. You will eventually need a report nobody built for you: churn by area, ARPU by plan, CPE failure rate by firmware version. That requires direct access to your own database.
• Operational context in one place. When a subscriber calls, the person answering should see the PPPoE session, the last disconnect reason, signal levels on the link, open tickets and unpaid invoices on one screen — not in four systems.

What to Compare — the Questions That Actually Matter

Feature checklists are close to useless when comparing ISP platforms, because every vendor can claim every row. These questions are harder to answer dishonestly:

1. What exactly happens when a subscriber does not pay?

Ask for the full chain: which day the invoice is generated, when the reminder is sent, what triggers suspension, whether suspension is a RADIUS Change-of-Authorization to a walled-garden profile or a hard disconnect, whether the subscriber sees an explanatory captive portal, and what happens the second the payment lands. A platform that only "marks the customer as blocked" leaves the actual enforcement to you.

2. Is RADIUS a first-class component or an integration?

PPPoE authentication, accounting, per-plan rate limits, IP pool assignment and CoA are the core of a subscriber network. If the platform writes RADIUS attributes but cannot show you live sessions, disconnect a single subscriber, or explain an Auth-Reject, you will spend your life in the router CLI anyway.

3. Who owns the data, and can you leave?

Ask for a full export in the vendor's own format and check whether it includes invoice line items, payment history and tax submission identifiers — not just a customer list. The ease of getting your data out of the new platform is the best available proxy for how it will treat you as a customer.

4. Where does it run, and what is the failure mode?

If billing is SaaS and your RADIUS is on-premise, decide now what happens when the link between them drops. Subscribers should keep working. Many implementations fail closed and disconnect everyone — verify it rather than assume.

5. What does the second year cost?

Total cost is licence plus modules plus e-invoicing connector plus support plus the hours your team spends on manual work the platform did not remove. Compare the second year, not the first — that is when discounts end and subscriber counts have grown.

How Veloxiom Approaches the Same Problems

Veloxiom is a self-hosted, multi-tenant ISP platform: subscriber and CRM records, service plans, billing and invoicing, RADIUS/PPPoE, MikroTik and multi-vendor router management, TR-069 provisioning, IPAM, SNMP monitoring, helpdesk and a NOC view, in one database you control.

• Greek e-invoicing is part of the billing engine. ΑΑΔΕ myDATA submission and ΔΙΑΣ direct-debit files are produced from the same invoice records, so a submission failure is visible next to the invoice instead of inside a connector's log.
• RADIUS is not an add-on. Plans map to RADIUS attributes, suspension is implemented as a real CoA or disconnect, and live PPPoE sessions are visible per subscriber with the last disconnect reason.
• Self-hosted by default. The database is yours; you can query it, back it up and report on it without asking permission.
• Multi-tenant. One installation can serve several operators with separate data, branding and domains — useful for groups and for resellers.
• Network context on the subscriber record. Router, interface, CPE, signal history, tickets and balance on one screen, because that is what shortens a support call.

Where it is not a fit, honestly: if you want a fully managed SaaS where somebody else patches the server, a self-hosted platform is more responsibility, not less. You need someone who is comfortable operating a Linux host, a database and backups.

How the Migration Works

1. Connect — enter your Splynx API key and secret in Veloxiom's migration screen.
2. Dry-run — review the full list of records that would be created, with conflicts and missing fields flagged before any write.
3. Import — customers, service plans, services, tariffs and balances are created; re-running the import updates instead of duplicating.
4. Parallel run — keep Splynx as the source of truth while you verify authentication and invoicing against it.
5. Cut over — point RADIUS at Veloxiom and switch billing for the next cycle.

The Migration Order That Avoids Outages

The sequence matters more than the tooling. This order keeps every failure reversible:

1. Read-only import first. Import subscribers and plans and change nothing on the network. Compare counts, balances and plan assignments against the old system until they reconcile exactly.
2. Authentication second, for a pilot group. Move 10–20 subscribers — including one of each plan type and one static-IP customer — to the new RADIUS and watch accounting for a full day.
3. Billing third, and run it in parallel. Generate a full invoice run in the new system without sending anything. Compare it line by line with the old system's run for the same month. Investigate every difference; there is always at least one, usually proration or VAT rounding.
4. Enforcement last. Enable automatic suspension only after one clean parallel billing cycle. This is the step that can wrongly disconnect a paying customer, so it should be the last thing you turn on and the first thing you can switch off.

Keep the old system readable for at least one full tax period. You will need it for a dispute, an audit or a credit note against an invoice it issued.

Things That Are Routinely Forgotten

• Invoice numbering. Tax authorities require unbroken sequences. Decide whether the new system continues the old series or starts a new one, and document the decision before the first invoice.
• Payment mandates. Direct-debit authorisations are legal documents tied to a creditor identifier. They usually cannot simply be copied between systems.
• Static IP assignments. Business customers with static addresses and their own firewall rules are where migrations break most visibly.
• Historical accounting data. Traffic history for the retention period your regulator requires must be exported before you stop paying for the old platform.
• Email and SMS templates. Reminders, suspension notices and invoice mails have to be rebuilt and tested against a real mailbox, not just previewed.

Frequently Asked Questions

Can I run Splynx and Veloxiom at the same time?

Yes, and you should. The importer is idempotent and read-only against Splynx, so you can keep it as the source of truth and re-sync while you validate. Only RADIUS authentication must have a single owner at any moment — that is the one cut-over that has to be scheduled.

How long does a migration take?

A first import typically completes in under an hour. The honest total, including a parallel billing cycle and verification, is two to six weeks for a few thousand subscribers — and almost all of that is verification, not import.

Will my subscribers notice?

They should not. PPPoE credentials are migrated unchanged, so sessions reconnect against the new RADIUS with the same username and password. What subscribers do notice is invoice layout and numbering, so tell them before the first new invoice goes out.

Is Veloxiom cheaper than Splynx?

It depends on your subscriber count and which modules you use, so treat any blanket claim with suspicion. Build the comparison for your numbers over two years, including the e-invoicing connector, support and the server you will host it on.

What happens to myDATA submissions already made in the old system?

They stay valid — they were submitted to the ΑΑΔΕ, not to the platform. Keep the submission identifiers and the marks exported, because a later credit note has to reference the original invoice.

Related Reading

• How to automate ISP billing — the invoice, reminder and suspension chain in detail.
• MikroTik RADIUS authentication setup — PPPoE, CoA and disconnect, step by step.
• ΑΑΔΕ myDATA e-invoicing for Greek ISPs — what a provider actually has to submit.
• From spreadsheets to automation — if you are not migrating from a platform at all.

Try Veloxiom Free Demo