Migrate from HoneyBook to Odoo CRM

HoneyBook Contacts export as a CSV via Clients > Contacts and include name, email, phone, address, notes, and creation date. We map each row to Odoo res.partner, setting is_company = False and using the contact_id as an external identifier for future sync. If the CSV contains both individual clients and company records, we split them by the presence of a company_name field and set is_company = True for the latter group. Phone numbers are stored as char fields in Odoo, so we preserve the original format without reformatting to avoid breaking downstream integrations.

HoneyBook Projects are the primary business record containing inquiry details, pipeline stage, custom fields, files, and associated contacts. Odoo has no native project object, so we reconstruct project metadata as custom fields on crm.lead (Opportunity): hb_project_id (char), hb_pipeline_stage (char), hb_created_date (datetime), hb_inquiry_type (char), and hb_notes (text). The project pipeline stage migrates to crm_stage via the stage name match, and the associated client contact resolves to res.partner.id for the Opportunity's partner_id. Projects without an associated contact are held in a reconciliation queue.

HoneyBook Invoices include line items, payment status, amounts, and client associations. We extract invoice records via the dashboard export or by scraping the invoice list view, then map to Odoo account.move with move_type = 'out_invoice'. Open invoices retain payment_status = 'posted' and are reconciled against the mapped res.partner. Historical invoices are loaded as out_invoice with payment_status = 'posted' and reconciled against the partner's account move lines. Odoo's account_id must be resolved to the customer's account.move record.

HoneyBook Contracts are template-based documents with client associations and signature status. We extract contract metadata (client, template name, status, date) and map the metadata to a custom field contract_status__c on the related crm.lead. The contract PDF itself cannot be downloaded via API because HoneyBook file URLs are session-bound; we attempt download during the authenticated export session and attach the resulting file to the Opportunity record using Odoo's ir.attachment model. Any undownloadable files are flagged in the handoff document.

HoneyBook Proposals are project-level documents combining scope, pricing, and terms. We extract proposal records and map scope and pricing terms to custom fields on the crm.lead (hb_proposal_scope__c, hb_proposal_value__c). The proposal PDF, if accessible during the authenticated session, attaches to the Opportunity via ir.attachment. Proposals with no corresponding project record are loaded as standalone Opportunities with proposal_type__c flagged.

HoneyBook pipeline stages (Inquiry, Follow Up, Proposal Sent, Booked, Completed, Declined) map to Odoo crm_stage records by name matching. Each stage gets a probability percentage matching HoneyBook's close-rate data. We configure stages under the relevant crm_team so that Opportunities are scoped to the correct team pipeline. Custom stage names in HoneyBook are preserved verbatim and created as new crm_stage records if no match exists. The migration assigns stage_ids after stage creation to maintain ordering.

HoneyBook Payment records include amount, method, status, and processing date. We extract payment history via the dashboard export and map completed payments to Odoo account.move.line entries reconciled against the corresponding invoice account.move. 'Payment Attempted' statuses (bank transfers taking 7-8 days) are preserved with their original HoneyBook timestamp as the payment date to avoid misrepresenting a pending payment as completed. Refunded payments are loaded as credit account.move.line entries.

HoneyBook distinguishes between collaborators (external, limited project access) and team members (internal). We export team member records including roles and permissions, then map to Odoo res.users by email match. Collaborators without a corresponding Odoo user are flagged for the admin to provision as portal users if external access is required. The migration holds any owner_id references on crm.lead until user provisioning is confirmed.

HoneyBook supports custom fields on contacts and projects. We identify all active custom fields during discovery, capture their types (text, number, date, checkbox, dropdown), and create matching custom fields on the Odoo res.partner or crm.lead model before migration using ir.model.fields. Dropdown-style custom fields map to Odoo selection fields; checkbox fields map to boolean fields. All custom field values migrate as column data alongside the parent record.

Client questionnaires are linked to projects in HoneyBook and serve as intake forms. We export questionnaire structure and response history as structured key-value data, mapping each question and answer pair to a custom field on crm.lead (e.g., hb_intake_budget__c, hb_intake_timeline__c). Long-form responses or multi-question forms are stored as a mail.message with body = JSON of the full response, linked to the Opportunity via res_id and model = 'crm.lead'.

HoneyBook stores files in a library (images, PDFs, brand assets) and uses templates for contracts and proposals. File URLs are session-bound and not publicly accessible. During the authenticated export session, we attempt to download available files and attach them to the corresponding res.partner (for brand assets) or crm.lead (for project files). Files that cannot be retrieved are logged with their HoneyBook URL in the handoff document for manual download.

HoneyBook Automations (email triggers, questionnaire delivery, follow-up reminders, booking confirmations) are rule-based and stored server-side with no export mechanism. These cannot be migrated programmatically. We deliver a written inventory of every active HoneyBook Automation with its trigger conditions, actions, and delay logic. The customer's Odoo admin or an Odoo partner rebuilds them using Odoo's Automated Actions (ir.cron), Studio workflows, or custom Python code. Automations are out of scope for standard migration.