Migrate from Encharge to Odoo CRM

Encharge People records map 1:1 to Odoo Contacts. Standard fields (email, first name, last name, phone, address) map directly. Custom person properties migrate as custom fields on the Contact model (ir.model.fields with column1 defined). Encharge's Places (location data) map to the Contact's street, city, state, zip, country fields. We set the industry, customer_rank, and supplier_rank defaults during import based on the customer's business type.

Encharge Accounts map to Odoo Companies (res.partner with company_type = 'company'). The Account's domain, annual revenue, employee count, and industry map to the corresponding Company fields. We link each Encharge Person's Account to an Odoo Company record via partner_id on the Contact, establishing the parent-company hierarchy that Odoo's Contact model requires for address inheritance.

Encharge Tags are flat string labels applied to People. We export the full tag assignment list per contact and import into Odoo's res.partner.category model. Tags in Odoo are attached to Contacts and Companies via a many2many field (category_id), preserving the per-contact tag history. We handle duplicate tag names by normalizing case and stripping whitespace before import.

Encharge Custom Objects are customer-defined schemas (Deals, Orders, Invoices, or domain-specific entities). We map each Custom Object to a new Odoo model (ir.model) with the same API name plus _custom suffix, then create the corresponding database table (ir.model.data) and fields. Custom relationship fields between Encharge objects map to Odoo many2one or many2many fields. Tier and edition constraints apply: Odoo Community supports custom models but the Studio UI for field configuration requires Enterprise. We include a Studio-ready field mapping document if the customer has Enterprise.

Encharge Flows cannot be exported via API. We document the complete Flow tree during scoping: every trigger (event type, filter condition), each conditional branch (operator, value), wait-step durations, and downstream actions (email send, tag apply, field update). This becomes a written rebuild checklist for the customer's Odoo admin. Odoo Automated Actions (ir.actions.server) handle trigger-on-record-create/update, time-based scheduling, and website event models. The customer or an Odoo partner rebuilds the automations post-migration.

Encharge Segments are dynamic groups of People defined by filter rules (behavioral and firmographic criteria). We export the segment definition including each filter condition, operator, and value, then map to Odoo's domain filter syntax (field operator value tuples). Segments without a direct domain equivalent (for example, behavioral events like 'opened email in last 30 days') are flagged for manual reconstruction using Odoo scheduled actions and computed fields if Enterprise is available.

Encharge Activities record behavioral events (email opens, page views, custom events). We map these to Odoo mail.activity records linked to the target Contact or Company. Event names normalize to Odoo activity type values (call, meeting, email, tentative, any_other_type). Timestamps preserve exactly. Custom event properties map to mail.message records attached to the activity for full behavioral context.

Encharge Email Templates store HTML with subject lines, sender names, and metadata. We export templates as HTML files preserving inline styles and image references, then import into Odoo's mail.template model. Merge fields (like {{first_name}}) are documented and mapped to Odoo's {{object.field}} syntax so the customer's admin can update template content post-migration. Template-to-segment associations are not preserved through import; we deliver a mapping table for manual reattachment.

Encharge Campaigns group emails and automation steps. We map campaign names and status to Odoo utm.campaign records (part of Odoo's marketing attribution module). The campaign-Flow association does not migrate because Flows are not exported. We deliver a written inventory of which campaigns used which Flows so the admin can reattach once automations are rebuilt in Odoo.

Encharge Users are assigned as Flow owners and sending identities. We map Users to Odoo res.users by email match. Any Encharge User without a matching Odoo User is held in a reconciliation queue for the customer's admin to provision before record import begins, since OwnerId is a required reference on many Odoo record types.

Encharge Forms capture new People via embed codes or webhook URLs. We export form field definitions and webhook configurations, then deliver a mapping document for the customer to recreate forms in Odoo Website (or a custom form model). Form URLs and embed codes do not migrate; the customer updates all published form endpoints post-migration.

Encharge Places store structured location data associated with People or Accounts. We map Places to Odoo's address field group (street, street2, city, state_id, zip, country_id) on the Contact or Company record. Structured location data (latitude, longitude, geocoding) does not have a native Odoo standard field and is flagged for custom field creation if the customer's workflow depends on location data.