Migrate from MoEngage to Salesforce Sales Cloud

MoEngage User records map to Salesforce Contact with the user_id field preserved as an external ID for deduplication. All standard attributes (email, first_name, last_name, phone) map directly. Custom user attributes (up to 100 per MoEngage schema) map to Salesforce custom Contact fields with __c suffix. Behavioral attributes (RFM scores, last purchase date, lifetime value proxies) are preserved as typed custom fields (Date, Number, Currency, Picklist) so they are available for reporting without requiring Data Cloud. The MoEngage customer_id becomes a custom external ID field moengage_id__c for reconciliation.

MoEngage auxiliary data ingested from external sources (Shopify, Snowflake, AWS S3 integrations) is exported as additional user attributes and mapped to Salesforce custom fields of equivalent type. Auxiliary data that represents enrichment signals (loyalty tier, preference center data, subscription status) becomes Salesforce custom fields. Any auxiliary data that represents external transaction history is documented separately as a data dictionary for the customer to connect via Salesforce Data Cloud or a native integration.

MoEngage device data (push tokens, OS version, app version, device manufacturer, device model, OS build) is exported as auxiliary fields on the User record. We map these to Salesforce Contact custom fields (mobile_push_token__c, device_os__c, device_os_version__c, device_app_version__c, device_manufacturer__c). We document clearly that iOS APNs tokens and Android FCM tokens are invalidated on platform switch and require re-registration via the destination push SDK. A push token health report is delivered at cutover showing token age, OS distribution, and expected re-registration rates.

MoEngage event streams (user actions, behavioral triggers, channel interactions) map to Salesforce Task records with event type preserved as TaskType or a custom event_type__c field. High-frequency events (page views, screen opens, heartbeat events) are mapped to Task records at reduced fidelity (one Task per event type per user per day) to avoid Salesforce activity record explosion. Significant events (purchase, cart abandonment, subscription change, campaign click) map 1:1 as individual Task records. The MoEngage event timestamp maps to Task ActivityDate for timeline ordering.

MoEngage segment definitions (audience filters based on user attributes and event behavior) are too complex to migrate as automated criteria. We export the segment membership snapshot at migration time and create a Salesforce Campaign for each MoEngage segment, with the membership as CampaignMember records linked to the corresponding Contacts. The segment logic (filter criteria, RFM thresholds, behavioral rules) is documented in a segment inventory report for the customer to recreate in Salesforce Reports, Data Cloud, or a third-party segmentation tool post-migration.

MoEngage product catalogs with custom schemas (item attributes, pricing, inventory, images) are exported as catalog JSON and mapped to Salesforce Product2 records with custom fields for catalog-specific attributes. The catalog_id is preserved as a custom external ID on Product2. Product catalog images and URLs are stored as URLs on the Product2 record or in Salesforce Files linked to the product. Pricebooks are created from MoEngage pricing tiers. If the MoEngage catalog serves non-product purposes (e.g., loyalty rewards catalog), we document the catalog schema and recommend a Salesforce custom object or Salesforce Order Management System approach.

MoEngage content templates (HTML email templates, SMS bodies with personalization tokens, push notification copy, WhatsApp message templates) cannot be directly imported into Salesforce. We export the template content as HTML or plain text files and deliver them in a template inventory document with the personalization variable mapping. The customer's admin or a Salesforce partner rebuilds templates in Salesforce Classic Email Templates, Lightning Email Templates, or Salesforce Marketing Cloud (if licensed). SMS and WhatsApp templates require separate re-creation in the destination channel's approved template library.

MoEngage campaign tags are workspace-scoped string labels attached to campaigns. Tags that exist in the source workspace but not the destination appear as unresolved references during any campaign export. We audit all campaign tags and deliver a tag taxonomy report listing every unique tag, its usage count, and the campaigns it labels. The customer's admin decides whether to create a custom multi-select picklist field on the Campaign object to carry tag data, or to use Salesforce Topics for a more structured labeling approach.

MoEngage campaigns may reference Content APIs that fetch external data at runtime (e.g., weather data, dynamic pricing, inventory counts). Campaigns with unavailable Content API references fail or warn during import. We audit every campaign for Content API dependencies and deliver a Content API dependency report listing each API reference, its purpose, its required fields, and a recommended Salesforce alternative (Formula Fields, Flow, Apex, or a native integration). No Content API is migrated as code; all are documented for manual rebuild.

MoEngage allows up to 100 custom user attributes and 100 custom event attributes per schema. We export the full attribute schema (name, data type, cardinality) as a data dictionary. Each attribute is mapped to a Salesforce custom field of equivalent type: string to Text, integer to Number, decimal to Number, boolean to Checkbox, date to Date, timestamp to DateTime, array to Text (comma-separated) or JSON blob. Attribute dependencies in MoEngage segments and campaigns are flagged in the segment inventory report. Custom attributes that reference nested object data require flattening to a supported Salesforce type or a custom field with JSON content.

MoEngage workspaces are isolated data clusters. If the migration involves consolidating multiple MoEngage workspaces into a single Salesforce org, we merge user records by customer_id deduplication, reconcile segment membership across sources, and flag duplicate records for merge before final import. Workspace-level tag taxonomies are combined into a unified tag structure. This cross-cluster consolidation scenario adds two to three weeks to the migration timeline and requires explicit deduplication rules from the customer before any data loads begin.

MoEngage events may carry nested object properties (e.g., order_items array, product_details object, custom_attributes map) that do not map to a flat Salesforce Task schema. We export nested object data in its natural JSON structure and store it in a custom Long Text Area field (event_payload__c) on the Task record. If the destination Salesforce org uses Data Cloud, we map the nested structure to a Data Cloud Data Model Object for analysis without flattening. For reporting without Data Cloud, we extract top-level keys into separate custom fields and store the full payload for audit.