Migrate from ContactDB to Salesforce Sales Cloud

ContactDB contact records map directly to Salesforce Contact. We ingest the CSV export row for each ContactDB contact and map FirstName, LastName, Email, Phone, and Title to the equivalent Salesforce Contact fields. Because ContactDB does not enforce a required LastName, we flag any record missing a name value for customer review before insert. The Contact's AccountId is resolved via the Account lookup step (see below) before the Contact record is created.

ContactDB exposes firmographic attributes (company name, size, industry, SICCODE) per contact row. We extract distinct company names from all contact records, deduplicate by normalized domain (extracted from email address where available), and create one Account per unique company. Company size maps to NumberOfEmployees; industry maps to Industry (Salesforce standard picklist, with unmapped values placed in a custom text field); SICCODE maps to a custom field sic_code__c. Accounts are created before Contacts so that AccountId lookup resolution is satisfied at Contact insert time.

ContactDB segments contacts by industry, profession, title, country, and software usage, but these segment labels are not exported as standalone tag objects. We reconstruct segment membership as one or more custom multi-select picklist fields on the Contact object in Salesforce, using the customer's confirmed segment categories. The customer chooses during scoping whether to create separate fields per segment axis or a combined Segment__c field.

ContactDB provides company size as a banded value (e.g., 1-10, 11-50, 51-200). We map these to the nearest integer midpoint for Salesforce NumberOfEmployees or, if the banded format is required for reporting, store the original band as a custom text field company_size_band__c alongside the numeric approximation.

ContactDB industry values are mapped to Salesforce Industry picklist values. Unmapped industry strings are preserved in a custom field original_industry__c and the customer is asked to provide a mapping table during scoping. SICCODE migrates to a custom field sic_code__c (text) on Account.

ContactDB provides a credit rating signal per contact. This maps to a custom field credit_rating__c (picklist) on the Account object. Values are preserved verbatim and the customer confirms the value set during scoping.

ContactDB provides mailing address fields (street, city, state, postal code, country) per contact. These map to the standard Salesforce Contact MailingAddress compound field. State and country values are validated against Salesforce's supported state and country ISO codes; unmapped values are flagged for customer correction before insert.

Email addresses map to the standard Salesforce Contact.Email field. We apply a pre-import validation that flags records with missing, malformed, or obviously bounced email formats for customer review. Valid emails insert normally. Email addresses are used as a secondary dedupe key when matching Contacts to existing Salesforce records during incremental migrations.

ContactDB does not document a custom fields schema. Any extended attributes stored against contacts in the platform are proprietary and not exposed in export packages. We explicitly scope custom field migration as out of scope and note that any extended data the customer wishes to preserve must be provided as a supplemental data dictionary or a separate CSV with field definitions at scoping.

ContactDB is a purchased list database and does not store engagement history, call logs, or email activity. No activity data exists in the source to migrate. Any historical outreach data lives in the customer's email client, sales engagement tool, or call logging system and must be sourced from those systems separately if needed in Salesforce.

ContactDB does not implement a pipeline or deal-tracking model. There are no pipeline stages, deal values, or deal-stage histories to migrate. If the customer requires Opportunity records in Salesforce, they create these post-migration as part of their Salesforce sales process setup.

ContactDB is a data product without an internal user system. Contacts are not assigned to sales reps within ContactDB. Salesforce User provisioning is outside migration scope; the customer's admin creates Salesforce User records for the team before or after migration. We provide a rep roster template so that Account and Contact ownership can be assigned during or after the migration.

ContactDB does not store document attachments against contact records. No attachment migration applies.

ContactDB does not store notes or tasks against contact records. Any internal notes the customer's team has maintained in spreadsheets or other tools must be provided as a supplemental CSV with a field mapping specification for import into Salesforce Note or Task objects.