Preventing data loss when exporting from NCR Retail Online

Moving an online store to another platform is more than downloading a product spreadsheet. Export files can contain product details, customer records, orders, stock quantities, images, pricing rules, and settings that are difficult to recreate once the original system is no longer available. A small mapping error can produce missing variants, incorrect inventory, or broken links across the new storefront. Learn more about Barware.html.

NCR Retail Online has been discontinued, so former customers may need to transition to another ecommerce system, including Magento or WooCommerce through NCR Counterpoint partners. A careful export process helps preserve business history and gives the receiving platform reliable information to work with.

The safest approach combines complete backups, documented field mappings, staged imports, and human review. Treat every export as a controlled migration project rather than a one-time file transfer.

Why export risk deserves attention

Retail data is interconnected. A product may have several variants, each linked to a stock record, image, category, tax rule, and order history. If an export preserves the product name but loses the variant identifier, the replacement store may display the item correctly while tracking inventory incorrectly.

Data loss can also be less obvious than a missing file. Text encoding problems may change special characters, date formats can shift by region, and leading zeroes may disappear from SKUs or customer account numbers. Empty cells can be interpreted as zero, “false,” or “delete,” depending on the import tool.

Images and documents require special care. A spreadsheet may include image paths that point to the old platform rather than the actual files. Exporting the links without downloading the assets can leave a new website filled with broken product imagery. Keep the original media files and create a manifest that connects each file to its SKU or record ID.

Map the information before exporting

Begin with a data inventory. List every record type used by the business, including products, categories, variants, inventory locations, customers, orders, discounts, shipping settings, tax settings, media, and custom fields. Mark each item as essential, useful, legally restricted, or safe to omit.

Next, identify the system of record for each dataset. Inventory may be managed in a retail management system, while product descriptions may be maintained in the ecommerce platform. Exporting both without defining which version is authoritative can create conflicting values during the migration.

A field-mapping document should show the source field, its destination, its format, and any transformation required. For example, a source field called “Item Number” might become “SKU” in WooCommerce, while a category path may need to be converted into a hierarchical taxonomy for Magento.

Use stable identifiers wherever possible. Names and descriptions can change, but SKUs, order numbers, and internal IDs provide a dependable way to match records. Never rely solely on row position because sorting changes can make two files appear aligned when they are not.

Create a controlled export workflow

Take a full export before making changes, then preserve the original files in read-only storage. Make a second working copy for cleaning and conversion. This separation protects the untouched source if a transformation script, spreadsheet formula, or import attempt damages the data.

Record the export date, account or store scope, file names, row counts, filters, and software version where available. If the system supports incremental exports, retain both a full baseline and later change files. A dated archive makes it possible to determine which records were present at each stage.

Avoid editing large CSV files manually unless the changes are fully documented. Spreadsheet applications can silently alter dates, remove zeroes, and convert long identifiers into scientific notation. Use a controlled data tool or script for transformations, and keep a log of every alteration.

When possible, calculate a checksum for each original file and media archive. A checksum does not prove that the content is correct, but it confirms that the stored file has not changed. Keep the checksum list with the migration records.

Validate files before importing

Validation should happen at three levels: structure, content, and business behavior. Structural checks confirm that required columns exist, delimiters are consistent, character encoding is correct, and row counts match the export report. Content checks look for blank SKUs, duplicate identifiers, invalid prices, missing tax codes, and unexpected characters.

Use a sample-based review alongside automated checks. Select products with variants, products without images, items with long descriptions, discontinued items, and products containing unusual punctuation. Review customers with different address formats and orders containing discounts, refunds, shipping charges, or multiple line items.

A staging store is essential when moving data to Magento, WooCommerce, or another replacement platform. Import a small batch first, inspect the result, then test a larger subset. This exposes mapping errors without contaminating the live catalog.

Verify relationships after import. A product should retain its category, variant options, images, inventory information, and searchable URL where appropriate. An order should retain its customer association, line items, quantities, discounts, taxes, shipping details, payment status, and total. Recalculate selected records independently rather than trusting a successful import message.

Protect sensitive and operational data

Customer exports contain personal information and should be handled with strict access controls. Limit the people who can download, clean, or import the files. Use encrypted storage and secure transfer methods, and avoid sending unprotected customer data through ordinary email or shared public folders.

Create a retention and deletion schedule before the migration. Keep only the information needed for operations, legal obligations, accounting, or customer service. If a field is not required by the destination platform, do not automatically carry it forward. Document the reason for retaining sensitive data and remove temporary working copies when the process is complete.

Catalog data also needs a visual review. For example, if the store sells dining products, compare exported category assignments with the existing dining and entertaining collection structure. A category can look complete in a CSV while products are actually assigned to the wrong parent or left without navigation placement.

Operational continuity matters as much as file security. Save a final inventory snapshot close to the cutover, pause changes during the final synchronization where practical, and record orders or stock adjustments made during the transition window. This prevents a valid export from becoming outdated before the new store opens.

Prepare for the platform transition

A migration to Magento or WooCommerce is an opportunity to separate transferable data from platform-specific settings. Product records, customer information, order history, and media may move in recognizable forms, but checkout rules, extensions, URL structures, payment integrations, and promotional logic often need to be rebuilt.

Work with an NCR Counterpoint partner or another qualified migration specialist when the store depends on retail inventory, point-of-sale synchronization, or multiple locations. Ask the implementation team how it will handle historical orders, stock reconciliation, customer passwords, images, redirects, and custom fields before approving the import.

Password data generally cannot be copied directly between unrelated systems because authentication methods differ. Plan for a secure customer account reset process instead of attempting to transfer credentials. Likewise, payment card data should not be exported into ordinary migration files; payment providers should manage tokenized or vaulted payment information through approved procedures.

Keep the discontinued platform’s export archive separate from the live destination system. The archive serves as an audit reference and recovery resource, while the replacement platform becomes the operational source after cutover. Label both clearly to prevent staff from updating an obsolete file.

Use a repeatable export checklist

A written checklist reduces dependence on memory and makes responsibilities clear. Assign an owner to each step, record completion dates, and require sign-off for customer data, inventory, and final reconciliation.

• Create an untouched full export and a separate working copy.
• Confirm row counts, identifiers, file formats, encoding, and media coverage.
• Document source-to-destination field mappings and transformation rules.
• Run a staged import, then compare products, inventory, customers, and orders.
• Secure the archive, remove unnecessary temporary files, and document the cutover snapshot.

After launch, monitor stock levels, order totals, customer account activity, search results, images, and category navigation. Compare the new system with the preserved export during the first reconciliation cycle. Keep a defect log so corrections are traceable rather than being made directly without documentation.

Start by securing the final NCR Retail Online export, cataloging every dataset, and testing a small import in the chosen replacement platform. A disciplined archive and validation process will protect business records, reduce disruption, and give the new ecommerce store a dependable foundation.