Moving Product Variants with CSV from NCR Retail Online

When an NCR Retail Online store is moved to another ecommerce platform, product variants require careful handling. A single parent product may contain several sizes, colors, materials, or configurations, each with its own SKU, price, barcode, stock quantity, and image. A CSV export can transfer much of this information efficiently, but only when the source data is structured for the requirements of the destination system.

NCR Retail Online has been discontinued, so merchants have had to move their catalogs to alternatives such as Magento or WooCommerce through NCR Counterpoint partners. The process is more than a simple file upload. It involves interpreting the original product model, translating fields, preserving inventory relationships, and validating how shoppers will see the finished catalog.

A well-managed migration also reduces operational disruption. The guidance in this headless commerce migration resource can help frame the wider platform decision, while a focused CSV workflow keeps variant data accurate during the transfer.

Map the variant data before export

Begin by identifying how NCR Retail Online represents a product family. Some systems store a parent item with separate child records, while others place option values in columns alongside the main SKU. Before exporting, document the relationship between the base product, each variant, and the inventory record connected to it.

For every product family, record the parent name, variant attributes, SKU, barcode, price, cost, quantity, weight, tax class, image references, and publication status. Also note whether stock is held at one location or across multiple retail locations. This inventory mapping prevents a common error: importing visually correct variants that are disconnected from the quantities managed by the retail system.

Pay close attention to products with combinations of options. A shirt may have color and size, creating a separate sellable SKU for every valid combination. A kitchen item may use finish, capacity, or pack size instead. Looking at a cook clothing example can help illustrate why descriptive attributes and individual stock records should remain distinct.

Build a clean CSV source

Export the catalog into a working file rather than editing the original export immediately. Keep an untouched backup, then create a separate migration copy where you can normalize values and add destination-specific columns. Preserve leading zeros in barcodes and SKUs by formatting those columns as text, since spreadsheet software may otherwise convert them into numbers.

Use consistent conventions throughout the file. Choose one spelling for values such as “Black,” “black,” and “BLACK,” and remove accidental spaces from SKU, option, and category fields. Standardize measurement units, currency formatting, tax labels, and availability values. Blank fields should have a defined meaning: an empty weight may indicate missing data, while an empty second image column may be perfectly acceptable.

A variant CSV commonly needs a parent identifier and a unique child identifier. The parent identifier connects variants to the product page, while the child SKU connects each option combination to inventory and order records. Never reuse a SKU for two different combinations, even if the products have similar names. If the destination platform requires globally unique handles or slugs, create those separately from the customer-facing product title.

Match fields to the destination platform

Magento, WooCommerce, and other platforms do not interpret product variations in exactly the same way. One may expect configurable products with simple child products; another may expect a variable product with variation rows. Before importing, obtain the destination platform’s current sample CSV or import specification and compare it with the NCR export.

A practical field map can clarify the transformation:

Some fields will not transfer cleanly through CSV. Product descriptions containing HTML, image galleries, custom merchandising rules, related products, bundles, and search metadata may need separate treatment. CSV should be treated as the main structured data channel, not as a complete backup of every storefront feature.

If the destination import tool cannot create parent and child records in one pass, use a staged process. Import attributes first, create parent products second, and load variations after the parent records exist. This sequence gives each child row a valid relationship and makes error reports easier to interpret.

Import in controlled batches

Avoid uploading the entire catalog on the first attempt. Start with a small representative batch containing simple products, products with two attributes, products with multiple images, inactive items, and products with unusual prices or stock rules. This test should reveal whether the importer recognizes option values, creates the correct SKU structure, and assigns stock as expected.

Review the import log after every batch. Separate rejected rows from warnings because a warning about a missing optional image is different from a failure to create a variation. Correct the source file, rather than repeatedly editing records in the storefront, so the migration remains reproducible.

Use a staging site whenever possible. Disable customer access and prevent test orders from entering live fulfillment systems. If stock synchronizes with a point-of-sale or retail management system, confirm which platform is authoritative during the migration window. Two systems writing quantities at the same time can create overselling or unexpected stock reductions.

Validate catalog behavior after migration

A successful import is measured by storefront behavior, not merely by the number of accepted rows. Open each test product and select every available combination. Confirm that the displayed SKU, price, image, weight, and stock status change correctly when a shopper chooses a different option.

Test invalid combinations as well. If a red, large product does not exist, the storefront should not present it as purchasable. Check whether unavailable variants are hidden, disabled, or shown with an accurate back-order message. Review mobile layouts too, because long option names and multiple selectors can create usability problems on smaller screens.

Run sample orders for several variants and follow them through payment, inventory deduction, receipt generation, and fulfillment. Compare the resulting order lines with the records in the retail or warehouse system. This is where mismatched SKUs, incorrect decimal formatting, and location-specific inventory rules usually become visible.

Images deserve a separate review. A CSV may contain a valid filename while the destination expects a public URL, or it may attach the parent image to every variation. Confirm that image paths work, file names are unique, and product media does not expose private storage locations.

Preserve availability and customer signals

Product availability information can be lost during a platform change even when the catalog itself looks accurate. Backorders, preorder labels, low-stock messages, and discontinued statuses should be translated into the destination platform’s supported fields. Review back-in-stock handling so existing customer expectations and notification workflows are accounted for before the old store is retired.

Redirects are equally important. If variant pages or parent product URLs change, map old addresses to their closest new equivalents. Preserve high-value product pages where possible, and update feeds, marketplace listings, advertising links, and saved internal references. A clean redirect plan protects search visibility and prevents shoppers from reaching obsolete pages.

Security should remain part of the transfer process. Store exports in controlled locations, limit access to files containing cost or supplier information, and delete temporary copies when the migration is complete. Do not place payment credentials, customer passwords, or unnecessary personal data in a product CSV.

Practical controls for a safer transfer

A repeatable checklist makes the work easier to audit and reduces dependence on one person’s spreadsheet knowledge. Assign an owner for source data, an owner for destination configuration, and an owner for final business approval. Keep versioned files so every change can be traced back to a decision or correction.

Use these controls during the migration:

• Preserve the original export and create dated working copies.
• Compare parent-product and variant counts before and after each import.
• Validate unique SKUs, barcodes, option combinations, and image references.
• Test inventory synchronization across every active retail location.
• Record rejected rows, corrections, and final approval in a migration log.

After launch, monitor orders, stock adjustments, search results, and customer service tickets for at least one complete selling cycle. Early monitoring often catches issues that a staging test misses, such as a marketplace feed rejecting a variation or a point-of-sale integration treating child SKUs as separate products.

A CSV export can provide a dependable bridge from NCR Retail Online to a replacement ecommerce system when the data model is understood and tested. Prepare the variant relationships first, translate fields deliberately, import in small batches, and validate the complete shopping and fulfillment path. Start with a controlled sample and move the approved catalog into production only after every variant behaves as expected.