Migrating NCR gift card balances to a modern plugin

NCR Retail Online connected ecommerce catalogues with in-store inventory and business management systems, allowing retailers to sell online while synchronising stock and automating key operations. Since the service has been discontinued, stores moving toward Magento or WooCommerce through NCR Counterpoint partners must decide what happens to balances customers have already paid for.

Migrating NCR’s gift card balances to a modern gift card plugin is primarily a data and liability exercise, not a cosmetic change to checkout. The migration must preserve every valid balance, expiry term, redemption history and audit trail while producing stored-value records that work online, over the phone and at the counter.

For Australian retailers, that means treating amounts in Australian dollars, reconciling gift-card liabilities with GST-aware ledgers, and complying with the Australian Consumer Law. Shoppers in Sydney and Melbourne commonly mix online buying with click-and-collect, so a balance must survive channel changes without depending on a particular till, browser or old NCR session.

Establish the retirement boundary

The legacy NCR Retail Online platform is no longer the destination for new integrations. Its archived material may still describe old catalogue, stock and customer processes, but retailers should treat it as a source of historical records rather than a live dependency. Confirm which NCR Counterpoint partner is accountable for the cutover and who will operate the replacement.

Define the population before exporting anything. It should include active and unredeemed cards, partial balances, promotional and employee cards, refunds, cancelled cards, expired balances awaiting write-off, and any cards denominated outside AUD. Record why each item remains outstanding, since dormant balances often carry a different liability and reporting requirement from current gift cards.

Decide whether the replacement platform assumes all outstanding liability immediately or whether NCR-era cards remain redeemable during a defined transition. The latter can reduce disruption, but it creates two systems that must be reconciled. Neither option permits valid balances to disappear merely because the originating software has been retired.

Build a reliable balance inventory

Extract the data from a read-only NCR snapshot and preserve the original files. An archived category page such as home decor products can expose legacy SKU naming conventions, which help identify gift-card products, but balances should come from transaction and liability records rather than catalogue descriptions. Record the extraction date, operator and source-system version for every file.

Normalise the records before loading them. Currency, case, whitespace, dates, status codes and card identifiers all need consistent meanings, while source values should remain available for audit. A dedicated transformation script should produce an exception report for malformed or ambiguous records instead of silently correcting them.

Use these controls for the preparation stage:

• Take a read-only snapshot before any cleanup and repeat it after each reconciliation.
• Store Australian dollar amounts as integer cents, with a separate field for the source currency.
• Create a stable migration identifier that links the plugin record to the NCR card number without changing its meaning.
• Preserve issue dates, expiry dates, status and redemption history so legacy terms can be honoured.
• Keep trackable card numbers, CVV data and plaintext PINs out of the plugin; assess PCI DSS scope with the acquirer if payment-card credentials are involved.
• Retain immutable source exports, transformation logs and approval records for finance and audit review.

Validate the result by status and by total value, not merely by row count. For consumer gift cards issued in Australia, ACCC guidance says an expiry period generally cannot be shorter than five years from issue, subject to limited exceptions. Preserve valid legacy expiry terms and configure newly issued plugin cards with compliant terms.

Choose a controlled migration route

Retailers generally have three practical migration routes:

The right route depends on balance volume, integration maturity and how much customer disruption the business can tolerate. A direct import gives the cleanest experience when the plugin can enforce legacy terms and the opening liability has been reconciled. A transitional bridge is safer for unusual records, while manual settlement should be limited to a documented residual population rather than used as the default.

For an automated route, transformations should be isolated in small, tested functions rather than embedded in an import script. The value of such a utility layer is illustrated in modern web development. Whichever route is selected, finance should reconcile the opening card count and dollar liability, every migrated transaction and the closing liability in the general ledger.

Test the customer journey

Test complete journeys, not isolated fields. A representative customer should be able to receive or buy a card, view its balance, redeem it online and in store, make a partial redemption, request an eligible refund and receive clear help when a balance is expired or disputed. Include click-and-collect orders in Sydney and Melbourne, phone-assisted sales and peak-period traffic, because these channels often expose integration gaps.

Run a controlled parallel period. Record each redemption against both the legacy and replacement records, but allow only one system to decrement the balance. Compare daily totals by channel and investigate differences before the next batch. Keep a tested rollback package containing the original export, import manifest, configuration and reconciliation results.

Prepare store and support teams before issuing replacement cards. Short demonstrations of issuance and redemption can be triaged with a smart video summaries workflow before full playback, while written scripts should cover expiry disputes, refunds, store transfers and the handling of cards that predate the migration. Customer communications should state which channels remain valid without implying that an existing balance has changed.

Retire the legacy platform

Only decommission the old service after the replacement balances, liabilities and customer communications have passed finance and operational sign-off. Revoke integration credentials, block unnecessary write access and retain a read-only archive for the period required by accounting, tax and contract rules. Under the Privacy Act 1988 and the Australian Privacy Principles, keep customer-linked records no longer than necessary and document any access, correction or deletion process.

Make the plugin the system of record and assign ongoing ownership. Schedule backups, dependency updates, API monitoring, monthly liability reconciliation and an annual review of gift-card terms. Long-unredeemed balances may also fall under state and territory unclaimed property rules, so obtain local legal advice before writing them off; the ageing of a balance does not automatically transfer its value to the business.

The first operational checkpoint should prove that no valid balance has been lost. Schedule a 60-minute balance-reconciliation workshop with the NCR administrator, the gift-card plugin vendor and the finance lead.