Enterprise data migrations involving Salesforce must navigate a complex matrix of regulatory obligations, contractual commitments, and Salesforce platform governance requirements. Compliance is not a post-migration checkbox; it must be embedded into every architectural decision from the pre-migration assessment through to the post-migration audit closure.
This guide walks through the regulatory requirements for Salesforce data migration compliance, how to configure Salesforce Shield before data migration begins, and how to build an audit log strategy that holds up when regulators or auditors start asking questions.
Table of Contents
Why Compliance Gets Left Until It’s Too Late
There is a simple reason why most migration teams delay compliance configuration: it isn’t on the priority list. Project plans, migration track records, cutover windows, and go-live dates—everything else is deemed critical. No one includes a milestone like “enable field audit trail,” so the process remains incomplete.
The problem is structural. Retroactive encryption does not protect data that was already written without it. Field audit trails cannot reconstruct changes that occurred before the policy was activated. If your migration took place over the weekend without audit logging configured, you don’t just have a documentation issue; you have an evidence issue.
That’s a harder conversation.
What GDPR, CCPA, HIPAA, and SOC 2 Actually Require from Your Migration
The four frameworks that most enterprise Salesforce environments deal with overlap enough that a single compliance setup addresses most of them.
| Regulation | Key Obligation | Migration Implication | Salesforce Control |
|---|---|---|---|
| GDPR (EU) | Lawful basis for processing; data minimisation | Only migrate data for which a processing consent exists | Data Classification metadata; Salesforce Privacy Center |
| GDPR (EU) | Right to erasure/data portability | Source system deletions must be reflected in the target | QueryAll API detects soft-deletes; hardDelete for GDPR compliance |
| CCPA (California) | Consumer right to know, delete, opt-out | PII fields must be tracked throughout migration | Field Audit Trail; Salesforce Shield Encryption |
| HIPAA (US Healthcare) | PHI protection; minimum necessary standard | Health data fields must be encrypted at rest and in transit | Salesforce Health Cloud; Shield Platform Encryption |
| SOC 2 Type II | Availability, security, and confidentiality controls | Migration pipeline must be within the audit scope perimeter | Event Monitoring logs; Salesforce Trust site |
Salesforce Shield: Encryption, Event Monitoring & Field Audit Trail
Salesforce Shield is an add-on product suite that provides enterprise-grade data protection capabilities essential for regulated industries (financial services, healthcare, government). For data migration projects in these verticals, Shield configuration must be completed before the migration data is loaded into the org.
- Platform Encryption (Shield): Encrypts field values at rest using AES-256 with tenant-specific encryption keys. Must be enabled and keys activated before migrating sensitive data. Encrypting fields on existing data after migration requires a separate data encryption job.
- Event Monitoring: Provides API-call-level audit logs including login events, data export events, Bulk API access events, and report executions. Enable Event Monitoring before migration to capture a complete audit trail of all migration API activity.
- Field Audit Trail: Extends the standard 18-month field history to up to 10 years. Configure Field Audit Trail on key fields (Status, OwnerId, Amount) before migration so that migration-era field values are captured in the audit history from day one.
Migration Audit Log Strategy
Every migration action should be recorded in a secure, tamper-evident audit store. The audit log serves multiple purposes: as key evidence for compliance audits, a primary diagnostic tool for investigating any post-migration discrepancies, and a key input for the migration sign-off report.
// Structured Audit Log Entry Format (JSON Lines / NDJSON)
{
"timestamp" : "2025-05-14T09:32:11.234Z",
"correlationId" : "mig-2025-q2-account-chunk-0047",
"event" : "JOB_COMPLETE",
"severity" : "INFO",
"object" : "Account",
"jobId" : "750Xx000004abcDEF",
"operation" : "upsert",
"chunk" : 47,
"totalChunks" : 120,
"recordsProcessed" : 50000,
"recordsSucceeded" : 49987,
"recordsFailed" : 13,
"failedJobPath" : "/migration/results/account/chunk_47_failed.csv",
"durationMs" : 94321,
"integrationUser" : "migration.service@company.org",
"sfInstanceUrl" : "https://company.my.salesforce.com"
}
Pre-Migration Compliance Checklist
Before a single batch job runs:
Data classification
- All objects and fields containing PII, PHI, or sensitive financial data are identified
- Lawful basis for processing each personal data category is documented (GDPR)
- Consent metadata is explicitly included in the field mapping document (CCPA)
- BAA is executed with Salesforce for covered HIPAA entities
Encryption and access
- Shield Platform Encryption is enabled on all PII and PHI fields in the target org
- All automations, reports, and integrations referencing encrypted fields are tested in the sandbox
- A dedicated migration integration user is created with the minimum necessary permissions
Audit configuration
- Field Audit Trail policy is active on all regulated fields before migration begins
- Event Monitoring log export is running and routing to SIEM or archive storage
- Log retention period is confirmed against applicable regulatory requirements
Documentation
- Data lineage document exists: source object > migration tool > target object > field mapping
- Migration is logged in your change management system with access approval records
Three Compliance Mistakes That Show Up on Nearly Every Migration
- Encrypting after migration, not before. Data written to Salesforce without encryption was not encrypted at the infrastructure level at that time. Enabling encryption later does not secure the pre-existing data. For PHI, encryption must be enabled in the target organization before the first record arrives.
- Leaving consent metadata behind. Field mapping documents focus on the obvious fields: names, email addresses, and account relationships. Consent logs, opt-out timestamps, and marketing preference flags get missed. A CCPA “do not sell” flag that doesn’t migrate is an incident waiting to happen, and it’s the kind of thing that surfaces months later in a data audit rather than immediately.
- Setting up the Field Audit Trail after go-live. The most common one, by a significant margin. Field Audit Trail is not retroactive. A migration that runs over a weekend, followed by Field Audit Trail configuration on Monday morning, means you have no audit record of the migration itself. That’s the entire dataset changed with no captured history.
Getting Compliance Right Is Mostly About Timing
The Salesforce tools for meeting GDPR, CCPA, HIPAA, and SOC 2 requirements during data migration exist and work well. Shield Platform Encryption, Event Monitoring, and Field Audit Trail give you what you need. The failure mode is rarely a product limitation. It’s timing and prioritization.
Build compliance configuration into the project plan from the start. Treat encryption setup, audit policy activation, and access controls the same way you treat governor limits: as design constraints that shape how the migration is built, not problems to address once data is already moving.
The next article in this series covers the migration cutover playbook: post-migration validation checklists, the T-72hr to T+8hr cutover window structure, and what to monitor in the first 48 hours after go-live.
Frequently Asked Questions (FAQ)
No. Data migrated via Bulk API or REST API travels over HTTPS, so it’s encrypted in transit. But if Shield Platform Encryption isn’t enabled on the relevant fields in the target org, the data will be stored unencrypted at rest. Encryption has to be configured before migration begins.
Classic Encryption masks a field value in the Salesforce UI but doesn’t encrypt at the storage infrastructure level. Shield Platform Encryption uses AES-256 to encrypt data in Salesforce’s database before it’s written to disk. For GDPR, HIPAA, and PCI DSS compliance, Shield Platform Encryption is the standard that applies.
It depends on which regulations govern your data. HIPAA requires a 6-year minimum retention for PHI-related records. GDPR has no fixed minimum, but typically warrants 3 to 5 years of audit evidence. SOC 2 retention is defined in your Trust Services Criteria, usually 1 to 3 years. When requirements conflict, default to the longest applicable period.
Not always. For standard CRM data such as professional contact details and business email addresses, native Salesforce access controls and field-level security may be sufficient. For sensitive personal data categories, including health data, financial data, or government identifiers, Shield Platform Encryption is strongly advisable and may be required based on your Data Protection Impact Assessment.
No. Field Audit Trail only captures changes from the moment the policy is activated. Standard field history may retain some data for up to 18 months, but Field Audit Trail’s extended retention and policy controls apply to future changes only. This is why it needs to be configured before migration begins, not after.
Kiran Sreeram Prathi
I’m Kiran Sreeram Prathi, a Salesforce Developer dedicated to building scalable, intelligent, and user-focused CRM solutions. Over the past five years, I’ve delivered Salesforce implementations across healthcare, finance, and service industries—focusing on both technical precision and user experience. My expertise spans Lightning Web Components (LWC), Apex, OmniStudio, and Experience Cloud, along with CI/CD automation using GitHub Actions and integrations with platforms such as DocuSign, Conga, and Zpaper. I take pride in transforming complex workflows into seamless digital journeys and implementing clean DevOps strategies that reduce downtime and accelerate delivery. Recognized by organizations like Novartis, WILCO, and Deloitte, I enjoy solving problems that make Salesforce work smarter and scale better. I’m always open to connecting with professionals who are passionate about process transformation, architecture design, and continuous innovation in the Salesforce ecosystem.
