Migrate from HoneyBook to Salesforce Sales Cloud

HoneyBook Clients are person-centric records containing both company and individual data. We split each Client into a Salesforce Account (using the company name field if present) and a Salesforce Contact (using the client name and email). If no company name exists on the HoneyBook Client, the Contact is created as an Individual Account (a Salesforce Person Account or an Account with no Website). The original HoneyBook Client ID is preserved in a custom field hb_client_id__c on both Account and Contact for reconciliation.

HoneyBook's native CSV export from Clients > Contacts includes name, email, phone, address, notes, and creation date. We ingest this CSV directly and map each row to Salesforce Contact. Email becomes Contact.Email, phone becomes Contact.Phone, address fields map to Contact.MailingAddress components. The hb_original_createdate__c custom field preserves the HoneyBook creation timestamp.

HoneyBook Projects are the primary work container, linking Clients to pipeline stages, custom fields, files, and invoices. We map Projects to Salesforce Opportunity when the project maps to a sales deal (Proposal Sent, Booked stages). For Projects representing ongoing retainer work or service delivery without a clear close date, we create a custom object Project__c with a lookup to Account and the original pipeline stage preserved in hb_pipeline_stage__c. The customer chooses the strategy during scoping based on their reporting needs.

HoneyBook pipelines have configurable stages (Inquiry, Follow Up, Proposal Sent, Booked, etc.) with stage-move timestamps. We create a Salesforce Sales Process with corresponding StageName values for each HoneyBook pipeline stage. Stage probabilities migrate from HoneyBook (if configured) to Salesforce StageProbability. Closed dates and stage-move history migrate as Salesforce OpportunityFieldHistory or a custom stage_timeline__c object.

HoneyBook invoices include line items, payment status, amounts, and client associations. We extract invoice records via CSV export or scraped invoice list views, then map to a custom Invoice__c object with fields: hb_invoice_id__c, Invoice_Number__c, Amount__c, Status__c (Open, Paid, Overdue, Void), Due_Date__c, and a lookup to Account and Contact. Open invoices preserve their original HoneyBook status for the customer's accounting team to reconcile against the destination accounting system.

HoneyBook Contracts are template-based documents with client associations and e-signature status. We export contract metadata (client, template name, status, date) to a custom Contract__c object with hb_contract_id__c, Template_Name__c, Status__c, Signed_Date__c, and a lookup to Account. The contract PDF content migrates as a Salesforce ContentDocument attached via ContentDocumentLink to the Account or Contact record.

HoneyBook Proposals combine scope, pricing, and terms tied to Projects. We map proposals to Salesforce Quote (available from Professional tier) if the customer uses Salesforce quoting, or to a custom Proposal__c object with hb_proposal_id__c, Proposal_Name__c, Amount__c, Status__c, and a lookup to Account and Opportunity. Proposal attachments migrate as ContentDocument linked to the parent record.

HoneyBook Payment records include amount, method, status, and processing date. We extract payment history via dashboard export or scraped views, then map to a custom Payment__c object with hb_payment_id__c, Amount__c, Payment_Method__c (Credit Card, Bank Transfer), Status__c (Completed, Pending, Refunded), Processing_Date__c, and a lookup to Account, Contact, and Invoice__c. We preserve the original HoneyBook timestamp rather than the settlement date for bank transfers that take 7-8 days to clear.

HoneyBook distinguishes collaborators (external, limited project access) from team members (internal). We export team member records including roles and permissions and map active team members to Salesforce User records. Collaborators are mapped to Salesforce Contact records with a custom hb_collaborator__c flag. Owner resolution by email match; any HoneyBook team member without a matching Salesforce User goes to a reconciliation queue for admin provisioning.

HoneyBook client questionnaires are linked to Projects and serve as intake forms. We export questionnaire structure (questions, types, order) and response history as structured data. The questionnaire template becomes a Questionnaire__c custom object; each client response becomes a Questionnaire_Response__c custom object with a lookup to Account and Project__c. Question-answer pairs migrate as JSON or as repeating custom fields on the response record depending on complexity.

HoneyBook supports custom fields on Contacts and Projects. We identify all active custom fields during discovery, export their values alongside the parent record, and create matching custom fields on the Salesforce Contact object. Field types are mapped: text fields to Text(255), date fields to Date, number fields to Number, checkbox fields to Checkbox, and dropdown fields to Picklist. Custom field API names carry a hb_ prefix to avoid collision with existing Salesforce fields.

HoneyBook Project custom fields migrate to the destination object selected for Project migration (Opportunity or Project__c). If the project maps to Salesforce Opportunity, custom fields become custom Opportunity fields. If the project maps to a custom Project__c object, custom fields are added to that object. Field type mapping follows the same rules as Contact custom fields.

HoneyBook automations (email triggers, questionnaire flows, booking confirmations) are rule-based and stored server-side with no export mechanism. We do not migrate automations as code. We deliver a written inventory of every active HoneyBook automation with its trigger, conditions, actions, and a recommended Salesforce Flow equivalent. The customer's admin or a Salesforce partner rebuilds them post-migration.

HoneyBook stores files in a library (images, PDFs, brand assets) and uses templates for contracts and proposals. File URLs in HoneyBook are session-bound and not publicly accessible. We handle file migration by downloading accessible files during an authenticated export session, uploading them to Salesforce as ContentVersion records, and linking them via ContentDocumentLink to the related Account, Contact, or Opportunity. Files that are inaccessible via URL are flagged in the handoff document for manual transfer.