Migrate from KulaHub to Odoo CRM

KulaHub stores all business entities as Contact records with company name, domain, address, and industry embedded as contact fields. We extract company-level fields (company_name, website, industry, company phone) into Odoo res.partner records with partner_type = 'company', then create a separate individual Contact (partner_type = 'person') linked to the Company via parent_id. The original KulaHub contact ID is preserved in a custom field x_kulahub_id for deduplication and audit. Any contacts that have no embedded company data become individual Contacts without a parent Company.

KulaHub contacts with no prior purchase history or informal stage indicators (captured in tags or notes) may represent unqualified prospects that map to Odoo crm.lead. We apply a split rule during scoping: contacts tagged 'lead', 'prospect', or 'unqualified' map to Odoo Lead. Contacts with active tasks, recent engagement, or formal company affiliation map to Odoo Contact attached to a Company. The customer defines the split rule based on their KulaHub tagging convention. The original KulaHub contact name and email migrate to Lead name and email_from.

KulaHub call activities (type=CALL) with disposition, duration, and timestamp migrate to Odoo Mail Message records attached to the corresponding Lead or Contact (res.partner). Odoo does not have a native Task object equivalent for call logging outside of Project tasks; we use the Note/comment channel (mail.message with message_type='notification') to preserve the call record in the chatter timeline of the parent record, preserving the timestamp and disposition text.

KulaHub email activity records migrate to Odoo Mail Message records on the corresponding Lead or Contact. The email body, subject, and timestamp are preserved. KulaHub's GDPR unsubscribe flag migrates to a custom field x_email_opt_out on the Odoo partner record so that Odoo's mass mailing features respect existing suppression lists. Email attachments migrate as IrAttachment records linked to the mail.message.

KulaHub meeting activities map to Odoo calendar.event records. Start datetime, end datetime, location, and attendee list (KulaHub contact references) migrate to the corresponding Odoo fields. Attendees are resolved to Odoo res.partner records via email match and linked via calendar.event.res.partner records. If a KulaHub meeting has no matching Odoo Contact or Lead, the event is attached to the nearest parent Company record.

KulaHub tasks with an assigned user and due date migrate to Odoo project.task records within a default 'CRM' project. Tasks with no assigned user or no due date migrate as Note records (mail.message) on the parent Contact or Lead. KulaHub task priority and completion status map to Odoo task priority and stage values. Task assignment resolves KulaHub owner email to Odoo res.users via email match.

KulaHub system event logs and informal notes attached to contacts migrate to Odoo Mail Message records on the corresponding Lead or Contact. These are logged as internal notes (message_type='notification', subtype='note') so they appear in the chatter timeline without triggering email notifications to the contact. Timestamps are preserved from the KulaHub activity date.

KulaHub email campaigns, templates, and tracking data (opens, clicks, unsubscribes) migrate to Odoo Marketing module's utm.campaign record and associated mail.mass_mailing records. The campaign name, description, and GDPR unsubscribe list migrate as utm.campaign metadata and mass mailing suppression records. KulaHub email templates migrate as mail.template records. Marketing automation workflows (KulaHub sequences, drip logic) do not migrate; we document each automation as a written step-list for the customer's Odoo admin to rebuild using Odoo's Marketing automation or Studio tools.

KulaHub documents attached to contacts are linked via a foreign-key relationship. We extract each document blob (stored as base64 or URL reference in KulaHub) and create Odoo IrAttachment records with res_model='res.partner' and res_id pointing to the migrated Contact. Document name and file type (MIME) are preserved. We maintain the original KulaHub attachment ID in x_kulahub_attachment_id for audit.

KulaHub users appear in activity logs and task assignments. We export the full user list first (name, email, active status) and create matching Odoo res.users records via the Odoo XML-RPC API before any records that reference users are loaded. KulaHub user email is the dedupe key. Users without a matching Odoo instance are held in a reconciliation queue for the customer's admin to provision before record import resumes. Archived KulaHub users map to inactive Odoo users to preserve historical assignment.

KulaHub reports (All Contacts export, activity reports, CRM activity logs) are extracted as CSV and presented to the customer as a supplemental dataset. Odoo has a native Reporting module (crm_analysis) and Spreadsheet app, but the report layouts and metrics from KulaHub do not transfer directly. We deliver the KulaHub report data as a structured CSV and a written mapping to Odoo report fields so the customer's admin can rebuild reports in Odoo Reporting or connect the data to an external BI tool.

KulaHub website enquiry forms are linked to contact records but the form-field schema is not publicly documented. We request a sample export of form submission data during discovery and map key-value pairs to custom fields (x_field_name) on the Odoo res.partner or crm.lead model. Any unmapped fields are held in a staging table and presented to the customer for manual mapping before the production run. KulaHub form-to-contact associations migrate as Note records on the parent Contact.

KulaHub stores email unsubscribe states and GDPR preference flags per contact but the data format is not documented. We export the preference flags as a custom field x_email_opt_out (boolean) and x_gdpr_consent_date (date) on the Odoo res.partner record, alongside the standard Odoo mailing.contact.opt_out_ids linktable. This ensures existing suppression lists are respected by Odoo's mass mailing features and can be re-exported if the customer later moves to another platform.