Skip to content
Ogloba
Back to blog

Industry Insights

Gift Card Platform Migration Without Disruption: Balances, Data and Continuity

Ogloba Team3 min read

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.

Illustration: Gift Card Platform Migration Without Disruption: Balances, Data and Continuity

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

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.

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 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.

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.

Watch the reel

Part of Gift Card Programs

Explore the business line
Talk to an expert