Moving a SAS4 installation across

The importer reads a standard SAS4 backup and writes it into a tenant you own. It has been run against a real production backup of about 17 million rows, so this page describes the path that was actually taken rather than an ideal one.

Take the backup

Take the backup SAS4 already produces — the compressed SQL dump. You do not need to prepare it, clean it, or restore it anywhere first.

Upload and import

Start a trial, then upload the file from Tools → Import. The import is a background job: it streams the file rather than loading it, so a large backup does not need a large machine, and it can be resumed.

You choose what to do about conflicts before it starts. On a fresh tenant the answer is usually to skip, because there is nothing to conflict with.

What comes across: subscribers with their usernames, passwords, plans, expiry dates and remaining quota; plans with their speeds, quotas, prices and fair-use chains; cards with their series and codes; the manager tree with balances; the money journal and the activation history; and the network device list with its addresses and secrets, ready to be re-pointed.

What does not: panel preferences. They are set again, because the wording differs.

Read the reconciliation

When the job finishes it reports a count per entity, and — this is the part worth reading — a counter for everything it deliberately did not import.

Soft-deleted subscribers are the biggest one. In the reference backup, 1,107,489 of 1,131,110 subscriber rows were deleted records, so the live count was 23,621. Activations behave the same way: the ones belonging to deleted subscribers are counted, not silently dropped.

The arithmetic should add up to the row. If it does, you have a migration you can audit rather than one you have to trust.

Point the network at X-Radius

Change the RADIUS server address on your routers to your instance, using the secrets that came across with the device list.

Then verify with a real login before you cut everything over. In the reference run, migrated subscribers were authenticated with real CHAP requests, with the tenant resolved from an imported device address, and were accepted with their reply attributes intact. Do the same with a handful of your own.

Usernames and passwords do not change, so your subscribers do nothing.

Export back

The exporter writes a SAS4-shaped backup out of your X-Radius tenant whenever you ask for it. In the reference run the round-trip returned exactly the counts that went in.

That exists so that "no lock-in" is a thing you can test rather than a thing we say.

Known differences

• Usernames are unique per tenant, not globally. A name another operator uses is still available to you. Nothing renames on import.
• Activation is idempotent. Every activation carries a request id and a unique constraint, so a retried request cannot charge twice. In SAS4 a retry could duplicate.
• Isolation is enforced by the database. Every tenant table carries a policy, and the application connects as a role that cannot bypass it.