Migrate from Taguchi to Odoo CRM

Taguchi Subscribers map to Odoo CRM Contacts by default. Subscribers with Organizations map to Contacts linked to the corresponding Odoo Company. Subscribers without Organizations map to Contacts with no Company link unless the customer elects to create placeholder Company records. The decision between Contact and Lead is made during discovery based on the subscriber lifecycle stage and the customer's Odoo use case. We preserve the original Taguchi subscriber status (active, bounced, unsubscribed) as Odoo Contact properties and set HasOptedOutOfEmail = True for unsubscribed and bounced records.

Taguchi key-value custom fields map to Odoo res.partner custom fields (ir.model.fields with technical name in the ir.model.fields table). We preserve the original field key as the field name with a taguchi_ prefix to avoid collisions. Field values migrate as typed data (text, date, selection, float, integer). If a Taguchi field was deleted from the UI but values remain on subscriber records, we reconstruct it as an archived custom field with a deprecation flag so data integrity is preserved without cluttering the active Odoo schema.

Taguchi Organizations map to Odoo Company records (res.partner with is_company=True). Organization name becomes Company name, domain becomes Website, and address fields map to Odoo's contact address fields. We create Companies first in the migration sequence so that the Contact-Company lookup is satisfied when Contact records are imported. If Taguchi Organizations have no subscribers attached, they are included but flagged for customer review.

Taguchi List memberships are append-only associations from Subscribers to Lists. We extract the full list of list names during discovery and map them as tags on the Odoo Contact record. The customer chooses whether list names become Odoo tags, custom Contact properties, or both. Because Taguchi lists cannot be deleted post-import, the tag inventory is fixed at discovery time. Odoo's tag editor supports add and remove operations post-migration, giving teams the mutability Taguchi lacks.

Taguchi Clusters identify the subscriber segment a contact is most strongly associated with, similar to a primary segment flag. We map Clusters as tags on the Contact record or as a single-select custom field, depending on whether the customer uses clusters as exclusive groupings or overlapping labels. The cluster name becomes the tag or field value. We advise during scoping whether a tag model or field model is more appropriate given the customer's segmentation workflow.

Taguchi logs per-subscriber behavioral events (opens, clicks, custom events) used to drive automation triggers. These have no native Odoo CRM equivalent. We extract the full activity history and write it as chitchat.message records on the Contact timeline, with the event type as subject (e.g., 'Taguchi Event: email_open', 'Taguchi Event: custom_event:webinar_registrant'), a timestamp from the original Taguchi record, and event metadata stored in the message body. Activity records are written after Contacts to ensure the parent Contact ID is resolved.

Taguchi Campaigns link subscribers and activities but do not map cleanly to a standalone Odoo CRM object. We extract campaign name, send date, recipient count, and open/click rates as campaign metadata and write them as notes or custom fields on the relevant Contact records. If the customer uses Odoo CRM's native campaign module, we map to crm.campaign with the campaign name, date, and audience size preserved. Content and workflow logic do not migrate.

Taguchi Broadcasts are one-time email sends to subscriber segments. We preserve broadcast metadata (name, send date, recipient count, open rate, click rate) as a linked Note or campaign entry on each Contact record that received the send. Broadcast content and scheduling logic do not migrate because Odoo CRM has no native broadcast send capability at the contact record level.

Taguchi SMS send history migrates as message records on the Odoo Contact. We extract send date, recipient phone number, SMS status (delivered, failed, undelivered), and content snippet, storing these as a chitchat.message or custom note on the Contact. Phone number fields must be validated and present on the Taguchi Subscriber record; records without valid phone numbers are flagged and quarantined for the customer's review before import.

Taguchi bounced subscriber flags are permanent and irreversible without Taguchi Support. We extract the bounced and suppressed status for each Subscriber and write it to Odoo Contact's opt_out field and a custom field taguchi_bounce_status__c so that migrated contacts are suppressed from email sends on the new platform immediately. This prevents the customer's Odoo-managed sending domain from landing on blocklists from the first send.

Taguchi Subscribers can have an assigned owner (typically a marketing user). We extract owner references and map them by email to Odoo res.users. Any owner without a matching Odoo User is held in a reconciliation queue for the customer's admin to provision before record import resumes. Unassigned subscribers default to the admin user or a designated migration placeholder.

Taguchi automation workflows and journey logic are rule-driven configurations that do not map to Odoo CRM. We do not migrate automation workflows. We extract the workflow definitions during discovery (triggers, conditions, actions, delays) and deliver a written inventory with recommended Odoo automated action equivalents for the customer's admin or Odoo partner to rebuild post-migration.