Moving NCR wishlist and saved cart items to a new storefront

When NCR Retail Online is discontinued, moving product data is only part of the work. Customer wishlists, saved carts, favourites and abandoned baskets can contain valuable buying signals that are easy to overlook during a storefront replacement. If those records disappear, shoppers may need to search for products again, while staff lose useful information about future purchases.

A careful migration should preserve the relationship between a customer, a saved item and the correct product in the new catalogue. That means mapping product identifiers, checking account records, reviewing stock status and deciding how to handle products that are no longer sold. The process applies whether the replacement storefront uses Magento, WooCommerce or another platform supported by an NCR Counterpoint partner.

Australian retailers also need to consider practical matters such as GST-inclusive pricing, Australian Consumer Law, delivery expectations in regional areas and the way shoppers use mobile devices during commutes. A saved cart transferred accurately can support a smoother return visit, but only if the new store presents current prices, availability and delivery information.

Identify what the old storefront actually stores

A wishlist is usually a list of product references attached to a customer account. A saved cart may contain quantities, selected variations, notes, promotional codes or a preferred delivery method. Some platforms also store anonymous carts in browser cookies or temporary sessions. These records should be inventoried before any export begins, because each type requires a different migration method.

Start by documenting the data fields available in NCR Retail Online. Useful fields may include customer email, internal customer ID, SKU, product name, variation code, quantity, date added and last activity date. Do not assume that the visible product name is a reliable identifier. A SKU or catalogue ID is safer because names can change during a redesign.

Inactive records need a defined treatment. A saved cart untouched for several years may contain discontinued stock, while a recent wishlist may reflect a product a customer still expects to buy. Set a retention period, record the decision and keep a secure archive where appropriate. This reduces clutter in the new storefront without silently discarding useful data.

Build a reliable product and SKU crosswalk

The most important migration file is a crosswalk connecting each old NCR product reference with its new storefront equivalent. It should include the old SKU, new SKU, parent product, variation attributes, brand, URL and migration status. Products with changed identifiers require manual review, especially where colour, size or pack quantity is represented differently.

Pay close attention to Australian catalogue conventions. A product listed as a “single” in one system may be sold as a two-pack in another, and footwear sizes can be displayed using different standards. A product that has moved from $99 to $109 should show the current GST-inclusive price, while a product unavailable for delivery to remote Western Australia may need a clear fulfilment status rather than a misleading add-to-cart button.

Run automated checks for missing SKUs, duplicate mappings and products whose category has changed. Then ask merchandising or store staff to review exceptions. Their knowledge can catch issues that a script cannot, such as a replacement appliance model that looks similar but uses different accessories.

Protect customer accounts and saved preferences

Wishlist migration involves personal information, so access controls and handling procedures matter. Customer emails, account IDs and shopping activity should be transferred through encrypted files or a secure integration rather than spreadsheets sent casually between teams. Access should be limited to people who need it for the migration, with logs retained for audit purposes.

The Australian Privacy Act and the Australian Privacy Principles are relevant when personal information is moved between systems or vendors. Review the privacy policy, supplier agreements and data-processing arrangements before exporting account-linked records. If the new platform is hosted overseas, document the relevant disclosure and security considerations.

Do not use wishlist data to send promotional messages unless the customer has the appropriate marketing permission. A saved item indicates interest, but it is not automatically consent to receive email or SMS campaigns. Customers should also have a straightforward way to remove saved products or close an account under the new system.

Decide how to treat discontinued and restricted products

No migration can guarantee that every saved item remains sellable. Products may have been discontinued, recalled, replaced by a newer model or removed because a supplier agreement ended. Create separate statuses such as active, replaced, unavailable, restricted and requires review rather than forcing every old item into a live product page.

For Australian shoppers, location can affect availability. Dangerous goods, oversized products and certain batteries may have delivery restrictions, while remote customers in the Northern Territory or far north Queensland may face different freight options. The new storefront should explain these limits without presenting an unavailable item as ready for purchase.

Replacement products should be handled transparently. A wishlist entry can point to the new model with a message such as “replacement product”, while an old saved cart may need to be reopened with its quantity reset. Never substitute an item silently when the price, specifications or warranty terms have materially changed.

Recreate the customer experience, not just the records

A technically successful import can still feel broken if customers cannot find their saved items. Test sign-in, password reset, wishlist display, saved-cart recovery, quantity changes and removal functions on desktop and mobile. Many Australian customers browse on phones during a train trip in Sydney, a lunch break in Melbourne or while comparing products at a physical shop.

Check how the new storefront behaves when a customer returns after several months. It should refresh price, stock and delivery estimates rather than showing stale information from the import date. A saved cart can be restored into the basket, but the customer should have a chance to review substitutions, shipping charges and applicable GST before payment.

Retailers with stores in Brisbane, Perth or Adelaide should also test location-aware features such as Click and Collect, store stock and pickup windows. If the old system stored a preferred store, confirm that the location still exists and that the new platform uses the correct postcode and trading hours.

Test redirects, content and connected operations

Storefront migration often changes product URLs, category paths and account routes. Create redirects for valuable product and gift pages, then test them from search results, email campaigns and saved links. Related merchandising content should be reviewed as well; for example, a gift-focused catalogue can retain useful seasonal context through pages such as gift ideas, provided the links and products still work.

Content migration should include more than descriptions. Check images, downloadable manuals, sizing information, reviews and internal search terms. If old editorial pages contain links to external buying guides or product education, verify that they remain relevant and safe; even a specialist scatter symbol guide should not be carried into a retail journey unless its surrounding context genuinely supports the intended audience.

After the import, test the operational chain from saved cart to order confirmation. Inventory reservation, payment, tax calculation, warehouse picking, dispatch and customer notifications must use the new product IDs. This is where many migrations fail: the customer sees a correct item, but the warehouse receives an obsolete code.

Launch in stages and monitor the first weeks

A staged release reduces the risk of losing customer data. Export and validate a sample first, import it into a test environment, and compare record counts and product matches. Invite internal users to recover old wishlists and carts across browsers and devices. Resolve failures before processing the full customer file.

Take a final snapshot immediately before cutover, because customers may add items while the migration is being prepared. Freeze changes for the agreed window or use an incremental export to capture activity after the first extract. Keep the legacy data protected and read-only until reconciliation is complete.

After launch, monitor wishlist recovery rates, cart errors, broken product mappings, search exits and support contacts. Fulfilment deserves special attention because automation settings may change with the platform; retailers can review guidance on order fulfilment automation while validating the new workflow. Provide support staff with scripts for missing items, expired prices and account access problems.

The key measure is not the number of records imported. It is whether customers can return to a familiar shopping intention and complete a purchase using accurate products, prices, stock and delivery details. Preserve the customer’s saved choices where they remain valid, explain every necessary change, and treat privacy and operational testing as part of the migration itself.