Migrate an ISP Billing Platform Without Losing the Audit Trail

Define what “same business” means after migration

A successful cutover is not proven by a login screen or a subscriber count. It is proven when the new system represents the same obligations, payments, service entitlements and network identities as the old one at a declared point in time.

Write that declaration before exporting data. It should state the financial cutoff, the timezone, which open transactions are included, how prepaid validity is interpreted, and whether historical detail or opening balances will be carried forward.

Inventory semantics before columns

Two databases may both contain a field named balance and mean opposite things. One stores customer credit as positive; another stores debt as positive. An expiry date may mean the last paid day, the suspension day, or a display-only value recalculated elsewhere.

Create a mapping document that describes business meaning, transformation and validation—not just source and destination column names.

Clean data in a staging area

Do not repair the source production database to make an import pass. Land immutable extracts in a staging area, checksum them, and run transformations there. This keeps the old platform available for comparison and makes the migration repeatable.

1. Extract. Export a documented snapshot with counts, timestamps and checksums.
2. Profile. Report nulls, duplicates, invalid dates, orphaned packages and unknown ownership.
3. Transform. Normalize phone numbers, identifiers and policy values using version-controlled rules.
4. Load. Import into a non-production copy of the target with external actions disabled.
5. Reconcile. Compare financial totals, service states and network policy samples.
6. Repeat. Run the same pipeline until the unexplained difference is zero or formally accepted.

Test accounts chosen for risk, not convenience

A random sample can miss the conditions that break migrations. Build a test deck from boundary cases: active and suspended subscribers, advance balances, partial payments, custom package prices, static IPs, multiple services, sub-operator ownership, tax exemptions and sessions crossing the cutoff.

For each case, record the expected invoice balance, entitlement decision and RADIUS policy before opening the target system. The test passes only when those values are explained—not when they merely look plausible.

Run both decision engines in shadow mode

Before cutover, ask both platforms to calculate selected outcomes without allowing the new system to enforce them. Compare upcoming invoices, customers due for suspension, package prices, RADIUS reply attributes and notification recipients.

Differences fall into three groups: bad source data, incorrect mapping, or an intentional policy change. Resolve the first two before launch. Document the third and obtain business approval so a migration does not quietly become a pricing or collection-policy change.

Create a finite write freeze

The final delta is easiest to control when the old platform stops accepting selected changes for a short, announced period. The freeze should cover the records being copied—typically customer edits, package assignments, manual payments and ownership changes. Network service can remain online.

Gateway events arriving during the freeze need a holding procedure. Either process them in the old system and include a final delta, or queue them for idempotent processing in the new system. Never post the same provider transaction to both.

Make rollback operationally possible

Rollback is not “we still have a backup.” It is a timed procedure with a decision owner. Define which failures justify rollback, how new writes made after go-live will be exported, and how RADIUS or router endpoints return to the old platform.

• Keep the old platform read-only and intact through the stabilization window.
• Record every post-cutover financial event in an exportable journal.
• Use DNS, virtual IP or documented NAS changes that can be reversed predictably.
• Set a deadline after which roll-forward repair is safer than rollback.
• Assign one person to declare rollback; avoid decision-making by group chat.

Close with reconciliation, not confidence

After launch, compare opening receivables, credits, payments held during cutoff, active subscriber counts, suspended counts and live RADIUS sessions. Review failed notifications and enforcement jobs separately. A successful login from one customer proves only that one path worked.

• All imported records have a source identifier for traceability.
• Financial totals match the signed cutoff report.
• No user role can see accounts outside its previous ownership boundary.
• Every package produces an approved network policy.
• Gateway callbacks are idempotent across the cutover window.
• Rollback steps were tested before the final go-live decision.

Research basis: repeatable database migration practice, financial reconciliation controls and RADIUS cutover operations. Retention, tax and invoice rules must be reviewed with the organization’s accountant and local regulatory requirements.