Migrate from cMercury to Odoo CRM

cMercury Subscribers map to Odoo CRM Contacts. The cMercury email address becomes the Contact email field and serves as the dedupe key. Subscription status (active, unsubscribed, bounced) maps to Odoo CRM's opt-out and blacklist fields: active subscribers remain in the normal contact list, unsubscribed contacts are flagged via the mass_mailing Unsubscribe field, and bounced contacts are flagged in the blacklist or an internal mail.mass_mailing.contact state field. Engagement score migrates as a custom float field on Contact (cm_engagement_score__c) if the customer requests it during scoping; otherwise it is preserved as a CSV export for post-migration manual entry. The cMercury Verify badge (valid, invalid, risky, catch-all) migrates as a selection field on the Contact record (cm_verification_status__c) so the new system can honour quality indicators.

cMercury Segments are dynamic filter-based audience groups (engagement score, source, custom field conditions). Odoo CRM does not have a native dynamic segment engine equivalent to cMercury's rule-based segmentation. We translate cMercury's segment membership rules into Odoo CRM Tags, assigning each subscriber the relevant tag(s) based on the last-known segment membership. For segments built on static criteria (tags, source), this is a direct tag assignment. For segments built on engagement thresholds or date ranges, we note the rule in the segment inventory document for the admin to rebuild using Odoo's Domain filter on a saved Filter view.

cMercury Campaign records include subject line, send date, aggregate open rate, click rate, bounce rate, and unsubscribe count. Odoo CRM has no native Campaign object in the base CRM app. We merge campaign metadata into a Note record attached to each Contact who received the campaign, or into a single Note per campaign for reference. Aggregate campaign performance metrics (total opens, clicks, bounces) are stored as a Note on the CRM's root document (or a dedicated Project in the Project app if Odoo Project is enabled) so the customer retains historical performance data. The customer can also opt to map campaign send history to Opportunities if Odoo CRM's native Activity and marketing tracking are used alongside Odoo Marketing, which is outside the base CRM scope.

cMercury custom profile fields (text, number, date, dropdown) map directly to Odoo CRM custom fields on the Contact model. We create fields of the matching type during schema design, before any data import. Dropdown fields from cMercury become Odoo Selection fields with the same option values. Date fields map to Odoo Date fields. Numeric fields map to Float or Integer fields depending on the cMercury data type. Fields are deployed into the Odoo Sandbox first for validation before production import.

cMercury flat tags on subscribers map 1:1 to Odoo CRM Tags. We export all subscriber tag assignments and bulk-apply them to the corresponding Contacts during import using Odoo's mail.composer.mixin (tag write API). Tag names are preserved exactly; tag count is maintained as a count of unique tags per Contact in a custom field if the customer requires it.

cMercury Verify stores per-email validation status (valid, invalid, risky, catch-all) as a badge on each subscriber record. We map this to a selection field (cm_verification_status) on the Odoo CRM Contact record, with values: valid, invalid, risky, catch-all, and unknown. This preserves the quality signal for the customer's deliverability team to reference without re-running verification on the imported list. If the customer has an Odoo email marketing integration (e.g., Odoo Email Marketing app), the verification field can be used to suppress invalid addresses from future sends.

cMercury tracks per-subscriber engagement scores as numeric values derived from open, click, and reply rates. We map engagement scores to a custom float field (cm_engagement_score) on the Contact record. If Odoo CRM has a scoring system enabled (available via the CRM Score app or a custom field), the score can be used to drive Odoo's lead prioritisation. Note that Odoo's native scoring engine uses different calculation logic; we preserve the original cMercury numeric score as a static field rather than recalculating it in Odoo's model.

Images and files stored in the cMercury Asset Library are downloaded as a batch during extraction, preserving file names and folder organisation. We upload them to Odoo CRM's IrAttachment records, linked to the relevant Contact or saved as general Attachments in Odoo's document management (if the Documents app is enabled). Folder hierarchy is approximated using Odoo's tags on attachments or subfolders in the Documents app, where supported. Plain image files (JPEG, PNG, GIF) are uploaded to the Odoo attachment store; HTML template files are stored as Attachments for manual reassembly in Odoo's email composer.

cMercury templates use a proprietary block structure for the drag-and-drop editor. We extract the HTML source and image assets from each template and store them as Attachments in Odoo CRM. The customer can then manually reassemble the template using Odoo's Email Template editor or paste the HTML into a custom email template. We flag which templates had complex nested blocks (e.g., conditional content, dynamic personalisation) in the inventory document so the admin knows which templates require extra reassembly effort. Template metadata (name, subject line, creation date) is preserved as a Note in the attachment description.

cMercury Automations are named workflow sequences with triggers, delays, and actions. We document the full automation tree for each active automation during discovery: trigger type, filter conditions, action sequence, and any conditional branching. We deliver this as a written automation inventory with trigger mapping recommendations for Odoo CRM Action Rules or Studio automations. The customer or an Odoo partner rebuilds the automations post-migration. No automation data migrates automatically.

cMercury sending domains are configured with DKIM, SPF, and DMARC records pointing to cMercury's infrastructure. Odoo Online uses Odoo's own sending infrastructure; Odoo.sh and On-Premise allow custom sending domains with customer-managed DNS. We provide a DNS checklist at cutover that specifies the TXT, DKIM, and SPF records required for each domain in the Odoo environment. The customer configures DNS in their domain registrar. We do not manage DNS changes. Sending domain ownership cannot be transferred between platforms.

cMercury Owner records (users who own subscribers and campaigns) map to Odoo CRM User records. We resolve cMercury owners by email address match against the destination Odoo User table. Any cMercury Owner without a matching Odoo User is held in a reconciliation queue for the customer's admin to provision before record import resumes. Inactive cMercury owners are mapped to inactive Odoo Users so that ownership attribution is preserved even if the user is no longer active.