A pre-migration checklist for prepaid voice operators
Most migration pain is decided before a platform is ever chosen. The work that protects a cutover is discovery: knowing your access numbers, PIN inventory, rate decks, IVR behaviour, and audit duties before you commit to a new prepaid billing system.
When operators plan a move, attention usually jumps straight to the platform shortlist. That order is backwards. The hardest parts of a prepaid voice migration are set by the product you already run, not by the system you are moving to.
If discovery happens after a platform is chosen, every gap becomes a renegotiation. If it happens first, the platform decision is made with eyes open, the timeline is realistic, and the transforms are designed once and reused. The checklist below is the discovery to run before any contract is signed.
What to inventory first
Build a structured record of the product before reading a single vendor brochure. Each item below is something a new platform must either reproduce, standardise, or deliberately retire.
Access numbers and routing
Every access and DID number, who owns the routing, which carriers terminate it, and any carrier-side dependency that affects when a number can move.
PIN and account formats
PIN length and format, account identifier conventions, padding rules, reused ranges, authentication rules, saved-PIN behaviour, and CLI recognition.
Account lifecycle
Lifecycle states, expiry rules, inactivity behaviour, maintenance and dormancy charges, and how each state changes what a customer can do.
Ratesheets and zones
Rate decks, zone definitions, destination prefixes, rounding rules, minimum charges, connection fees, and time-of-day or day-of-week windows.
IVR structure
Menu structure, supported languages, prompts and recordings, balance playback, special menu functions, and any support or self-care flows.
Operational data
Current balances, active sessions, recharge history, CDRs, manual adjustments, and the audit obligations that govern how long each record must survive.
Questions that change the timeline
Some answers move the cutover date by weeks. These are the questions worth resolving early, because the platform cannot fix a dependency you discovered too late.
Carrier-side cutover dependencies
Which numbers depend on a carrier to reroute, how long each change takes, and whether those windows can be scheduled together. Carrier lead times often set the real cutover date, not the platform.
Where the business logic lives
How much charging and product behaviour sits in visible configuration versus IVR scripts, rating code, stored procedures, or support tools. Hidden logic is the most common cause of late surprises.
CDR retention and audit duties
How long CDRs, adjustments, and recharge records must be retained, in what format, and for which regulator or reconciliation process. This decides how much history has to migrate and how it must be proven.
Concurrency and peak volumes
Typical and peak-hour concurrent sessions, busy-hour call attempts, and recharge spikes. These numbers shape capacity planning and the fraud caps that protect balances at cutover.
Reseller and dealer hierarchies
How resellers, dealers, and sub-brands are structured, how balances and commissions flow between them, and which of those relationships must be reproduced on day one.
Running a zero-downtime cutover
Discovery exists to make the cutover boring. The goal on the night is simple to state and hard to achieve: no dropped calls, no lost balances, and no double-charging while live traffic moves. Zero downtime does not mean zero risk — it means the risk has been moved out of the cutover hour and into the weeks of rehearsal before it.
Parallel run and phased number migration
Keep the legacy platform live and move access numbers in controlled batches. A small first batch proves routing, IVR, and PIN authentication end to end before the rest follow.
Traffic shadowing
Replay or mirror a slice of live calls into the new platform without affecting the customer, then compare real-time rating and CDR output against the legacy platform under genuine load.
Freeze-and-reconcile window
Block recharges and freeze balances for a short window, take the final extract, apply the proven transforms, and reconcile loaded totals against the source before reopening the product.
Gates that must pass before go-live
A cutover should never proceed on optimism. Each gate is a measurable pass-or-fail against thresholds agreed in advance, with a single named owner holding the go, no-go, or rollback decision. Predefine what triggers a rollback, and keep the legacy platform reachable so a rollback means rerouting numbers back, not rebuilding a service under pressure.
- Account count and total balance reconcile within the agreed threshold after transforms and rounding rules.
- Sample test calls succeed across local, international, and premium-rate destinations.
- IVR menus respond and PIN authentication works, including saved-PIN and CLI behaviour where used.
- The CDR pipeline is confirmed flowing, with rated records arriving and hard cut-off enforcement applying.
A rollback that has been rehearsed is an operational decision. A rollback that has not been rehearsed is an incident. Treat the reverse path with the same care as the forward one, and keep the first hours after go-live as an intensive-care window before calling the migration done.
Why do this before you choose
Running discovery first turns a stressful migration into a planned one. When the inventory is complete, transforms can be written once and reused across every dry run and the final cutover, so the same rules that cleaned the rehearsal data also produce the live data.
It also produces a realistic timeline. Carrier lead times, CDR retention duties, and hidden IVR logic are known up front instead of surfacing on cutover night. Capacity and fraud caps can be sized against real concurrency and peak-hour figures rather than guesses, and reseller hierarchies can be reproduced deliberately.
Most of all, it lets you treat migration as a control process rather than a single high-risk event. With per-second rating, A to Z rate decks, balance and PIN control, hard cut-off enforcement, and multi-brand support already mapped against your inventory, the platform choice becomes a question of fit, and the cutover becomes the execution of work that has already been proven.