Data migration checklist for moving customer records from NCR Retail Online

Moving customer data from NCR Retail Online requires more than exporting a spreadsheet and importing it into a replacement store. Customer profiles often connect to orders, addresses, tax settings, loyalty details, marketing permissions, saved payment references, and support history. A clean migration preserves useful business context while avoiding duplicate, incomplete, or noncompliant records.

NCR Retail Online has been discontinued, so retailers transitioning to platforms such as Magento or WooCommerce need a controlled plan for extracting and transforming their information. The exact export options may depend on the former installation, connected NCR Counterpoint systems, and the partner supporting the replacement ecommerce site.

A practical checklist should cover discovery, data protection, field mapping, cleansing, test imports, customer communication, and post-launch verification. Treat the work as a business data project rather than a one-time technical transfer, because customer records influence order fulfillment, service quality, reporting, and consent management.

Define the customer data in scope

Begin by identifying every location where customer information may reside. The primary ecommerce database could include names, email addresses, telephone numbers, billing addresses, shipping addresses, account status, registration dates, password metadata, order totals, store credit, and marketing preferences. Related records may remain in NCR Counterpoint, a payment service, a loyalty system, an email platform, or a customer service application.

Separate essential customer attributes from historical or disposable data. A replacement store may need an active email address, contact name, shipping details, tax information, and order relationships. Old abandoned carts, malformed guest profiles, internal notes, and obsolete promotional fields may be better archived than imported.

Create a written scope document with three categories: migrate, archive, and exclude. Include the reason for each decision, the source system, the target destination, and the person responsible for approval. This prevents teams from discovering late in the project that a seemingly minor field, such as a wholesale account flag or tax-exempt status, affects pricing and fulfillment.

Protect exports and establish a source of truth

Before exporting data, confirm who owns each dataset and whether the export includes all stores, sales channels, and customer types. Run a full backup where possible, then create a read-only copy for analysis. Preserve the original files in an access-controlled location, using encryption at rest and during transfer.

Restrict access to the smallest practical group. Customer exports contain personally identifiable information, so they should not be emailed casually, stored on personal devices, or uploaded to unapproved file-sharing services. Record when each export was created, which filters were applied, and whether the file contains guests, registered users, deleted accounts, or test records.

Establish one approved source for each field. For example, the ecommerce database might be authoritative for online account credentials, while NCR Counterpoint could be authoritative for store account numbers or in-person purchase history. If two systems disagree, document the resolution rule instead of allowing an import tool to choose silently.

Payment information deserves special care. Do not attempt to move full card numbers or security codes into the new platform. Where tokenized payment methods are supported, confirm portability with the payment provider and the receiving platform. Otherwise, plan a secure customer reauthorization process and review payment gateway planning before promising stored-payment continuity.

Map and cleanse fields before import

Build a field-mapping workbook that lists the source column, target field, format, transformation rule, validation requirement, and treatment of missing values. Mapping should cover both obvious attributes, such as first name and email, and less visible data, such as customer groups, tax exemptions, communication consent, account status, and external IDs.

Use stable identifiers to connect records. An email address may help identify duplicates, but it can change, be shared by multiple shoppers, or differ in capitalization. A source customer ID is usually a better reference, especially when linking customers to historical orders. Keep the original ID in a custom field or migration reference so support staff can trace records after launch.

Clean data in a staging copy rather than editing the production export manually. Standardize capitalization, phone formats, country codes, postal codes, state or province values, and address line structure. Normalize email addresses carefully without changing the underlying identity. Flag invalid addresses, duplicate accounts, blank names, and records with conflicting consent values for review.

Handle privacy, consent, and account access

Customer migration is also a privacy exercise. Identify the legal basis and retention requirement for each type of personal information, particularly marketing consent, behavioral history, date of birth, and internal notes. Consent should not be inferred from the existence of an email address or an old order.

Preserve the original consent status, timestamp, source, and subscription category when the new platform supports them. If the source data cannot prove that a customer opted in to a particular channel, mark the record conservatively and avoid enrolling it automatically. Coordinate with the privacy, legal, and marketing teams before sending post-migration campaigns.

Passwords usually cannot be transferred in readable form. Depending on the destination platform, customers may need to reset their passwords, activate new accounts, or use a secure identity migration service. Communicate this clearly through an approved message that explains the change, gives the official sign-in path, and avoids requesting passwords by email.

Review contracts and processing arrangements with any ecommerce agency or migration partner. A specialist familiar with both retail operations and the target platform can help define responsibilities, and this agency selection guidance can inform the evaluation of technical, security, and support capabilities.

Test relationships and customer-facing behavior

Never make the first import the live import. Load a representative sample into a staging environment, including active accounts, duplicate candidates, international addresses, guest orders, wholesale customers, unsubscribed contacts, and profiles with unusual characters. Check that the target system accepts the records without truncating values or silently changing formats.

Test the relationships around each customer. A profile should connect to the correct orders, refunds, store credits, loyalty balances, and support references. Verify that guest orders remain available for reporting without accidentally creating multiple accounts. For broader order-history work, use a documented order mapping guide to align customer IDs, order IDs, products, taxes, discounts, and fulfillment data.

Run reconciliation reports after every test load. Compare record counts by customer type, country, account status, consent state, and date range. Select records at random and compare source and target values field by field. Also test searches, account activation, password resets, address changes, checkout, order-history display, refunds, and customer service workflows.

Plan the cutover and post-migration checks

Choose a cutover window that minimizes new activity during the final export. If the old environment can remain available, freeze account changes and orders briefly, take a final incremental export, and import only changes made since the last successful test. Record the exact timestamp and filters used so the team can prove what was included.

Prepare a rollback plan before launch. Keep the original export, staging results, transformation scripts, error logs, and import configuration together. Define who can pause the new store, restore a previous version, or resolve conflicts if customer records are incomplete. A rollback plan is useful only when it has clear triggers and named decision-makers.

After launch, monitor failed imports, duplicate creation, password-reset activity, delivery failures, consent changes, and customer service tickets. Reconcile totals again after the first day and first week. Keep a migration log showing corrected records and the reason for each correction, while preserving the original source data for audit and support purposes.

Practical safeguards for a controlled transfer

Use the following checks as a final operational review before approving the customer import:

• Export a complete, dated source backup and store it securely.
• Match source and target counts by account type, status, country, and consent category.
• Preserve stable source IDs and document every merge or exclusion rule.
• Test passwords, addresses, order history, payment references, and marketing preferences in staging.
• Assign owners for privacy approval, technical validation, customer communication, and launch support.

A successful transfer is measured by more than the number of rows imported. Customers should be able to recognize their accounts, support agents should be able to find relevant history, marketers should be able to honor consent, and finance teams should be able to reconcile connected transactions. These outcomes depend on documented rules and repeatable validation.

Retailers moving away from NCR Retail Online should start with a data inventory and a small representative test file rather than a rushed full export. Bring the ecommerce team, NCR Counterpoint partner, privacy owner, payment provider, and customer support lead into the same migration schedule, then approve the production cutover only after the evidence matches the checklist.