Migrate from Marketing 360 to Odoo CRM

Marketing 360's flat Contact with embedded organization fields (organizationId, contactName) splits into two Odoo res.partner records at migration time. The primary contact person becomes one res.partner with partner_latitude/longitude and category_id (tags). The associated organization becomes a separate res.partner with is_company=True and the primary contact linked via child_id. We use the Marketing 360 organizationId as the dedupe key for Company creation and apply a mapping table to preserve the relationship back to the Contact record.

Marketing 360 email maps directly to res.partner.email and serves as the primary dedupe key for Contact records during import. We validate email format before insert and flag any malformed addresses for customer review.

Marketing 360 phone maps to res.partner.phone; if the source stores separate mobile numbers, these map to res.partner.mobile. We strip non-numeric characters during transform to comply with Odoo's phone normalization if the customer has phone formatting installed.

Marketing 360 custom fields (exposed via the Custom Fields API as id-value pairs per contact) map to Odoo custom fields. In Odoo Community, custom fields require the studio module or manual ir.model.fields creation; in Enterprise, they are configurable via Settings > Custom Fields. We pre-create the destination custom field schema before migration, preserving field type (char, selection, integer, date) and any picklist options used in Marketing 360 Status or Type properties.

Marketing 360 contact tag arrays (id and tag name) migrate to Odoo res.partner.category_id, which is a many2many_tags field. We extract the full tag taxonomy from the source API, create equivalent Tags in Odoo (or map to existing tags if the customer has already set them up), and apply tag memberships per contact. Tags used for segmentation logic carry over as category entries for reporting in Odoo.

Marketing 360 assignees (stored as username, fullName, email nested under contact records) map to Odoo res.users by email match. We resolve each assignee reference during migration and set res.partner.user_id on the migrated Contact so that the sales rep is the responsible user in Odoo. Any Marketing 360 assignee without a matching Odoo user is placed in a reconciliation queue for the customer's admin to provision before Contact import resumes.

Marketing 360 Status and Type are arbitrary name/id pairs without a standard Odoo equivalent. We extract the full taxonomy during discovery and map Status values to a custom selection field on res.partner (e.g., m360_status__c) or to crm.lead.tag depending on whether the customer uses Odoo's Lead kanban for early-stage prospects. The mapping table is delivered as part of the migration spec for the customer's admin to finalize before production import.

Marketing 360 Deals map to Odoo crm.lead records in the Opportunities kanban view. The HubSpot-to-Salesforce-style pipeline-to-kanban split does not apply here because Odoo uses a single crm.lead model with a team kanban view; multiple pipelines are represented as Odoo CRM Teams (crm.team) with separate stage sequences per team. We extract the Marketing 360 pipeline and stage assignments and configure matching Odoo stages per crm.team before import.

Marketing 360 pipeline and stage assignments map to Odoo crm.team (one per Marketing 360 pipeline) and crm.stage (one stage set per team). Stage probability percentages map to Odoo stage probability values. The customer configures team-stage associations in Odoo before migration; we provide the mapping table with the number of stages, stage names, and probability values sourced from Marketing 360.

UXi XML export contains Posts, Pages, and Testimonials as structured content. Odoo CRM does not include a CMS, so content is flagged for migration to the customer's chosen destination CMS (WordPress, Webflow, or Odoo Website if selected). Testimonials migrate as res.partner comments or as a custom testimonials model if the customer licenses Odoo Studio. We extract content text, categories, tags, and media URLs from the XML and deliver them as structured CSV for the customer's CMS admin to import.

The UXi XML export includes media references but not root-domain hosted assets. We download accessible media files during export, re-upload them to the Odoo attachments table (ir.attachment linked to res.partner) if the media is CRM-relevant (e.g., contact photos, company logos), and flag the remainder as out-of-scope for the website rebuild workstream. Any inaccessible media is documented in a gap report.

Marketing 360 subscriber data and segment membership extract via the CRM contact export. Email opt-in and opt-out preferences migrate to res.partner.opt_out (boolean) and a custom m360_list_segmentation__c field for audit. We do not migrate email marketing sequences or automated journey triggers; those require reconfiguration in the customer's chosen email marketing platform post-migration.

Marketing 360 automation journeys and automation logic are stored in the platform's application layer and are not accessible via the public API. Workflow definitions, trigger conditions, time delays, and subscriber entry points do not migrate. We document all active Marketing 360 journeys during discovery (name, trigger type, steps, and estimated equivalent Odoo CRM automation) in a written rebuild checklist delivered as part of the migration handoff package.

Marketing 360 bundles its own payment processing layer with card-present and card-not-present fee structures, hardware costs, chargeback fees, and payout fees. These configuration records live in the Marketing 360 payments module, not in the CRM data model. They do not appear in the API export and cannot be migrated. We separate payment processor reconfiguration as a distinct workstream in the migration plan and flag the fee differential for the customer's finance team to compare against Odoo's integrated payment providers (Stripe, PayPal, Buckaroo) if Odoo Accounting or Point of Sale is also in scope.