Industry Insights
Gift Card Platform Migration Without Disruption: Balances, Data and Continuity
Can gift card platforms migrate without disruption? Yes — mapped data extraction and loading moves balances and inventory intact, while API interfaces preserve checkout continuity when conversion isn't required.
A gift and loyalty programme can change platforms without customers noticing — but only when balances, card inventory and data formats are mapped before anything moves.
Migration Is a Mapping Exercise First
Ogloba has built turnkey routes for retailers moving existing gift and loyalty programmes, active card balances and card inventory across from an incumbent platform. The work begins by mapping old-system data to the Ogloba schema, which produces the design for extraction and loading — relating legacy formats to the requirements of the new system. A programmatic migration may run through many phases, but minimally it reads from the old system and writes into the new. The practical constraint is rarely technical. Continuity depends on cooperation from the former vendor, or on the retailer's own IT team being able to extract the data.
When Conversion Is Not the Answer
Not every programme needs converting. Where local regulation requires a third-party processor to remain in place, the change is one of interfaces, not data. A mobile gift card programme delivered to a large Chinese retail chain in 2013 worked this way: a dedicated API connected the Wincor checkout system to Ogloba, while a China Union Pay web service handled balance checks and transaction queries. At the till, the register passed the card PAN and cardholder's mobile number to Ogloba, which delivered the card to the phone — or sent an SMS app-store link if needed.
Migration risk is mostly a data-mapping problem. Solve it early and the customer never sees the switch.
FAQ
What has to be mapped before any balance is moved?
Every legacy data format is related to the Ogloba schema first. That mapping is what produces the extraction and loading design, covering active balances, card inventory and the programme rules attached to them.
What most often delays a platform migration?
Not the technology. The usual constraint is getting the data out of the incumbent system — either the former vendor cooperates, or the retailer's own IT team performs the extraction.
When is converting the data the wrong approach?
When local regulation requires a third-party processor to stay in place. The programme then changes interfaces rather than data, and the existing processor keeps running underneath.
How does a checkout stay unchanged while the platform behind it changes?
Through a dedicated API between the register and the platform. In one Chinese retail deployment the till passed the card PAN and the cardholder's mobile number to Ogloba, which delivered the card to the phone without altering the checkout flow.
