Napoleon Perdis said its current online store was unaffected by the breach reported this weekend. The customer information involved was held in an older system with Retail Express, a provider the retailer had previously used. For anyone who has recently replaced a website or moved customer records to another platform, that distinction deserves attention: a working replacement tells you little about what remains at the previous provider.
ABC News reported on 17 October 2026 that Napoleon Perdis had emailed customers about approximately 339,055 affected records. According to the notification quoted by ABC, Retail Express confirmed in August that unauthorised access had occurred between November 2025 and June 2026. The records concerned customers from before June 2025 and included names, contact details, dates of birth and purchase histories.
The company said the affected system held no payment-card or bank details, or passwords for its current website. It also said the incident had been contained and the system permanently shut down. ABC reported that the OAIC had been notified.
That reporting does not establish why the older records remained, whether anyone had requested deletion, or what retention arrangements applied. It would be unfair to turn it into a finding that either company unlawfully kept information, or to assume that a website migration led to this breach. The broader issue is worth examining whenever a business leaves a technology provider.
The old shop can still have the customer list
Consider a separate, hypothetical example: a small Australian retailer moving to a new ecommerce provider. Customers can place orders and the new payment service works. Staff stop opening the old dashboard. It is tempting to call the migration complete at that point, particularly when everyone wants to get back to running the shop. That is too narrow a view of the job.
Recent orders may need to move so staff can handle returns. Older invoices may belong in a restricted archive for accounting or legal purposes. Some customer contact information may still be needed for ongoing service, while abandoned accounts and obsolete delivery details may have no continuing purpose. Copying the entire database into the new platform saves someone the effort of sorting through it, but carries everything forward regardless of whether it is still useful.
Before cancelling the old service, the retailer needs to establish which records must remain usable and check that the export actually contains them. An order list without the detail needed to resolve a customer enquiry may be inadequate. Keeping the old shop running indefinitely because nobody checked the export is an expensive way to discover that problem.
Keeping an archive with the former provider may be a sensible arrangement. The owner still needs to know where it lives and who can open it, with protection suited to the information it contains. Its purpose should be recorded, along with when retention will be reviewed or the records deleted. A legal requirement to retain particular transaction records does not automatically justify keeping every customer profile and marketing field alongside them.
“Deleted” needs a scope
Removing the live database is only one part of retiring that retailer's old system. The migration may also have produced a database dump, a spreadsheet on the owner's laptop and a test copy used by the new developer. The former provider may hold backups on a separate schedule. Those copies need to be accounted for while the people who created them still remember where they went.
I would want a completion note that identifies what was removed and what remains. A provider confirming deletion of the production database should say whether that includes exports and staging copies. If backups will expire later, record the applicable schedule, access restrictions and how deleted information will be handled if a backup is restored. Some backup systems cannot selectively remove a customer's records immediately; that needs an understood, documented arrangement rather than an assumption that every copy disappeared when the account closed.
There can be legitimate reasons to keep recovery copies for an agreed period. They still need protection, and their retention needs to be assessed against the business's obligations. “We keep backups” is too vague to explain how long the former provider will hold customer information or what happens at the end.
The old administrator accounts may also still work, even after the storefront has gone offline. A former provider with credentials for a separate CRM can still reach records the business uses every day. That access needs removing when it is no longer needed, with shared credentials replaced where appropriate. Limited support access can be useful during a handover, provided its purpose is clear and someone is responsible for ending it on the agreed date.
For businesses covered by the Australian Privacy Principles, APP 11 requires reasonable steps to protect personal information they hold. It also requires reasonable steps to destroy or de-identify information no longer needed for a permitted purpose, subject to exceptions including legally required retention and Commonwealth records. Outsourced storage can still count as information the business holds where it retains control over the records.
The OAIC's small-business guidance explains that most businesses with annual turnover of $3 million or less are exempt, with exceptions including health service providers. An owner should establish which obligations apply rather than infer coverage from business size alone. Specific retention periods depend on the records and applicable law; get advice where that is unclear. An archive labelled “just in case” is not a substitute for deciding what must be kept.
A simpler website does not clear the archive
There is good reason to settle this during website migration planning, while the old provider is still involved and the budget has not been closed off. Waiting until after launch makes it easier for the remaining work to drift. Decisions about what moves and what must be retained need to be followed through, including secure deletion of unnecessary copies and confirmation of any access that survives the handover.
A brochure website can often run as static HTML without a publicly accessible customer database or a live CMS. Where dynamic functionality is unnecessary, removing those components reduces what needs to be maintained and exposed. But a static rebuild does not delete the previous site's enquiry database, and a connected form service, mailing platform or CRM may continue processing customer information.
Calling the retailer's migration complete while nobody can account for the old records would be premature. Any retained archive needs an owner and a reason to exist, and the former provider's remaining copies and access need agreed limits. A functioning replacement system proves that the new environment works. It provides no evidence that the previous one, or the customer information it held, has been properly retired.