Migrate from NEON-dX to Odoo CRM

NEON-dX customer profiles contain demographic fields, behavioral signals, and digital footprint data. We map standard profile fields (name, email, phone, address, company affiliation) to Odoo Contact fields. Any custom profile attributes stored as formula fields or lookup relationships are discovered via NEON-dX API enumeration and mapped to Odoo custom contact fields. The original NEON-dX profile ID is preserved in a custom field x_neon_profile_id for audit and reconciliation. Behavioral signals and digital footprint metadata that have no Odoo equivalent are mapped to custom Text or Char fields for manual review post-migration.

NEON-dX profiles for contacts in early lifecycle stages (subscriber, visitor, lead) map to Odoo Lead records. We use NEON-dX's lifecycle stage field to determine whether a profile belongs in Lead or Contact on the Odoo side. Lead records carry the original NEON-dX lifecycle stage in a custom field x_neon_lifecycle_stage for reference during the customer's review period.

NEON-dX behavioral segments are defined by rule criteria evaluating customer event streams. We transfer the segment definition rules as a written specification document and create Odoo Tags for each segment name. For complex segments with multiple criteria, we create a custom Many2many field on Contact (segment_ids) and populate with the segment memberships as they existed at migration time, noting that the Odoo system will re-evaluate membership based on available event data in the new environment.

NEON-dX campaigns and their associated offer content map to Odoo Opportunity records. Campaign name becomes the Opportunity name, campaign status maps to a custom picklist field, and offer metadata (offer type, discount percentage, terms) is preserved in custom Opportunity fields. The Odoo CRM Pipeline and Stage model replaces NEON-dX's journey stage assignments, requiring the customer to define which pipeline each migrated campaign belongs to.

NEON-dX offer items map to Odoo Product records. Offer name becomes the product name, offer type (discount, bundled, loyalty) maps to a custom product field, and pricing information maps to Odoo's list_price field. Bundle offers require the customer to decide whether to create a single product with components or multiple linked products.

Predictive scores are model-generated outputs that depend on NEON-dX's proprietary ML pipeline and training data. These are not transferable as static values. We create custom numeric fields on the Odoo Contact record (x_neon_churn_score, x_neon_ltv_score, x_neon_propensity_score) and populate them with the last-known values from NEON-dX, flagging them as historical reference only. The customer should expect a re-warming period before new predictive scores from any Odoo-native or third-party analytics tool become actionable.

NEON-dX multi-step journey orchestrations with branching logic and wait conditions cannot be migrated as code. We deliver a written specification document for each journey that describes the trigger, step sequence, branch conditions, channel assignments, and wait durations. The customer's admin rebuilds these in Odoo using the native activity model, Odoo Marketing (if licensed), or a third-party marketing automation tool. The original journey name and NEON-dX journey ID are preserved in the specification document.

Channel configurations (SMS gateways, email sender IPs, push credentials, digital channel API tokens) are environment-scoped in NEON-dX and cannot be exported as valid credentials. We document the channel type, provider name, and configuration schema for each channel during discovery. The customer must re-authenticate each channel in Odoo or the third-party marketing automation tool used as the channel replacement. We provide a re-authentication checklist organized by channel type.

NEON-dX custom objects with standard field types map to Odoo custom models. We discover the custom object schema via NEON-dX API enumeration at the start of the engagement, generate the destination Odoo model with matching field types, and map records accordingly. Any lookup fields in NEON-dX custom objects that reference other custom objects require a dependency graph to be built before import sequencing can begin.

NEON-dX formula fields carry business logic that is evaluated at read time. We document the formula expression for each formula field and note whether Odoo's computed field mechanism (fields.function or fields.Char with compute) can replicate the logic. Where replication is feasible, we configure the Odoo computed field; where it is not, we migrate the last computed value as a static field and flag it for manual review.

NEON-dX pre-built dashboards and custom reports reference platform-native metric definitions and anomaly detection logic. We migrate the report structure and column configurations as a written specification document. Destination metric data populates after migration completion. Odoo uses its own reporting model (pivot, graph, and list views) and does not natively replicate NEON-dX's anomaly detection; the customer may need a BI tool or Odoo Enterprise reporting add-on for equivalent analytics.

Consent management, data retention policies, and governance frameworks are platform-native constructs in NEON-dX. We map GDPR and CCPA opt-out records to Odoo's privacy opt-out fields on Contact (opt_out). Data retention policies are documented as a written specification for the customer's admin to configure in Odoo's privacy settings or a dedicated consent management tool.