Migrating NCR recurring orders to third-party plugins

NCR Retail Online has been discontinued, leaving retailers to move subscription or recurring order data into platforms such as Magento or WooCommerce through NCR Counterpoint partners. The recurring agreement is often the hardest asset to transfer because its schedule, customer, product variants, payment token, delivery address, tax treatment and cancellation state must survive together.

A successful migration separates historical orders from active commitments. Order history can generally be imported as reference data, while an automatic replenishment programme or fixed subscription needs live billing, renewal and entitlement logic in the destination. Copying customers and products alone does not reproduce that behaviour.

Australian implementations must also handle A$ settlement, 10% GST and GST-inclusive storefront pricing. Operational support and reconciliation may span Sydney, Melbourne, Brisbane and Perth, so cutover reports should use one timestamp standard even when legacy records are stored in UTC.

A controlled migration treats extraction, mapping, validation and cutover as one connected chain. Raw records remain untouched in an encrypted archive, a redacted sample configures the destination plugin, and production imports begin only after totals, schedules and payment outcomes reconcile.

What the platform change means

The source data should be divided into historical orders, active subscription contracts, scheduled recurring-order templates, customer profiles, catalogue records and payment references. Each category has a different destination. An imported order can remain historical, while an active contract must regain its next billing date and lifecycle controls.

Confirm current transition notices on the former NCR platform and establish which responsibilities belong to the departing NCR provider, the receiving Counterpoint partner and the internal retailer. That prevents critical tasks such as gateway reconciliation or subscription cancellation handling from falling between organisations.

Inventory the data owner for every field before extraction. Payment tokens, tax codes and fulfilment rules often have separate owners, and resolving those dependencies early is more reliable than repairing incomplete records after the new platform is live.

Preparing a clean data export

The first export should preserve the source identifiers and include customer references, contact details, product and variation IDs, prices, discounts, tax, shipping, currencies, schedule rules, start and end dates, order references and lifecycle statuses. Timestamps, currency codes and status names need explicit definitions because equivalent-looking fields may carry different meanings.

Keep the original export immutable and create a normalised working copy for mapping. Date values should use an unambiguous format, totals should be stored in minor units where appropriate, and Australian GST-inclusive or exclusive values should be labelled before they are compared with the destination ledger.

Realistic test fixtures help expose product mapping errors. A legacy category such as kitchen cookware accessories can supply sample SKUs, variants, inventory identifiers and shipping attributes without using live customer information. The same fixtures should include cancelled, paused, past-due and one-time orders.

Sensitive information requires a separate decision. Raw card numbers should never be included in a migration file. Use gateway tokens or customer references that the receiving payment provider can safely re-map, and document whether a failed token requires the customer to update payment details.

Selecting the destination plugin

WooCommerce Subscriptions suits recurring memberships, digital entitlements and many fixed-interval products. Magento recurring-product extensions support contract-style selling through a different catalogue and checkout model. Physical replenishment orders may need a scheduled-order plugin or a custom queue instead of a conventional subscription extension.

Compare plugins using actual operational cases rather than feature lists. Test proration, trials, coupons, failed renewals, skipped shipments, manual cancellation, refunds, address changes, tax rounding and multi-currency behaviour. Also confirm how each option represents fulfilment history and customer account access.

A destination choice should account for the wider estate, including gateways, ERP connections, shipping services, accounting software and customer-service workflows. During URL discovery, quarantine unrelated destinations such as an unrelated campaign landing page rather than redirecting retail traffic to a page with no verified retail purpose.

Mapping subscriptions and recurring orders

Customer mapping requires more than copying email addresses. Match customer IDs, billing and shipping addresses, consent records, account status and historic order references, while reviewing duplicates created by old store imports. An automatic merge can attach orders to the wrong household, so uncertain matches should remain exceptions until a person resolves them.

The recurrence mapping must preserve billing intervals, anchor dates, next delivery dates, trial periods, skipped cycles, cancellation rules and renewal status. Historical totals, discounts, shipping charges and GST should reconcile to the source ledger. For physical products, consider Australian Customs requirements, import GST, duties and biosecurity inspections when a recurring box ships from overseas.

Payment migration is usually a re-tokenisation exercise rather than a direct copy. The destination gateway must recognise each customer reference, while recurring billing mandates, instalment arrangements and refunds must continue to align with the original agreement. Privacy reviews should cover the Australian Privacy Principles, the Spam Act, PCI DSS controls and the retailer’s retention schedule.

Testing before cutover

Begin with a sandbox and a small, representative sample containing active agreements, cancelled subscriptions, one-off purchases, failed renewals and physical recurring shipments. Import it into a staging copy of the plugin, with transactional emails, live fulfilment, stock movement and payment capture disabled where possible.

Reconcile record counts, Australian dollar totals, GST amounts, payment attempts, next billing dates, customer links and inventory deductions. Run the same import twice to confirm that the process is idempotent and does not create duplicate orders, customers or schedules. Record rejected rows with a reason code rather than silently discarding them.

Search visibility must be protected during the transition. The guidance on retaining search rankings supports a deliberate review of redirects, product URLs, metadata and canonical tags. Schedule the final cutover during a low-risk trading window, with rollback data retained and coverage arranged for Australian support teams.

Comparing migration approaches

Three migration routes suit different combinations of catalogue complexity, transaction volume and recurring-order rules. The appropriate choice depends on how much source-system behaviour must be reproduced and how tightly the new platform must integrate with other systems.

A staged approach usually gives the clearest evidence. Migrate a sample first, validate the field mapping, test renewal behaviour in a sandbox and only then schedule the bulk load. Complex integrations should preserve a raw identifier on every destination record so later audits can trace it back to NCR.

Controlled handover and next step

Production readiness depends on both data integrity and operational ownership. The following checks should be completed before the legacy environment is made read-only and the new plugin begins processing renewals.

Data checks

• Every active schedule has a destination identifier and a verified next billing date.
• Australian dollar totals and GST reconcile to the approved source ledger.
• No migration file contains raw card data or unprotected gateway credentials.
• Duplicate customer profiles and unmatched SKUs appear in a resolved exception register.

Launch checks

• Plugin, gateway, shipping and accounting versions are recorded and tested together.
• Redirects, transactional emails, renewals and fulfilment run in a controlled sequence.
• Monitoring covers failed payments, subscription churn, stock changes and timezone boundaries.
• A named owner can trigger rollback and communicate status across Australian offices.

Redirect governance remains part of the migration, not a separate marketing task. A promotional URL such as casino spin the reels should be excluded from the approved redirect set unless ownership, consent and destination relevance have been documented.

The next concrete step is a read-only export of active recurring schedules, encrypted in transit and at rest, followed by a field-mapping review against the chosen plugin.