Migrate from MoEngage to Twenty CRM

MoEngage Users carry name, email, phone, and up to 100 custom attributes. We map standard profile fields (first_name, last_name, email, phone) to Twenty Contact fields and extract a company domain or company_name attribute to create a linked Twenty Company record. Custom user attributes migrate as Twenty Contact custom fields, with type inference (text, number, date, boolean, picklist) applied during the schema design phase. MoEngage's auxiliary data and nested object attributes migrate as JSON-serialized custom fields or as related Company custom fields depending on the attribute scope.

MoEngage Events capture user actions (page views, purchases, custom triggers) with up to 100 properties per event type. We transform high-signal events (purchase, signup, upgrade, support_ticket) into Twenty Activity records of type Note or Task with the event name, timestamp, and key properties preserved as text. Low-frequency or high-volume behavioral events (page views, scroll depth) are summarized rather than migrated individually to prevent bloating Twenty's activity timeline. We preserve event count totals as Contact custom fields so aggregate behavioral data is accessible without full event replay.

MoEngage Segments are workspace-scoped audience definitions based on user attributes and event behavior. Twenty CRM does not have a native segmentation engine with behavioral rules. We create Twenty Static Lists (standard CRM practice) containing the Contacts that matched each MoEngage segment at migration time. Segment membership is a point-in-time snapshot. The behavioral filter logic (event frequency, recency, attribute conditions) is documented in the handoff inventory for the customer's admin to recreate as a manual list or to implement via a reverse-ETL pipeline from their data warehouse.

MoEngage Campaigns (email, SMS, push, WhatsApp, in-app) cannot migrate to Twenty CRM because Twenty has no native campaign management or multi-channel execution engine. We export campaign metadata (name, channel, target segment, send time, open rate, click rate) as a Campaign Audit Report. The customer's team rebuilds campaign logic manually in Twenty using their own workflow triggers or connects a dedicated engagement platform (Klaviyo, Mailchimp, Braze) for ongoing campaign execution. MoEngage's Content API references and campaign tags are flagged in the gap report.

MoEngage Email, SMS, push, and WhatsApp templates carry HTML content, personalization tokens, and conditional logic. Twenty CRM has no native template storage or dynamic content rendering engine. We export template HTML and token mappings as a Template Audit Report. The customer's team uses Twenty's Note and Task records to store template copy for reference, or rebuilds templates in their chosen engagement platform post-migration.

MoEngage Product Catalogs store item attributes, pricing, and metadata. If MoEngage catalogs represent a product catalog used for transactional or e-commerce personalization, we map catalog items to Twenty Company records (for vendor catalogs) or to a custom Product object that we pre-create in Twenty's schema. Product names, SKUs, and pricing fields migrate as text or number custom fields. Catalog schemas with complex nested attributes are flattened during transformation to match Twenty's flat-field model.

MoEngage Device Data (iOS APNs tokens, Android FCM tokens, OS version, app version, push enabled flag) is exported as part of the User record. We map these to Twenty Contact custom fields (device_os, app_version, push_enabled). Push tokens are device-specific credentials issued by APNs and FCM and are invalidated on platform switch; the destination platform cannot send push notifications using migrated tokens. We document this expected delivery gap (7-14 days post-migration until app re-engagement re-registers tokens) in the handoff report.

MoEngage allows up to 100 custom user attributes and 100 custom event attributes per object type. We extract the full attribute schema (name, data type, sample values) from the MoEngage API during discovery. Each custom attribute is mapped to a typed Twenty Contact or Company custom field. Picklist-type attributes from MoEngage become picklist fields in Twenty. JSON-object attributes are flattened to multiple fields or stored as a serialized JSON string field with explicit documentation for the customer.

MoEngage Workspaces are isolated data clusters that may correspond to different business units, brands, or environments within the same organization. Twenty CRM uses a Tenants model for self-hosted deployments and Teams within a workspace for access control. We map MoEngage workspace membership to Twenty Tenants or Teams, preserving team-based access control by exporting workspace owner and collaborator roles and mapping them to Twenty team memberships. Cross-workspace users are assigned to the primary Twenty tenant with cross-tenant access flags where applicable.

MoEngage Campaign Tags are workspace-scoped string labels attached to campaigns. Tags that exist in the source workspace but not in Twenty appear as warnings during the gap audit. We export all campaign tags and map them to Twenty Contact tags if the customer's team uses tags for contact classification, or document them as campaign metadata in the Campaign Audit Report.