Migrating NCR’s supplier and vendor records to Counterpoint or ERP

NCR Retail Online connected online catalogues with retail inventory and business-management systems, but its discontinuation has left retailers with a practical data problem: supplier and vendor details may still sit in old tables, exports and staff spreadsheets. Moving those records into Counterpoint, an ERP or a supported commerce stack requires more than reloading product rows. Each relationship, SKU, purchasing rule and contact must be mapped to a system that will own procurement after cutover.

A reliable migration preserves useful history without carrying legacy errors into daily operations. Teams must establish which source is authoritative, remove duplicates and test how prices, stock and purchase orders behave before the old platform is retired. Local trading conditions sharpen those priorities: retailers in Sydney and Melbourne commonly combine online orders with click-and-collect and fast courier despatch, while Australian Business Number (ABN), GST and Australian privacy requirements add details that generic migration templates can miss.

Decide what needs to move

Start with the operating boundary rather than the file size. Counterpoint may be the destination for store inventory, purchasing and supplier records; an ERP may own broader workflows such as accounts payable, finance and procurement. Some retailers will run one of these as the system of record and connect Magento, WooCommerce or another storefront through an integration layer. The target choice determines how much history and which fields must survive.

Treat legacy identifiers as part of the migration, not disposable metadata. Purchase-order history, supplier references printed on invoices and staff knowledge of price breaks can be needed during reconciliation. Keep the original supplier code beside the new one, record the source system and migration date, and avoid rebuilding the entire catalogue when only a subset of active SKUs needs to trade immediately.

Because NCR Retail Online is no longer available as the long-term operating layer, agreements with implementation providers and NCR Counterpoint partners should state who owns exceptions, data corrections and vendor onboarding. That avoids a common failure mode in which migrated records look complete while new purchases, returns and invoice queries still depend on people who remember the old process.

Audit and clean supplier and vendor data

An audit should separate supplier identity from commercial and catalogue data. A supplier can sell several brands, use several trading names and supply several pack sizes, while one vendor record may be duplicated across legacy contacts. Give each legal entity a stable internal supplier ID. An ABN can support Australian identity checks, but it cannot replace that internal key because overseas suppliers will not have one.

• Identity: Legal name, trading names, ABN, GST registration status, supplier category and remittance address.
• Contacts: Buyer names, email, phone, preferred communication method and the relevant Australian or overseas time zone.
• Commercial terms: Currency, payment terms, price breaks, rebates, contract dates and accounts-payable details.
• Catalogue links: Vendor SKU, manufacturer, barcode, unit of measure, pack size, minimum order quantity, lead time and last confirmed cost.

Match those fields to source evidence rather than trusting an old export. Compare supplier names against invoices and remittance details, test ABN validity where applicable, and have purchasing or finance owners approve duplicates. Currency, tax treatment and freight assumptions often differ between records created by buying, receiving and accounting teams.

Keep inactive suppliers separate from active catalogue records. Archiving them protects audit history without cluttering reorder suggestions, but do not delete data that is still needed to explain old stock, credit notes or warranty claims. Record who requested each merge, which identifiers changed and how the old record maps to the surviving supplier.

Design target mappings for Counterpoint and ERP

Design the destination model before transforming the data. Counterpoint supplier records and ERP purchase-vendor masters may use different fields, hierarchies and approval rules; store catalogue records can add another layer. Map source values to a defined target rather than copying labels verbatim. This includes supplier status, currency, tax codes, units, lead-time conventions and the treatment of a product supplied under more than one vendor.

Identifiers need special care. Preserve legacy IDs in a cross-reference, decide whether product and supplier keys will remain stable, and document rules for products with no current vendor, several vendors or a discontinued vendor. Where a destination cannot represent the original relationship, capture it in a controlled extension or associated table rather than forcing it into a misleading field.

For retailers moving to Magento alongside Counterpoint, the Magento migration pitfalls article highlights why catalogue assumptions and extension data deserve early testing. The same discipline applies to WooCommerce: the storefront may present a simple product, but purchasing, tax, stock and supplier decisions still need a reliable source behind it.

Move products, stock and purchasing rules

Product migration should preserve the relationship between an item and the people who supply it. A vendor SKU, case quantity, minimum order, agreed cost and lead time can determine whether stock replenishes correctly. A product carrying only a retail price and a stock number may look migrated but will fail when a buyer creates a purchase order or accounts payable performs a three-way match.

Decide how stock is synchronised before bulk updates begin. Count physical inventory, clear or quarantine obsolete locations, and establish which system owns available-to-sell quantity, reserved stock and incoming purchase orders. For supplier-direct dispatch, the dropshipping workflow guide explains how order routing can be separated from local stock ownership; supplier confirmations, dispatch dates and cancellations then need a clear status model.

Price data also needs versioning. Wholesale prices may include rebates, freight or currency conversion, while retail prices depend on mark-up rules and promotions. Load effective dates, preserve the cost used for recent transactions and show users which value is current. This prevents a historic cost from silently changing margin reports during the first trading cycle.

Rebuild integrations and fulfilment workflows

Rebuild integrations after the core mappings are approved. Purchase orders should create the right supplier and items, receipts should update stock, invoices should reach accounts payable, and exceptions should return to a person with enough context to act. Storefront orders must carry supplier, fulfilment location and tax information needed after the NCR layer is gone. An integration that works for standard products but loses pack sizes or rebates will still create operational rework.

Specialist migration support can reduce the load on internal teams, and QLOUD Press is one source of implementation and ecommerce guidance to examine. The important control is not who clicks the import button; it is who signs off the mapping, tests exceptions, monitors the first live orders and can trace an incorrect change back to its source.

Run a small, representative test rather than a full production replay. Include high-value stock, multi-pack items, vendors with different currencies, products with multiple barcodes, returns and a slow-moving SKU. Compare purchase orders, stock adjustments and invoice lines in the new system with expected results, then record defects by severity. Fixing a field rule during the pilot is safer than compensating manually after launch.

Control go-live, compliance and continuity

Use a staged cutover with reconciliation checkpoints and a rollback path. Start with a controlled vendor cohort, watch order flow and stock movements through at least one replenishment cycle, then expand. Keep the legacy export read-only until finance, buying and store operations agree that balances and supplier terms match.

• Sample purchase orders match supplier, SKU, pack size, price, tax and delivery details.
• Stock-on-hand, reserved and incoming quantities reconcile across store, warehouse and ecommerce channels.
• New vendor invoices match purchase orders and receipts, with exceptions assigned and traceable.
• Storefront orders, cancellations, returns and fulfilment updates retain the correct supplier context.

Automation should follow a stable transaction model. The automated fulfilment guidance covers order-handling patterns after leaving NCR Retail Online, including how status changes can keep teams and customers informed. Introduce alerts for failed supplier confirmations, ageing stock and mismatched costs rather than automating every exception without an owner.

Supplier files can contain names, emails, phones and bank information, so access, retention and disposal should follow the Privacy Act 1988 and Australian Privacy Principles. Consumer-facing policies, warranties and returns must continue to comply with the Australian Consumer Law, while contracts should define how supplier data may be processed and transferred. Legacy records no longer needed should be archived or deleted under the approved retention schedule, not left indefinitely in exports and inboxes.

The practical takeaway is a controlled ownership model: authoritative source records, documented mappings, reconciled quantities, tested exception paths and a reversible cutover protect trading continuity while supplier and vendor data settles into its new home.