Migrating off Digitalk: what actually breaks
Replacing a long-lived prepaid voice platform rarely fails on the obvious things. It fails on the accumulated detail. Here is where these migrations actually get stuck.
A prepaid calling platform that has been live for many years is never a single clean dataset. It is the original design, the configuration that drifted from it, the data customers created, the fixes operations applied under pressure, and the undocumented behaviour that keeps the service running.
Digitalk was the dominant platform for calling card and prepaid voice operators through the 2000s and into the 2010s. Many of those deployments are still live. The operators running them are, in many cases, still carrying real traffic on corridors that remain commercially meaningful — which is precisely why the platform has never been replaced. It works well enough to defer the question.
Digitalk is the platform many operators name when they start planning a replacement, so it is a useful reference point. The hard parts, though, are general to any ageing on-prem prepaid voice system. The migration almost never breaks on the headline step. It breaks on the detail underneath it.
Where migrations get stuck
The risk is concentrated in a handful of areas. Each one is manageable on its own, but together they decide whether a cutover is a controlled event or an open-ended firefight.
Rate tables and zone definitions
Years of edits leave rate decks with format drift, overlapping prefixes, duplicated zone labels, and stale destinations that no longer route. A clean A to Z deck on the new platform depends on resolving those conflicts before load, not after.
PIN and account data
Prepaid account stores accumulate inconsistent padding, reused PIN ranges, mixed lifecycle states, and support-created exceptions. These collide during normalisation unless every variation is mapped to a single agreed format.
Business logic in scripts, not config
Real product behaviour often lives inside IVR scripts and rating code rather than visible configuration. That logic has to be surfaced and re-expressed deliberately, because it cannot be copied across as a simple data extract.
CDR history and audit retention
Call detail records and account events carry billing, dispute, and audit obligations. Retention requirements decide how much history must move, in what format, and how it stays queryable for finance and support after cutover.
Carrier integration and access numbers
Cutover depends on carrier and softswitch integration and on who owns the access numbers. Rerouting cannot proceed faster than the carrier-side dependencies and number ownership allow.
What 'done' should mean
A migration is not finished when the data loads without an error. It is finished when the new platform holds a cleaner, more operable product than the one it replaced. A like-for-like copy simply reproduces the old problems on newer infrastructure.
Done means normalised data, with identifiers, balances, dates, rates, zones, and lifecycle states all following agreed formats. It means deterministic transforms, so every dry run and the final cutover produce the same result from the same input. And it means verified parity: counts reconcile, balances match, rating output is checked against the source, and accepted differences are documented rather than discovered later.
That distinction matters most for rate tables and balances, where a small inconsistency carried forward becomes a billing dispute once live traffic is running.
If a dry run keeps surfacing new hidden rules, the migration is not ready for cutover. The point of rehearsal is to make the final run predictable.
How Seshnova approaches it
Seshnova treats a migration as an operational control process rather than a one-off data load. The work is rehearsed through repeatable dry runs until the final cutover is a controlled execution of steps that have already been proven, with clear reconciliation and rollback criteria at each stage.
In practice that means hands-on migration of rate tables, accounts, balances, and integrations onto a platform built for prepaid voice: real-time per-second rating, A to Z rate decks, balance and PIN control, hard cut-off enforcement, CDRs, multi-brand and reseller support, fraud caps, and API and softswitch integration. The migration tooling normalises the data on the way in, so the new product is easier to operate from the first day it carries traffic.
The goal is not a prettier copy of the old system. It is a product that is safer to support, easier to audit, and no longer dependent on memory and manual interpretation.
Rehearse until cutover is boring
Treating migration as a control process — not a single heroic data load — is what keeps the detail above from turning into a cutover-night firefight. Each dry run should make the next one cleaner, until the final run is a controlled execution of work that has already been proven.
1. Discover the product
Build a complete product inventory before touching data. A prepaid voice product is a bundle of access numbers, accounts, PIN rules, rating logic, IVR behaviour, charging rules, reports, and operator processes — not just an account file and a balance file.
2. Map source behaviour to the new platform
Record each legacy feature against the capability it maps to: directly supported, supported by configuration, supported by a transform, custom, or deliberately deferred. This is where hidden logic in scripts and stored procedures gets surfaced.
3. Dry-run extract and transform
Take full extracts, hash the files, transform them into the target schema, and make the same automation reusable for every later rehearsal and the final cutover. No last-minute edits on the night.
4. Load, reconcile, and find anomalies
Load into a dry-run environment, compare counts and balances, test rates and zones, identify dirty records, and separate true defects from accepted product differences.
5. Wash data at source
Use the migration to normalise years of inconsistent formats, duplicate conventions, and operational shortcuts. Correct data upstream where possible, then encode the remaining rules in transforms so every extract stays repeatable.
6. Cut over under control
Block access numbers, take the final balance extract, run the proven transforms, load the new platform, reroute access numbers, smoke test, go live, and run an intensive-care window before calling it done.
Planning a move off a legacy platform
If you are evaluating a replacement for an ageing prepaid voice system, the safest first step is to map the detail before committing to a cutover date. Seshnova can help you scope the rate tables, account data, IVR logic, CDR history, and integration work involved.