Definition. An electronic voucher management system (EVMS) is the software that controls the whole life of prepaid vouchers, from generation or intake through dealer allocation, sale, redemption into charging and reconciliation. MoboGage EVD System is an EVMS and electronic voucher distribution platform built for telecom operators and VAS partners.
TL;DR for migration owners
- A voucher platform migration is a ledger move, not a software install. Treat stock, PIN data and dealer balances like money, because they are.
- Map every legacy lifecycle state to a target state before you move a single serial range.
- Drain offline POS caches and resolve unknown-status top-ups before you snapshot dealer wallets.
- Run both platforms in parallel until reconciliation closes with zero unexplained variance, and write the rollback trigger down before cutover weekend.
Most operators do not wake up wanting a new voucher platform. They get there because the old one has become expensive to keep alive: a vendor that no longer ships fixes, or a reporting layer finance has quietly replaced with spreadsheets. By the time the replacement is signed, the commercial team wants the new dealer app live “next month”.
That is where migrations go wrong. The new electronic voucher management system is rarely the problem. The problem is what you carry into it: millions of PINs in a dozen states, a dealer hierarchy that drifted from the contracts years ago, and wallet balances that distributors will check to the last unit the morning after cutover.
This playbook is the sequence we would follow from the operator side of the table. It is written for prepaid product owners, channel managers, IT leads and the SI partner running delivery.
Why voucher platform migrations fail
They almost never fail on the user interface. They fail on three quiet things.
State drift. The legacy system calls a batch “active” when it means “printed and sitting in a warehouse”. The new platform reads “active” as sellable. Within a day, stock nobody has received is showing on dealer screens.
Balance disputes. A top-tier distributor’s wallet shows a different number on Monday than it did on Friday. Even if the difference is a single pending transaction, the trust damage lasts longer than the fix.
Orphaned channels. An API partner nobody remembered still points at the old endpoint, or a batch of rural POS terminals never picked up the new app. They keep selling against stock the old system no longer owns.
None of these need clever technology to prevent. They need a written inventory, a state map, a freeze window and reconciliation gates someone senior signs off.
Step 1: Inventory what actually has to move
Before anyone talks about cutover dates, list every object the old platform holds and decide what happens to it. Some things migrate, some get rebuilt cleanly in the new platform, and some are archived read-only for audit.
| Object | Migrate, rebuild or archive | What to verify | Typical owner |
|---|---|---|---|
| Product catalogue and denominations | Rebuild (cleaner) | Every live SKU has a target product with the same face value and charging profile | Prepaid product |
| Voucher batches and serial ranges | Migrate | Count by batch, by state and by serial range matches the legacy export | Voucher ops |
| Encrypted PIN data | Migrate under key ceremony | Record counts and checksums match; no clear-text exposure at any step | Security / IT |
| Dealer hierarchy and contracts | Migrate, then clean | Every dealer has one parent, one tier and a current contract | Channel sales |
| Wallet and float balances | Migrate at snapshot | Sum of balances per tier matches the signed snapshot | Finance |
| Credit limits and commission plans | Rebuild | Plans match signed commercial terms, not legacy configuration | Channel finance |
| Open disputes and pending transactions | Resolve before snapshot | Zero unknown-status transactions at freeze | Ops + finance |
| POS terminals and app versions | Re-enrol in waves | Each terminal is registered, on the target app and drained of offline stock | Field ops |
| API partner credentials | Reissue | Every partner tested in sandbox against the new endpoint | Partner management |
| Transaction history | Archive read-only | Retention period agreed with audit and regulators | Finance / compliance |
The rebuild column matters more than it looks. Legacy commission plans carry years of one-off exceptions. Rebuilding them from the signed agreements is slower for a week and saves a year of disputes.
Step 2: Map lifecycle states before moving stock
This is the step most teams skip, and the one that causes the worst first week. Every voucher platform has its own state vocabulary. Write them side by side and agree the rule for each.
| Legacy state (example wording) | What it usually means | Target state | Migration rule |
|---|---|---|---|
| Generated | PINs created, not yet sent to print or channel | Generated / inactive | Move as inactive; never sellable on arrival |
| Printed / in transit | File released to print house or courier | In custody (inactive) | Hold inactive until goods receipt is confirmed |
| Received | Physical stock in warehouse | Warehouse stock | Activate only on allocation |
| Allocated | Assigned to a distributor or dealer | Allocated to the same node | Verify the node exists in the new hierarchy first |
| Active / sellable | Can be sold and redeemed | Active | Cross-check against charging before cutover |
| Sold | Sold, not yet redeemed | Sold | Keep redeemable; preserve sale timestamp |
| Redeemed / used | Consumed in charging | Redeemed (archive) | Migrate for audit; block any re-use |
| Blocked / stolen / damaged | Withdrawn from sale | Blocked | Never reactivate during migration |
| Expired | Past validity | Expired | Migrate for reporting, or archive |
Ask your vendor two direct questions here. Does the target platform hold state per PIN or per serial range? And what happens to a range that is half sold? If the answer is vague, the migration plan is not ready.
Step 3: Move PIN data without ever seeing it
PIN files are the most sensitive thing in the programme. The rule is simple to say and hard to keep: no person and no intermediate system should see clear-text PINs during migration.
In practice: a key ceremony with dual control, PINs re-encrypted from legacy to target keys inside a hardware security module or equivalent protected environment, and record counts plus checksums compared on both sides. Transfer files are deleted on schedule and the deletion is logged.
If the vendor proposes exporting PINs to a spreadsheet “just for validation”, stop the call. We cover the wider custody model, including what encrypted-until-sale should mean, in our guide to voucher reconciliation and PIN security in an EVMS.
Step 4: Freeze, drain and snapshot dealer float
Dealer wallets are where migrations become personal. A distributor who sees a wrong balance on Monday will phone your commercial director, not your IT team.
A sequence that holds up:
- Announce the freeze window early. Dealers should know a week ahead when stock purchases and wallet transfers pause, and for how long.
- Drain offline POS caches. Handheld terminals that sell offline hold cached vouchers and unsynced sales. Push a sync, then block offline sales for the final 24 to 48 hours so nothing appears after the snapshot.
- Resolve unknown-status top-ups. Any PINless recharge sitting in a timeout or unknown state must be confirmed against charging and either completed or reversed before the snapshot. Our electronic top-up system guide explains why float, not stock, is the real inventory in eTopup.
- Snapshot and sign. Export balances per dealer and per tier, share them with the top distributors and get written acknowledgement before go-live.
- Load and re-verify. After load, the sum per tier in the new platform must equal the signed snapshot. Not roughly. Exactly.
If your hierarchy has more than two or three tiers, check that each sub-dealer lands under the right parent and inherits the right credit limit. The patterns in our piece on multi-tier reseller voucher distribution are a useful sanity check for that review.
Step 5: Cut over channels in waves
Do not switch every channel on the same night. A sensible order is usually:
- API partners first, in sandbox and then a controlled production window, because their traffic is easiest to watch and roll back.
- Dealer web portal next, starting with a small group of top-tier distributors who agreed to be early.
- POS fleet in regional waves, pushed through terminal management, with field teams ready in each region on the day.
- USSD and SMS last, because routing changes touch the network side and need their own change window.
Keep old endpoints answering with a clear “moved” response for a while. It is the cheapest way to find the partner nobody remembered.
Step 6: Parallel run and reconciliation gates
Run both platforms side by side long enough to close several full business days, including at least one weekend and one month-end if you can. Each gate has a pass condition and a rollback trigger agreed in advance.
| Gate | Pass condition | Rollback or hold trigger |
|---|---|---|
| Stock count | Counts by product, state and serial range match the legacy export | Any unexplained difference in sellable stock |
| Dealer balances | Sum per tier equals the signed snapshot | Any distributor balance dispute not resolved within the agreed window |
| Sales vs charging | Every sale has a matching redemption or a valid sold-not-redeemed record | Redemptions in charging with no sale record |
| Commissions | Sample of dealers recalculated by finance matches the platform | Systematic commission mismatch in any tier |
| Channel health | Every live channel transacting on the new platform | Any channel still hitting the old endpoint after the deadline |
| Day-close | Day-close pack produced and accepted by finance | Day-close cannot close without manual journals |
Write the rollback decision into the plan with a named owner and a deadline. A rollback decided at 4 a.m. by whoever is still awake is not a plan.
GCC and MEA notes
Timing matters as much as engineering in Gulf markets. Avoid the Ramadan and Eid peaks, when recharge volumes and dealer activity change sharply. Remember that weekends differ: the UAE moved to a Saturday–Sunday weekend in 2022, while Saudi Arabia, Qatar and Kuwait keep Friday–Saturday. A cutover planned on a European calendar can land on your busiest dealer day.
Bilingual dealer communication, data-residency language in the contract and SI partner responsibilities should all be settled before the freeze notice goes out. Our GCC operator guide to electronic voucher management covers those requirements in RFP terms.
Questions to ask any EVMS vendor about migration
- Show us a state-mapping template from a previous migration, with customer details removed.
- How do you re-encrypt PINs from our legacy keys, and who holds which key component?
- Can you run a parallel reconciliation report against our legacy exports, and in what format?
- How do you handle POS terminals that were offline during the freeze?
- What is the rollback path for each channel, and how long does it take?
- Which tasks sit with you, which with our SI, and which with us?
How MoboGage EVD System approaches a migration
We start with the state map and the dealer snapshot, not the screens. EVD System holds voucher inventory, the dealer hierarchy with wallets and credit limits, PIN and PINless sales across Android/Linux POS, apps, portals and APIs, and day-close reconciliation in one control plane. That makes it practical to run a parallel period against legacy exports and close each gate with evidence finance can read.
What we will not do is promise a date before seeing your data. The honest answer comes after a short discovery on a sample export.
FAQ
What is an electronic voucher management system?
An electronic voucher management system is software that controls prepaid vouchers end to end: generation or intake, inventory, allocation through the dealer hierarchy, sale, redemption into charging and reconciliation. MoboGage EVD System is one such platform for telecom operators and VAS partners.
How long does an EVMS migration take?
It depends on data quality, channel count and how many lifecycle states the legacy platform uses. Plan for discovery, a test migration on a data copy, a parallel run over several business days and phased channel cutover. Treat any date given before discovery as an estimate.
How do we move PIN data securely?
Use a key ceremony with dual control, re-encrypt PINs from legacy keys to target keys inside a protected environment such as an HSM, compare record counts and checksums, and log deletion of transfer files. Nobody should see clear-text PINs.
What happens to dealer wallet balances during cutover?
Freeze purchases and transfers, drain offline POS caches, resolve unknown-status top-ups, then snapshot balances per dealer and tier. Load that snapshot into the new platform and confirm the totals match exactly before reopening sales.
Should we cut over all channels at once?
No. Move API partners first, then the dealer portal, then the POS fleet in regional waves, and USSD or SMS last. Keep old endpoints returning a clear moved response so forgotten integrations surface quickly.
When should we roll back?
When a gate fails and cannot be fixed inside the agreed window: unexplained sellable-stock differences, unresolved distributor balance disputes, or redemptions with no sale record. Name the decision owner and the deadline before cutover.
Planning a voucher platform migration?
Replacing a legacy VMS or consolidating PIN and eTopup channels? Send us your current platform, channels and dealer tiers, and we will come back with a state-mapping outline and a realistic migration sequence.
Talk to MoboGage about your EVD System migration or email projects@mobogage.com.
Add a Comment