Migrating a webshop looks like a technical task: move the products, the orders and the images, hook up the payment methods, set up the redirects, and the new system can go live. With customer data, however, there's far more at stake than simple data copying. A live webshop's database can contain names, email addresses, phone numbers, billing and shipping addresses, order histories, marketing consents, user accounts and authentication data. For a larger webshop, that can mean hundreds of thousands or even millions of records.
If their migration is poorly organised, you're not just risking a technical glitch — you're risking a data breach, which nobody wants.
From a GDPR standpoint, moreover, it's not only how the new webshop will operate that matters. The export itself, the transfer, the temporary storage, the import and the deletion of the old copies are all data processing operations.
GDPR applies during the webshop migration too
There's a basic principle: the GDPR's concept of data processing is deliberately broad. Processing isn't just when a webshop displays a customer's name or stores their order — it also happens when the database is copied out of the old system, uploaded to a migration server, handed over to a developer, restructured, or loaded into the new system. An important practical rule follows from this: the webshop owner cannot treat the migration as if it were solely the IT provider's business.
If it's the merchant who determines what customer data is processed and for what purpose, they typically remain the data controller. The developer, hosting company or platform provider carrying out the migration usually takes part in the process as a data processor.
According to the European Data Protection Board's guidelines, the relationship between controller and processor must be governed by a proper data processing agreement. Among other things, it must cover the subject matter, duration and purpose of the processing, the categories of data involved, the data security obligations and the conditions for engaging sub-processors.
Migration risk is very real
Hungary has already seen a data protection authority proceeding tied specifically to the migration of a customer database.
In a case published in 2025, the NAIH (Hungarian data protection authority) investigated an incident where a database held roughly 3.6 million pieces of personal data belonging to around 900,000 individuals. The problem didn't stem from someone importing the wrong data. A server's firewall came back up with a faulty configuration after a restart and, for a period, allowed network access that should never have existed. The faulty state persisted for several days, and unauthorised data queries did occur; names, email addresses, phone numbers, home addresses and bank account numbers were all affected.
Do you need fresh consent just because you're moving to a new webshop engine?
Generally, no. If a business switches from one webshop platform to another, the legal basis for processing customer data doesn't automatically change. A webshop doesn't process the data of a past order because the customer consented — it does so because it's needed to perform the contract or to fulfil a legal obligation. Swapping the technology stack doesn't, in itself, make obtaining new consent necessary.
Things are different if the processing itself changes along with the platform switch. For example, the new system starts doing profiling that didn't exist in the old one, or a new company begins using the customer data for its own purposes. At that point we're no longer talking about a simple technical migration. The legal basis, the purposes of processing and the information given to data subjects all need to be re-examined.
So the point isn't whether the webshop engine's name has changed. The question is whether the substance of the data processing has.
You may not need to migrate everything
Before migrating, it's worth asking a deceptively simple question: do you really need every piece of data sitting in the old system?
In practice, many webshop databases grow for years. Along the way, data accumulates that's no longer needed: old temporary addresses, obsolete technical logs, fields from long-retired features, abandoned imports, or marketing information whose processing purpose expired ages ago.
Carrying all of this over automatically is bad practice. The GDPR's data minimisation principle implies that only personal data genuinely needed in the new system should make the move. That's why a migration should start with a data inventory.
Review what data the current webshop stores in customer accounts, what the orders contain, what technical log data exists, which marketing consents are tied to customers, and what authentication information sits in the database. The only question left is which of these can move over to the new system.
Marketing consent must be migrated too — not just the email address
The newsletter database can be a particular source of trouble. For a webshop, it's not enough for a customer record in the new system to carry a “subscribed” flag. You may need to be able to prove when and under what circumstances the consent was given. A well-run system therefore stores more than just the email address. The timestamp of the consent, its source and other information that can later help demonstrate its lawfulness can all be preserved.
The same goes for unsubscribes. A distinctly unpleasant situation can arise if, after a webshop migration, some previously unsubscribed customers start receiving marketing emails again — because only the active email addresses were carried over to the new system, while the opt-outs were not.
In a migration, then, the “does not want marketing” flag is at least as important as the address itself.
A password is not a field you can simply copy over
One of the most sensitive technical questions in any webshop migration is the handling of user passwords.
In a modern system, passwords must never be stored in readable form. Ideally, not even the webshop's operator can tell what password a given user has. Instead, the system stores a password hash. When the user logs in, the password they enter is run through the same mathematical process to produce a verifiable value, which is compared with the one stored in the database. This may sound like a technical footnote, but in a migration it's of decisive importance.
If someone says “let's export the old passwords and load them into the new webshop”, you should suspect a misunderstanding — because if we're talking about actual, readable passwords, that's a serious security problem!
Not every password hash can be carried over cleanly
The ideal case is when the new system can handle the password hash format used by the old webshop. Then the hash itself can be migrated, and the customer can log in with the same password after the move. For this, you need to know exactly how the previous system worked.
If the new platform doesn't support the old scheme, the hashes generally can't simply be “converted”. That's the whole point: the original password must not be recoverable.
In such cases, it's often cleaner and safer to migrate the customer accounts and request a password reset at first login. From a user experience standpoint it's not perfect, but security-wise it's a better decision than keeping an outdated password scheme alive for years just to avoid asking for a new password.
Although all of this may sound intimidating, migrating between webshop systems can be done safely once it's properly mapped out — reach out to the Sellvio team if you have any doubts at all!