Migrate from Proton to Salesforce Sales Cloud

Proton Contacts include name, email addresses, phone numbers, physical addresses, and custom fields exported in vCard format. We map each Contact to a Salesforce Lead by default. If the customer has pre-existing Account records or a clear qualification criteria, we apply a Lead-Contact split at migration time and document the rule in scoping. Original Proton contact fields map to typed Salesforce fields; unrecognized fields map to custom text fields for admin review.

Proton Calendar events include title, description, location, start/end time, reminders, attendees, and recurrence rules. We extract via Proton Calendar API and map to Salesforce Event records. Recurrence patterns translate to Salesforce Event recurrence fields. Reminders migrate to Salesforce Event reminder fields. Attendees map to EventRelation records linked to the corresponding Salesforce Lead or Contact by email resolution.

Proton Mail uses both hierarchical folders and color-coded tag-style labels. Salesforce has no direct label equivalent. During scoping we ask the customer to choose between mapping labels to Salesforce Topics (with TopicAssignment records) or to a custom multi-select picklist field on Lead and Contact. Folder hierarchy does not map to Salesforce; we flatten it into a label string or ignore it per the customer's preference.

Each paid Proton plan supports multiple encrypted email addresses organized as user accounts. We extract address identities from the Proton organization API and map them to Salesforce User records by email. The customer's Salesforce admin provisions the matching Users before migration so that OwnerId references are satisfied on migrated records.

Proton Drive stores files with end-to-end encryption. We decrypt client-side, extract file binaries and folder structure, and map them to Salesforce ContentDocument records linked to the migrated Contact or Lead via ContentDocumentLink. Folder hierarchy is preserved as a path string in ContentDocument Description or a custom field. Version history up to 365 days on Workspace Standard migrates as ContentVersion records with VersionData.

Proton Mail Plus and above support hide-my-email aliases (disposable forwarding addresses). We extract these as separate address strings and map them to a custom text field on the Salesforce Lead or Contact. Salesforce does not have a native alias object equivalent, so the alias list is preserved as a comma-separated custom field for reference and routing purposes.

Proton Workspace Standard supports up to 15 custom domains; Workspace Premium supports up to 20. We extract domain configuration and map DNS records (MX, SPF, DKIM, DMARC) to a DNS migration checklist delivered as written documentation. Custom domain ownership transfers at the DNS registrar level; Salesforce domain verification is a separate admin step documented in the handoff package.

Proton for Business organizes users into teams with role-based access. We extract team membership and role assignments and map them to Salesforce User records and Salesforce Groups. Role translation is approximate because Proton's privacy-centric permission model differs structurally from Salesforce's profile and permission set model.

Proton is not a CRM and has no Account or Company object. If the customer has Account data in a separate system (ERP, spreadsheet, or legacy CRM), we can ingest it during migration as a separate data stream. If no Account data exists, we flag the gap and advise the customer to create Account records post-migration or to use the Lead object as the primary contact container until Accounts are available.

Proton has no deal or pipeline objects. Opportunity data does not exist in Proton to migrate. We flag this gap explicitly in scoping so the customer understands that Salesforce pipeline data must be built post-migration from CRM activity, forecasting inputs, or a separate deal registration system.

Proton Pass stores credentials in an end-to-end encrypted vault. The E2E key is held by the user and Proton cannot access plaintext. We do not migrate vault entries as a data object because there is no meaningful Salesforce equivalent and credential data requires separate security review. We advise the customer to export vault data as a structured file from Proton Pass directly if a password manager migration is planned separately.

Proton VPN configuration profiles are platform-specific and tied to Proton's infrastructure. VPN tunnel configurations cannot be mapped to other VPN providers or to Salesforce. We do not include VPN profiles in the migration scope and note this in the written inventory.