Migrate from MoEngage to Odoo CRM

MoEngage Users with lifecycle_stage of subscriber, visitor, or unknown map to Odoo Lead. Users with lifecycle_stage of lead, customer, or evangelist map to Odoo Contact. We compute the split at migration time using MoEngage's user attributes and preserve the original lifecycle_stage in a custom field moe_lifecycle_stage__c on both Lead and Contact for audit. User custom attributes (up to 100 per MoEngage schema) map to Odoo Contact or Lead custom fields with type conversion applied (date fields, numeric fields, boolean flags). Device metadata (OS version, app version, push token) exports as a JSON blob in a notes field since Odoo CRM has no native device tracking model.

MoEngage allows up to 100 custom user attributes per schema. We pre-create Odoo CRM custom fields on the res.partner model before migration, mapping MoEngage attribute data types to Odoo field types (MoEngage text to char, numeric to float, boolean to boolean, date to date). MoEngage auxiliary data ingested from external sources maps alongside standard attributes. Nested object attributes (JSON stored within user records) are flattened to char fields or stored as attachment notes depending on the data shape.

MoEngage's Company data (if present as a related object on Users) maps to Odoo res.partner records with company_type set to company. The MoEngage company identifier becomes the Odoo partner reference field. Users linked to the same company in MoEngage share the same Odoo parent partner ID.

MoEngage behavioral events (page views, purchases, custom actions) map to Odoo CRM Activities (mail.activity) or Notes attached to the Contact/Lead. High-frequency events (page views, scroll events) that would create thousands of activity records are consolidated into a summary note on the Contact rather than individual activity rows. Business-critical events (purchase, signup, upgrade) map to individual mail.activity records with activity_type set to the event category. MoEngage event attributes (up to 100 per event type) are stored as activity description text or as attachment notes. Historical event timestamps are preserved as activity create_date.

MoEngage RFM and behavioral segments map to Odoo Contact Groups (res.partner.category) with the segment name preserved. Segment membership criteria (MoEngage filter logic) is documented in a written segment inventory that the Odoo admin uses to rebuild the segment logic in Odoo Studio or using a domain filter on an ir.filters record. Segments containing more than 50,000 users are split into multiple Odoo groups or exported as CSV static lists. We do not migrate segment logic as executable code.

MoEngage campaigns (email, SMS, push, WhatsApp) do not migrate as active automations. We document every MoEngage campaign in a written campaign inventory with its trigger, audience segment, channel, content references, and performance metrics (open rate, click rate, conversion). Odoo Marketing campaigns (crm.campaign) are created as destination records, and the inventory document is handed to the Odoo admin for rebuild. MoEngage campaign tags that do not exist in Odoo appear as warnings in the inventory report.

MoEngage In-app campaigns cannot be migrated across workspaces or to external platforms because the content, triggers, and delivery context are tightly bound to the MoEngage SDK implementation. We document In-app campaign configurations in the written campaign inventory with SDK event name references so the Odoo admin can reproduce equivalent in-app messaging using Odoo's web push module or a third-party in-app messaging tool. Push tokens exported with User records do not carry over as active subscriptions; they require re-registration.

MoEngage email templates with personalization tokens (first_name, last_name, product_name, etc.) are documented with their token mappings in the campaign inventory. HTML email templates are exported as raw HTML files for the Odoo admin to import into Odoo's email template system (mail.template). SMS templates are documented for import into Odoo's SMS module. Push notification templates carry platform-specific tokens (MoEngage moe_* variables) that do not translate to Odoo push templates. We flag all token incompatibilities in the template inventory.

MoEngage product catalogs (item ID, name, price, attributes) map to Odoo product.template records. MoEngage catalog item attributes (custom schema fields per item) map to Odoo product.attribute and product.template.attribute.line records. Catalog ID preservation is attempted but Odoo generates new product IDs on import. We export catalog items as JSON and ingest via Odoo's product import wizard or XML-RPC API with batch chunking.

MoEngage device records containing APNs tokens (iOS) and FCM tokens (Android) are exported with device metadata (OS version, app version, token age). These tokens are invalidated when the app registers with the new Odoo push provider or third-party push service after cutover. We document the full device token inventory with platform, token hash, and last-seen date so the customer's development team can plan the silent re-registration strategy during the app update rollout. Push delivery is expected to drop to zero for 7-14 days post-migration until app re-engagement re-registers tokens.

MoEngage workspace Owners map to Odoo Users by email match. We resolve MoEngage owner_id references on User and Event records to Odoo res.users IDs at migration time. Any MoEngage Owner without a matching Odoo User is held in a reconciliation queue for the customer's Odoo admin to provision before record import resumes.

MoEngage custom objects with their nested property schemas map to Odoo custom models created via the Odoo Studio interface or via the ir.model and ir.model.fields API. We pre-create the destination model schema including all custom fields and field types before data import. MoEngage custom object relationships to Users map to Odoo many2one or many2many fields on the custom model. The Odoo data migration runs after standard model creation to avoid schema mismatch errors.