Privacy, security and access: the constraints that shape the work
Where migration data may be processed, by whom and under what security and access controls, settled before the first record is replicated.
Data work at scale usually involves copying production data from its system of record into an environment where it can be transformed and tested. That act engages the client's privacy obligations, its information security policy and its identity controls, and each can alter the design of the engagement. They are settled at the outset, because a constraint discovered late ordinarily means rework rather than delay. The Salesforce permission model behind several of the answers below is introduced in Trailhead's data security module.
Security constraints on a data migration
| Constraint | Question | Consequence for the work |
|---|---|---|
| Privacy regimes | Do GDPR, CCPA or sector-specific regimes apply to the data or its sources? Must data subjects or regulators be notified? | Determines whether personal data may be copied into test environments, and whether it must be masked, minimized or processed in region. |
| Privacy function | Has the client's data protection officer or privacy team imposed restrictions on processing, residency or retention? | May require an approved processing record, a data processing agreement, or the exclusion of specific fields. |
| Masking | Must email addresses and other contact fields be masked in sandboxes? | Masking keeps test messages from reaching customers and, depending on the method, keeps personal and other sensitive data unreadable in test environments. |
| Information security | Must the work be performed on client-issued devices, from specified locations, or within defined hours? | Governs where our team may work and whether overnight loads can be monitored, including any follow-the-sun coverage the project would use. |
| Identity | Will members of our team authenticate through the client's single sign-on? | Named logins for source review and target validation are provisioned per person and per org. |
| Integration user | Can an API-enabled user be created in each source system and in the target org without multi-factor authentication, restricted instead by IP range or permissions? | The ETL tooling cannot answer an interactive authentication challenge. Without such a user, replication and loading cannot run. |
| Audit fields | Does the load user hold the permissions to set audit fields on creation and to update records with inactive owners? | Without them, created dates and users take the date and identity of the loading user, as do the owners of records whose original owner has left, unless the load assigns a different default. The client decides which it wants. |
| Environment ownership | Who provisions, owns and decommissions the migration environment? | The environment is the client's, under its controls. Our team works within it, and the client decides when to withdraw it; we advise keeping it until the end of the stabilization period. |
Constraints that travel with the scripts
Each answer is recorded against the requirement it governs, so that the constraint travels with the scripts it affects. The removal of email masking, for instance, is a line in the production cutover runbook, not a recollection.
Assess the data before the agents depend upon it
The first call is with the practitioners who would do the work, not a sales intermediary. The measures come first and the estimate follows.