Migrate from Populate to Salesforce Sales Cloud

Direct map. Salesforce requires an AccountId on Contact, so contacts without a primary company are attached to a default 'Unassigned Account' record or routed to a Lead based on the status field mapping you define. During discovery we capture routing rules (e.g., Prospect → Lead, Customer → Contact) and note your preference for per‑contact accounts or fallback. This logic is verified in the test migration.

Split map. If Populate stores a separate prospect record type, those records route to Salesforce Lead based on the status or type field values that distinguish them from customer contacts. We capture the exact field values, map them to Lead Status picklist entries, and document the mapping in the plan. Leads do not require an AccountId and can be converted to Contacts later via standard Lead conversion.

Direct map. Populate company hierarchies (parent/child) map to Salesforce ParentId on Account, preserving the parent name and depth. When a Populate contact has multiple associated companies, we link the primary company as AccountId and surface additional companies via Account Contact Relationships (junction object). This ensures all company links are represented in Salesforce and can be queried for reporting. The mapping documents each junction relationship and flags circular parent references.

Direct map. Populate deal pipelines map to Salesforce Sales Processes tied to record types. Each pipeline requires a Salesforce record type so stage pick‑list values are correctly scoped per deal category. We create record types, assign page layouts, and set stage probabilities for each type. The mapping table shows each Populate stage paired with its Salesforce name, probability, and forecast category, preserving your original deal progression.

Populate pipeline becomes a Salesforce Sales Process keyed by RecordTypeId. Teams with multiple pipelines in Populate will have multiple Salesforce record types, each requiring its own page layout, profile assignment, validation rules, and stage set before data lands. We provide a record‑type checklist with fields, permissions, and stage values for each Sales Process, so the schema is ready when migration runs and records land in the correct type.

Stage names map value‑by‑value per record type. Stage probability and forecast category are re‑applied from Salesforce defaults unless you specify custom values; in that case we record the custom probability and forecast category in the mapping table. HubSpot stage‑entered timestamps are preserved as custom datetime fields (e.g., Original_Stage_Entered__c) for audit continuity. The migration plan includes the complete stage mapping for each record type, including any required pick‑list value creation in Salesforce.

Populate calls and emails map to Salesforce Tasks with Type='Call' or Type='Email', while meetings map to Events preserving start and end times. Notes map to Salesforce Notes. All activity records retain timestamps, owners (via OwnerId), and parent‑record links through WhatId or WhoId. Custom fields on activities are created in Salesforce and mapped during migration. File attachments on activities are re‑uploaded as Salesforce Files and linked via ContentDocumentLink.

Populate custom objects map 1:1 to Salesforce custom objects with the __c suffix, preserving field values. If a Populate custom object uses a many‑to‑many (N:N) association, the migration plan creates a Salesforce junction object with lookup fields to each parent. We document every custom field mapping and the foreign‑key relationships so integrity is verified before load. The plan also lists any custom indexes or validation rules to re‑create.

Populate file attachments are re‑uploaded to Salesforce as ContentVersion records, creating a ContentDocument link for each parent record. Salesforce enforces a 25MB per‑file limit; files exceeding this are flagged and can be split or stored externally with a URL reference. We preserve the original file name and size as metadata on ContentVersion. Inline images embedded in notes are extracted, downloaded, and re‑hosted in Salesforce Files, ensuring they render after migration.

Owner resolved by email match to Salesforce users. Unmatched owners are flagged in an owner report — your team either invites them to Salesforce first or assigns their records to a fallback user. No record migrates without an OwnerId; after the owner report is resolved, all records receive the owner lookup. If an email has no Salesforce user, the record is assigned to the fallback owner and flagged for correction.

Workflows, sequences, and automation rules do not migrate. FlitStack exports the workflow definitions as a reference document listing trigger objects, conditions, and actions for your Salesforce admin to rebuild in Flow. Automation rebuild is outside the data migration scope and is priced separately; we recommend scheduling a call to scope the Flow rebuild effort. The document can also be used to compare new automation against the original Populate logic.