Card data and passwords do not travel. Test data masking, time-limited access, count-sample-total verification, a written rollback plan and destroying copies.
A data migration is the moment personal data is most exposed: while moving between two systems, while being copied into test environments, and while temporary access is open. This article covers the risk points, test data masking, verification methods and the rollback plan.
Migration projects usually discuss "did all the data transfer". That matters, but it is not the only question. The second is: who saw it while it moved, where was it copied, and what happened to those copies? Test databases forgotten after a project ends are among the most common sources of data leaks.
What we are protecting
| Data type | Example | Risk |
|---|---|---|
| Personal data | Name, address, phone, email | Regulatory obligation, reputation |
| Special category data | Health, biometric (if any) | Heavier protection obligation |
| Payment data | Card details, transaction records | Should not move; stays with the provider |
| Authentication | Password hashes, session tokens | Should not move; should be reset |
| Commercial data | Price lists, margins, dealer terms | Competitive damage |
Rows three and four are rules: card data and passwords do not travel in a migration. Card data stays with the payment provider; passwords are reset in the new system and users are asked to set new ones. This is an operational necessity as much as a security one — we cover the same point in WooCommerce to Shopify migration.
Data protection obligations vary with your circumstances; review your migration plan with your legal adviser. This is a technical framework, not legal advice.
Risk points
- During transfer. If data moves as files it must be encrypted; a database dump sent by email attachment or shared cloud folder is the most common mistake.
- In test environments. Real customer data pulled into development and test does not get the same protection as production.
- In temporary access. Permissions opened for the project are not closed when it ends.
- In backups. Pre-migration backups sit for years with no retention period set.
- With suppliers. Copies left with the agency or consultant who ran the migration.
What these five share: none is technically hard, and all happen because nobody planned for them.
Test data masking
| Field | Approach |
|---|---|
| Name | Replace with fake but consistent names |
| Redirect to a fixed test domain | |
| Phone | Randomise while preserving the format |
| Address | Keep city/district, replace the street address |
| National ID / tax number | Remove entirely or replace with an invalid value |
| Order amounts, dates | Usually keepable (needed for analysis) |
An important detail: masking must be consistent. The same customer record should appear with the same fake value across tables, otherwise relationships break during testing and the masked data becomes useless.
There is a side benefit: with no real data in the test environment, the effort needed to secure that environment drops too.
Access control and traceability
- Least privilege. Whoever runs the migration should reach the tables they need, not the whole database.
- Named accounts. Individual accounts rather than a shared login, so actions can be attributed.
- Time-limited access. Permissions should be opened for the project duration with an end date set upfront.
- Logging. Who exported what, and when.
- Closure check. Verify against a list that every access opened has been closed.
Verification: is the data complete
- Counts. Are record counts equal per table between source and target? Any difference should be explainable (for example, deleted records not migrating).
- Sampling. Compare randomly selected records field by field. Especially date formats, decimal separators and non-ASCII characters — the three things that break most often.
- Totals. Sums of numeric fields (total order value, say) should match on both sides. If counts match but totals do not, the data moved but was corrupted.
The third check is the most skipped and catches the most errors.
Rollback plan
- Where the full pre-migration backup is and how long restoring takes
- The threshold for rolling back (for example, a critical flow not working)
- Who makes the decision
- What happens to data created after the switch — the hardest part, because orders in between can be lost on rollback
Keeping the rollback window short shrinks that problem: deciding within the first hours after the switch means little data in between.
After the migration: destroying copies
- Delete data copies in test and development environments.
- Remove the files used for transfer, and any cloud folders.
- Obtain destruction confirmation for copies held by suppliers.
- Set a retention period for migration backups and diarise it.
- Write down when the old system will be switched off and how long its data will be kept.
Checklist
- Is it written down which data types will and will not migrate?
- Are card data and passwords out of scope?
- Is test data masked, and is the masking consistent?
- Was access opened as named, time-limited and least-privilege?
- Is the transfer happening over an encrypted channel?
- Were count, sample and total checks all performed?
- Is there a written rollback plan with a named decision maker?
- Is destruction of copies listed as a closure task?
Common mistakes
- Pulling real data into test. The most common and most easily prevented risk.
- Putting a backup in a shared folder. Unencrypted, unlimited and untraceable.
- Not closing project permissions. Access is still open months later.
- Verifying record counts only. Counts can match while content is corrupted.
- Not writing the rollback plan down. A verbal plan does not work in a crisis.
Conclusion
Security in a data migration is not an extra stage but part of the plan: deciding what will not move, keeping real data out of test, opening access with an end date, and destroying copies at closure. With those four done, what remains is verifying data integrity.
For the SEO and technical side of a platform move, see WooCommerce to Shopify migration; for permanent data flow between systems, see ERP integration.
At Commerslab we run data migrations including masking, verification and destruction steps. See our data migration service or get in touch about your migration plan.
