Migrate from MoEngage to Pipedrive

MoEngage Users map to Pipedrive People records. Standard user attributes (email, first_name, last_name, phone, gender, date_of_birth, location) map to Pipedrive standard Person fields. MoEngage custom user attributes (up to 100 columns per schema) map to custom fields on the Person record. We flatten nested auxiliary data and nested object properties into pipedrive custom fields using dot-notation naming (e.g., loyalty_tier_level_value). Push token metadata (iOS APNs, Android FCM) migrates as a custom field but is flagged for re-registration after cutover.

MoEngage event streams have no direct Pipedrive equivalent. Pipedrive Activities (calls, emails, meetings, tasks) are engagement records tied to People, Organizations, and Deals. We transform high-value MoEngage events into Pipedrive Activity records: event names become Activity subjects, event timestamps become Activity dates, and key event properties (e.g., purchase_amount, subscription_tier) become custom Activity fields. Not all MoEngage events migrate; we scope the transformation to events with business significance agreed during discovery. MoEngage's behavioral frequency and recency data can alternatively become numeric custom fields on the Person record rather than individual Activity rows.

MoEngage Segments define audience filters based on user attributes and event behavior. Pipedrive has no segment equivalent; People filtering is done via saved filters within the People list view. We export the MoEngage segment definitions (filter logic, membership criteria, event conditions) as a written inventory document. The customer's Pipedrive admin recreates each segment as a saved People filter using Pipedrive's filter builder. Segment membership counts are preserved in a custom Person field (e.g., original_segment_name) so that the initial cohort identity is not lost even after the dynamic filter logic is rebuilt.

MoEngage Campaigns (email, SMS, push, WhatsApp, in-app) manage multi-channel messaging orchestration. Pipedrive has no campaign management objects. Campaign names, channel types, and send dates migrate as Activity records with a custom campaign_type field, or as Notes attached to the relevant Person records. The campaign content (HTML templates, personalization tokens, message body) is catalogued in the campaign inventory document and does not migrate to Pipedrive; Pipedrive supports email templates but not the channel breadth that MoEngage campaigns cover.

MoEngage Catalogs contain product and item schemas with custom attribute definitions. Pipedrive has no product catalog object. We map catalog item attributes to custom fields on the Deal record (for deal-specific product data) or Organization record (for company-level product/service associations). If the customer requires a full product catalog in Pipedrive, we recommend the Products add-on (available on Advanced and higher plans) or a third-party inventory integration; catalog migration scope is agreed during discovery.

MoEngage Content Templates (email, SMS, push, WhatsApp) carry HTML structure and personalization tokens. Pipedrive Email Templates support basic variable substitution. We export template HTML and token mappings for review. Full template recreation in Pipedrive requires manual effort by the customer's admin; we provide the token-to-variable mapping reference so that personalization fields map to the correct Pipedrive Person or Organization field names.

MoEngage allows up to 100 custom user attributes per schema. We map each custom attribute to a Pipedrive Person custom field of equivalent type (text, number, date, single-select, multi-select, phone, email, URL). Attribute data type mapping follows Pipedrive's supported field types; any MoEngage attribute type without a Pipedrive equivalent (e.g., nested object, array) is flattened to a text field with JSON string content for the customer's admin to parse post-migration.

MoEngage allows up to 100 custom event attributes per event type. We map high-priority event attributes to custom fields on the corresponding Pipedrive Activity record. Low-priority or low-cardinality event attributes are omitted from migration; the customer decides which event properties carry business value in Pipedrive's Activity model. Event-level attributes that represent product or transaction data (e.g., order_value, sku) are mapped to Deal custom fields instead.

MoEngage auxiliary company data attached to Users (e.g., company_name, industry, employee_count ingested from external sources) maps to Pipedrive Organization records. We resolve the Organization-User relationship by matching MoEngage user attribute company_name against the Organization name in Pipedrive. Organization custom attributes from MoEngage map to Organization custom fields using the same flattening approach as Person custom attributes.

MoEngage User device data (OS version, app version, push token, device_id, device_manufacturer) migrates as custom fields on the Pipedrive Person record. Push tokens (iOS APNs and Android FCM) are migrated as text fields but are flagged in the technical inventory as requiring re-registration. Pipedrive does not support native push notifications; the customer's mobile app must re-register tokens against its own push infrastructure after cutover. Token age and last-seen timestamps map to date custom fields on Person.

MoEngage Campaign Tags are workspace-scoped string labels that categorize campaigns by theme, brand, or team. Pipedrive has no tag object for Activities. We map campaign tags to a custom Activity field (campaign_tag) using a multi-select picklist, or alternatively store them as a comma-separated custom field on the Person record for audit purposes. Tags without a matching Pipedrive field value are listed in the gap report for the customer to resolve.

MoEngage Workspaces are isolated data clusters. If the migration involves multiple MoEngage workspaces (especially cross-cluster scenarios), we consolidate all workspace data into a single Pipedrive account. Workspace identifiers are preserved in a custom Person field (original_workspace_id) so that the provenance of records from different clusters is traceable post-migration. Pipedrive does not support multi-workspace isolation; all migrated records land in one account.