Preserving Referral Data When Migrating From NCR Retail Online

When NCR Retail Online is discontinued, moving product records and customer accounts is only part of the work. A referral programme can contain years of commercial history: who referred whom, which purchases qualified, what rewards were issued, and whether a customer agreed to receive marketing communications. Losing those relationships during a platform change can create disputes, duplicate rewards and gaps in customer service.

Australian retailers moving to Magento, WooCommerce or another platform through an NCR Counterpoint partner should treat referral information as a separate migration stream. A careful process preserves the original evidence, translates it into a usable structure and protects personal information while the new ecommerce system is being configured.

Identify Every Referral Record

Start by locating all sources that may contain referral activity. The NCR database may hold customer IDs, order references, account balances and registration dates, while referral codes could appear in ecommerce exports, spreadsheets, email tools, loyalty software or payment notes. Staff may also have manually recorded exceptions, such as a reward approved after a returned item or an offline purchase made in a Brisbane store.

Create a source register before exporting anything. For each file or system, record its owner, date range, file format, fields included and last update. Separate active programme data from historical records, test accounts and cancelled campaigns. This makes it easier to decide what must be imported into the replacement store and what should remain in a secure archive.

Referral data usually includes several linked entities:

• Referrer and referred customer IDs
• Referral code, campaign code or invitation URL
• Date of invitation, registration and qualifying purchase
• Order number, product value, discount and reward amount
• Reward status, including pending, approved, paid, reversed or expired
• Return, refund, fraud-review and chargeback indicators
• Consent records and communication preferences

Do not rely on customer names or email addresses as the only connection between records. A customer may have changed their email address, used a second account or shared a household address. Stable legacy IDs and original order numbers provide a much stronger audit trail.

Build A Reliable Data Map

Before importing into Magento, WooCommerce or a connected referral extension, map every NCR field to its destination. Keep a copy of the original field name and value alongside the transformed value. For example, a legacy status such as “completed” may need to become “reward approved,” while “void” could map to “reversed.” Document these decisions so staff can explain the result months after launch.

Use a referral ledger rather than a simple customer import. Each referral event should remain traceable from the original invitation to the qualifying transaction and final reward. A practical ledger might include a legacy referral ID, referrer ID, advocate ID, order ID, event date, gross and net order values, reward rule, currency, status and migration note. Australian retailers should retain the original AUD values and clearly identify whether the programme calculated rewards before or after GST and shipping.

Deduplication deserves special attention. Compare legacy customer IDs, normalised email addresses, phone numbers and order references, but do not automatically merge records when the evidence is uncertain. Flag possible duplicates for review. A mistaken merge could assign a reward to the wrong person, while an unmerged duplicate could allow one customer to claim a promotion twice.

Run a test conversion with a representative sample: successful referrals, rejected referrals, refunds, partial returns, expired codes and customers with several referrals. Have the business owner compare source totals with imported totals. The test should confirm that every reward has a clear status and that no referral relationship disappears when customer accounts are created in the new platform.

Protect Consent And Customer Privacy

Referral records often contain personal information about both the person making the recommendation and the person being invited. Under Australia’s privacy framework, the business should understand why each field was collected, how it will be used after migration and whether it is still necessary. Avoid importing unused notes, internal comments or sensitive details simply because they appear in an old export.

Consent and marketing permission should be migrated as separate fields, with the date, source and wording of the original permission where available. A referral invitation does not automatically establish permission for every future marketing channel. Keep transactional messages, reward notifications and promotional communications distinct, particularly where email or SMS campaigns are involved.

Restrict access to raw exports during the migration. Use encrypted storage, individual administrator accounts and a defined deletion schedule for temporary files. A CSV sent through personal email or saved to an unprotected laptop can create a greater risk than the platform transition itself. Keep a read-only archive of the original data, with access limited to authorised personnel and a record of any changes.

Australian businesses should also check whether overseas hosting, analytics tools or referral applications change their privacy obligations. A retailer operating in Sydney, Perth or regional Queensland may serve customers across the country, yet the same online system can send data to vendors in other jurisdictions. Confirm the new provider’s security controls, retention practices and breach response arrangements before transferring personal information.

Preserve Reward And Financial History

A referral programme is connected to money, so historical rewards need more than a customer profile field. Reconcile the total value of issued, pending, cancelled and expired rewards against finance records. Include gift cards, store credit, discount vouchers, cash payments and manual adjustments in separate categories. This prevents an old liability from being treated as a new promotional expense.

For rewards that remain payable at the migration date, preserve the original qualification evidence. Store the order number, payment state, refund state and approval history so the new team can decide whether a reward should be released. A returned order should not become payable merely because its referral record was imported without the associated fulfilment status.

Where approval was previously handled through email or spreadsheets, the transition is a useful time to formalise the process. Referral bonuses, goodwill credits and staff-authorised exceptions can be routed through documented expense approval workflows, giving finance a consistent record of who approved each payment and why.

Reconcile before and after launch using several totals: number of referrals, number of qualifying orders, value of rewards, number of pending cases and number of reversed cases. Investigate differences instead of forcing the figures to match. A small variance may reflect a late refund, time-zone conversion or an order imported twice, but it should be explained and recorded.

Coordinate The Cutover

Choose a clear freeze period for referral activity. During the final export, stop changes to referral rules and record any invitations, orders or reward approvals created after the extract. Those late events can be held in a controlled queue and entered after the new platform is live, rather than being lost between systems.

Assign ownership across the retailer, migration specialist, finance team and ecommerce administrator. One person should approve the data map, another should verify financial totals, and a technical owner should manage import permissions and backups. Partners supporting Counterpoint-connected businesses may also help determine which historical data can be carried into Magento or WooCommerce and which should stay in an archive.

The new store should be tested from the customer’s perspective. Confirm that a referred shopper receives the correct attribution, that an existing customer is not given a duplicate account, and that a refund changes reward eligibility as intended. Test Australian tax settings, AUD display, local delivery scenarios and time zones, especially when the business serves customers in Melbourne, Adelaide, Darwin and other locations with different operating patterns.

Staff training should cover the referral ledger, exception handling and privacy controls as well as ordinary order management. Teams moving to Magento can use guidance on training the Magento admin so they understand where imported customer information sits and which actions can change reward status. Keep a short runbook showing how to investigate a missing referral, reverse an incorrect reward and retrieve the original NCR evidence.

Review the migration after launch at set intervals, such as seven, thirty and ninety days. Compare new referral activity with the preserved baseline, inspect failed attribution and contact customers only when the business has a clear explanation. Keep the former NCR subscription and licence position documented as part of the transition record; guidance on existing NCR subscriptions can help teams identify which access, exports or contractual records need to be retained before closure.

A successful migration leaves more than a functioning storefront. It preserves the chain of evidence behind every referral, protects customer choices, reconciles financial obligations and gives staff a dependable way to resolve disputes. The essential record is the link between the original referral, the qualifying order and the final reward, supported by clear consent and an untouched historical archive.