Four ICO and PECR questions Leeds merchants should ask before a platform migration

What to take away

Why a platform migration is a data protection decision

Moving from one ecommerce platform to another looks like a replatforming project. In law it is a change in who holds your customers' personal data, for how long, and on whose instructions. That makes it a data protection decision under the UK GDPR and the Data Protection Act 2018, with PECR alongside.

Picture a Leeds merchant with a shop on Vicar Lane or in the Corn Exchange and a warehouse out at Stourton or Thorpe Park. Its estate is a storefront platform, a payment provider, an email tool, a helpdesk and a warehouse system. Each holds names, addresses, order histories, sometimes allergy details from product notes.

The ICO's guidance on controllers and processors is the starting point for working out who is answerable for what.

PECR sits alongside UK GDPR. It governs cookies and similar storage, and it governs electronic marketing. A migration touches both, because a new platform usually means new tags, new scripts and a new consent banner.

Leeds hosts one of the UK's largest financial and business services clusters outside London. Its retail core runs from Briggate and Kirkgate Market to Trinity Leeds and Victoria Leeds, and merchants trade under Leeds City Council and West Yorkshire Trading Standards.

Those businesses routinely compare platforms on card fees, Faster Payments, subscription billing and VAT handling. Those comparisons tend to stop at fees. The data terms are where the risk sits.

Start by writing down the real data flow. Freeze the store's real data flow, then review GDPR, PECR and cookies one at a time, rather than accepting the platform's marketing diagram. Then answer the four questions below.

Question one: who is controller and who is processor

For your own customers, you are almost always the controller. The platform is usually your processor. That holds whether the platform hosts the checkout, the product catalogue or both.

Two exceptions matter. If the platform uses customer data for its own purposes, such as improving its own models or marketing its services, it is a controller for that use. If the platform decides retention or reuse, that is a controller decision.

The distinction decides who answers a complaint, who signs a data processing agreement, and who notifies a breach. It also decides who pays.

Ask for the processing terms before commercial terms. A contract should schedule data roles to exit: what the platform does, what it may not do, where data sits, how it is returned or deleted, and what happens on termination.

The ICO expects a written contract between controller and processor, and it expects the processor to act only on documented instructions.

Sub-processors are the usual gap. Cloud hosting, email delivery, fraud screening and analytics are often sub-contracted. You need a list, a change notification route, and a right to object.

Be clear which platform operating model you are choosing. Comparing the options on control, cost, data, support and exit is a useful frame, because control and data sit next to each other for a reason.

Question two: how does cookie consent survive the migration

Cookie consent rarely survives a migration intact. Consent is tied to a specific purpose, a specific tool and often a specific consent record. Switch the tag manager or the analytics vendor and the old consent may no longer cover the new processing.

The ICO's guidance on the use of storage and access technologies sets out the standard: consent before non-essential storage or access, clear information, and an easy way to withdraw.

There are three practical traps.

Fix it before cutover, not after. Export consent records in a usable format. Map every tag to a purpose and a lawful basis. Re-paper the banner so it names the categories you actually run.

Check whether any consent you hold was given under a different brand or domain. Consent given to one website does not automatically carry to another.

Question three: can you answer a subject access request after cutover

A subject access request is a request from a person for their own personal data. You have a month in which to reply, and for complex requests this can be extended by two months. The ICO's subject access requests guidance covers how to search, what to redact and how to refuse manifestly unfounded requests.

The migration question is simpler than the law: can you still find the data?

During cutover, customer records often live in three places at once. The old platform, the new platform, and a migration staging area or CSV export. A request that arrives on day two of a migration must be answered from all three.

Ask the platform what search tools you get. Can you search by email, by order number, by partial name? Can you export a person's full history, including support tickets and marketing preferences?

Backups are the common failure. Many platforms will not let you search backups at all, and will only restore a whole instance. If that is the case, say so in your records and be ready to explain the limits to the requester.

Test it. Before go-live, run a synthetic subject access request for a test customer and time how long it takes to assemble. Controlled migration and rollback describes how to run that test without touching live customer data.

Question four: what happens if there is a breach during migration

Migration windows are the riskiest period for a breach. Data is in transit, access is widened for contractors, and temporary credentials are everywhere.

A personal data breach is any security incident leading to accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to personal data. If it risks people's rights and freedoms, you report it to the ICO within 72 hours of becoming aware.

The ICO's report a breach guidance explains what to include and when you can report in phases.

The 72 hours runs from awareness, not from the end of your investigation. That is why the plan has to exist before the migration starts.

Separately, check the data protection fee. Most UK organisations that process personal data must pay it unless an exemption applies, and the ICO's data protection fee page lists the tiers and the exemptions. Non-payment is a separate breach of the law and can attract a penalty.

How Shopify, WooCommerce and BigCommerce differ on the four questions

The four questions land differently depending on the platform model. This is a structural comparison, not a feature audit, so confirm current terms with each supplier.

The practical difference is who carries the work. A hosted platform gives you one contract to review and a supplier breach route, while WooCommerce gives you control and more contracts to manage. Score both on the same four questions, alongside Shopify and WooCommerce differences in technical work.

A migration evidence sheet for Leeds merchants

Keep one document. It is what you show a regulator, a customer or an insurer.

Then work through the sequence.

Whether you sell from a unit in the Corn Exchange or a warehouse in Holbeck, put these four questions on the same scorecard as VAT handling, card fees and subscription billing. The answers change which platform is cheapest once the data work is priced in.

Common questions