What to do with customer data after an ecommerce migration

Moving an online shop to a new platform can feel complete once orders, customer accounts and stock records appear in the replacement system. Legally, however, the old database, exports, backups and administrator accounts may continue to create obligations long after the storefront has closed. The decision to keep or delete that information should be deliberate, documented and tied to a genuine business need. Learn more about Customizing Checkout Flows For Former Ncr Retail Online Customers.html.

This issue is especially relevant to retailers transitioning away from NCR Retail Online after its discontinuation. Australian businesses must balance privacy duties with tax, consumer protection, dispute management and security requirements. A clean migration therefore involves more than importing order history: it also requires a defensible plan for legacy data.

Identify what remains in the old environment

Customer information rarely exists in one neat file. A former ecommerce system may contain names, delivery addresses, telephone numbers, email addresses, account passwords, order notes, invoices, refund records, marketing preferences, IP addresses and support correspondence. CSV exports may sit in shared drives, while automated backups remain with the former host or an integration provider.

Begin with a data inventory that records each category, its location, its purpose and who can access it. Include staging sites, test databases, payment plugins, warehouse integrations and employee laptops. A product page such as this shoe catalogue is generally public information, whereas the customer and transaction records connected with browsing or purchasing require a much more careful assessment.

The inventory should distinguish personal information from non-personal business data. Product descriptions, public prices and stock-keeping codes usually present a different risk from a customer’s address or purchase history. That distinction helps prevent a retailer from retaining an entire legacy database simply because a small portion may be useful.

Apply Australian privacy rules

The Privacy Act 1988 and the Australian Privacy Principles are central for businesses covered by the Australian Privacy Act. The APPs generally require personal information to be collected and retained for a lawful purpose, handled transparently and protected from misuse, loss and unauthorised access. APP 11 also requires reasonable steps to destroy or de-identify information when it is no longer needed for the purpose for which it was collected, unless another law requires retention.

There is no universal Australian rule saying every ecommerce record must be kept for a fixed period. The correct period depends on the information, the business purpose, applicable legislation and credible operational needs. A retailer may need an invoice to answer a warranty question, but that does not automatically justify retaining an old password, abandoned marketing profile or full payment-related record.

Privacy notices and collection statements matter as well. If customers were told their information would be used to process orders and provide support, keeping it indefinitely for unrelated analytics may be difficult to justify. A documented retention schedule should state when information is reviewed, when it is anonymised and when it is securely erased.

Separate tax and consumer records

Australian tax obligations can require records to be kept longer than privacy-based business needs. The Australian Taxation Office commonly expects businesses to retain tax records for five years, although particular circumstances and record types can create different requirements. Sales invoices, GST documentation and transaction evidence should therefore be assessed with an accountant before deletion.

The Australian Consumer Law adds another practical reason to preserve selected records. Customers in Perth, Brisbane or regional New South Wales may contact a retailer months after purchase about a faulty product, refund or consumer guarantee. Keeping enough information to verify the transaction and resolve a complaint can be reasonable, provided access is restricted and unnecessary fields are removed.

A retention schedule can separate invoice and refund data from marketing data. For example, an invoice might be retained for tax and warranty administration while the customer’s promotional profile is deleted when there is no continuing consent or business purpose. Records held for a legal claim should be preserved through a documented legal hold rather than kept casually in the old platform.

Manage the migration contract

The agreement with the former platform provider should answer what happens to data after termination. Check clauses covering export, deletion certification, backups, subcontractors, audit rights, security incidents and assistance with transition. A provider may have copied information to support systems or disaster-recovery locations, so deleting the visible store alone may not complete the process.

For businesses moving from NCR Retail Online through a Counterpoint partner or another ecommerce provider, responsibilities should be allocated in writing. The retailer remains responsible for deciding why customer information is retained, while a service provider may process it on the retailer’s instructions. Contract language should identify who can access the old database, how long exports remain available and how deletion will be verified.

A migration checklist covering order history and invoices can help identify records that need to move for reporting, tax or customer service. It should also record what was deliberately excluded. The aim is controlled continuity, rather than creating several permanent copies of the same sensitive dataset.

Protect archived information

Keeping data for a legitimate reason does not remove the obligation to secure it. Old systems are often more exposed than current platforms because patches stop, administrator accounts are forgotten and integrations are no longer monitored. An unused database containing Australian addresses can be an attractive target even when the associated storefront is offline.

At a minimum, revoke former staff access, rotate credentials and API keys, apply available security updates and restrict the archive to named personnel. Encrypt stored exports and use secure transfer methods. Avoid retaining payment card numbers or authentication secrets where they are not essential; tokenised payment references are safer than raw card data and reduce exposure under payment security standards.

Backups need explicit treatment. A business should know how long backup copies persist, whether they can be restored, and whether deletion from a live system also removes them. If immediate removal from an immutable backup is impossible, restrict access, record the limitation and ensure the data disappears through the normal overwrite cycle.

Consider breaches and overseas providers

If an old database is accessed without authorisation and the incident is likely to cause serious harm, Australia’s Notifiable Data Breaches scheme may require notice to affected individuals and the Office of the Australian Information Commissioner. A forgotten legacy environment is still part of the organisation’s security landscape. Incident response plans should cover former platforms, archived exports and migration vendors.

Cloud hosting also raises cross-border questions. Australian Privacy Principle 8 may apply when personal information is disclosed overseas, and the retailer may remain accountable for an overseas recipient’s handling of that information. Confirm where the replacement platform, backups and support teams are located. A provider operating from Singapore, the United States or Europe may involve contractual and privacy considerations that were not obvious during a fast migration.

Australian retailers serving tourists or selling internationally may have additional obligations. A Melbourne store with customers in the European Union could fall within the GDPR for certain activities, while email marketing to Australian customers may engage the Spam Act 2003. These rules do not mean every record must be deleted immediately, but they make purpose, consent, access controls and retention decisions more important.

Build a defensible deletion process

Deletion should be systematic rather than an employee manually removing a few customer rows. Classify information into categories such as tax records, warranty evidence, support tickets, marketing contacts and obsolete technical data. Assign a retention period or review date to each category, then document the reason for keeping it.

Before erasure, check for unresolved complaints, chargebacks, litigation, audits and statutory recordkeeping requirements. After approval, delete live copies, revoke access, remove local exports and instruct processors to delete their copies where the contract permits. If complete deletion is not technically possible, anonymisation may be appropriate when the result can no longer be linked to an identifiable person.

Keep a short destruction log showing what was deleted, when, under whose authority and from which systems. The log should not reproduce the personal information it records. It provides evidence that the business followed a consistent process, which is valuable if a customer complains to the OAIC or a former vendor later reports a security incident.

A sensible Australian migration file will contain the data inventory, vendor correspondence, privacy assessment, tax advice, deletion certificate and access review. Set a calendar reminder for the next review rather than treating migration as a single event. The practical next step is to create that inventory today and mark every legacy customer-data location as retain, anonymise or delete.