Lesson 3 of 5
Privacy in migration
13 min
Data migration moves large amounts of personal data: customer contacts, supplier bank details, employee names on documents, sometimes consumer addresses for warranty claims. It copies that data into extract files, staging areas, test systems and spreadsheets used for validation. Each copy is a privacy risk. The program's obligations depend on the jurisdictions involved and are set by the company's privacy officer and legal counsel; this lesson covers the practical controls a migration lead must plan for.
Principles that shape migration scope
- Data minimization: migrate only the personal data needed for the purpose. Inactive customer contacts and old one-time customers are prime candidates to leave behind.
- Purpose limitation: data collected for one purpose should not be repurposed casually, for example by loading old consumer warranty addresses into marketing.
- Storage limitation: personal data should not be kept longer than needed; retention for legal reasons is a purpose, but it ends.
- Security: every copy of personal data needs appropriate protection, including test systems and extract files.
The personal data lifecycle in SAP
SAP S/4HANA supports these principles with simplified blocking and deletion based on SAP ILM. SAP describes the lifecycle like this: personal data is processed while there is business activity; after the end of business, a residence time may follow; at the end of purpose the data is blocked so that only authorized users, such as auditors, can see it; at the end of retention it is deleted. An end-of-purpose check decides when a business partner can be blocked.
- ActiveBusiness processingOrders, invoices and payments with the customer
- End of businessLast activity completedResidence time starts, for follow-up such as returns
- End of purposeBlockedOnly authorized users, such as auditors, can display the data
- End of retentionDeletedDestroyed when no retention requirement or legal hold remains
For migration, this has two consequences. First, records whose purpose has already ended in the source should generally not be migrated as active data; they belong to retention, not to the new system. Second, the new system's blocking and deletion settings should be designed and tested before go-live, so that migrated records enter a lifecycle that works from day one.
Controls for migration copies
| Where personal data appears | Risk | Control |
|---|---|---|
| Extract and staging files | Copies on shared drives, laptops or email | Restricted, encrypted storage; no email; deletion after go-live with evidence |
| Mock load target systems | Full production data in a system with wider access | Access limited to named roles; access reviews; no generic users |
| Test clients built from mocks | Testers and offshore teams see real personal data | Anonymize or scramble where testing allows; restrict where it does not |
| Validation spreadsheets | Bank details and contacts in personal files | Validate with counts, totals and masked samples; central controlled storage |
| Load logs and error lists | Records with personal fields in messages | Same retention and access rules as the data itself |
Where personal data spreads during a migration and how to control it.
Privacy questions to settle before Mock 1
Most privacy problems in migration come from decisions nobody made in time. Settle these with the privacy officer before the first mock, because the first mock is when real personal data first leaves the source system: which personal data categories are in scope and why; where extracts and staging data are stored and who can open them; which systems and clients will hold copies, for how long, and with which access rules; which fields will be masked or scrambled for testing; and how copies will be deleted after go-live and how that deletion will be evidenced. Write the answers into the migration plan and check them at every mock review, not only at the start.
What would you do?
Priya wants to refresh test client 100 with data from Mock 3 for user acceptance testing. Some testers work for an offshore partner. What is the best approach?
- Migration multiplies copies of personal data: extracts, staging, mocks, test clients, spreadsheets.
- Minimize scope: do not migrate personal data with no remaining purpose.
- SAP's lifecycle: end of business, residence, end of purpose (blocking), end of retention (deletion).
- Protect every copy, design blocking and deletion before go-live, and clean up after it with evidence.
Check your understanding · not graded
Lesson check
1. Which principle argues against migrating contacts of long-inactive customers?
2. In SAP's blocking and deletion lifecycle, what happens at end of purpose?
3. Who confirms which privacy rules apply to the migration?
4. Which is a good way to validate supplier bank details?