Migrate from Engage Messaging to Salesforce Sales Cloud

Engage Messaging Contact records map to Salesforce Contact by default, with the primary phone number mapped to the Contact's Phone or MobilePhone field. Contacts with no Account relationship in Engage are created as standalone Contacts or as Leads depending on whether the customer uses a Lead-to-Contact conversion process. Opt-in status migrates to HasOptedOutOfEmail (false = opted in), and any custom Contact properties map to Salesforce custom fields created during schema design. We use the Contact's email address as the dedupe key.

Engage Messaging Contacts with an associated company or organization map to a Salesforce Account via domain-based matching or a Company field. If no matching Account exists, we create one during migration. The Account is inserted before the Contact so that the AccountId Lookup is satisfied at insert time. Subaccount structure from Engage (used for team separation) does not map to Salesforce Account hierarchy and is documented for the customer's admin to configure post-migration.

Engage Messaging Conversation threads map to Salesforce Activity records. The thread metadata (start time, last activity timestamp, status: open/closed) becomes a parent Task record with description summarizing the thread. Individual inbound and outbound messages within the thread map to Salesforce EmailMessage records linked to that parent Task and to the Contact record. Direction (inbound/outbound), message timestamp, and delivery status migrate as EmailMessage fields. This reconstruction preserves the conversation context in Salesforce's activity timeline.

Individual SMS, MMS, and RCS messages migrate as Salesforce EmailMessage records with the message body in TextBody. Direction (EmailMessageDirection: Inbound or Outbound) is set per message. The message timestamp sets EmailMessage.MessageDate. Status (sent, delivered, failed, read) maps to Salesforce EmailMessage status fields where supported. MMS media references download separately and attach as ContentDocument records linked via ContentDocumentLink to the parent EmailMessage. Without this step, MMS messages in Salesforce show text only with no attachment context.

Engage Messaging Segments group Contacts by criteria such as engagement history, tag, or custom property. Segment definitions export as criteria lists with field names and operator logic. These criteria lists do not become executable Salesforce segments; instead we deliver a written mapping document that maps each Engage Segment to a Salesforce Campaign with the same contact membership or to a saved Report with equivalent filter logic for the admin to activate post-migration.

Engage Messaging Tags applied to Contacts migrate as Salesforce multi-select picklist values on the Contact object. We pre-create a custom multi-select picklist field (engagetag__c) during schema design and populate it with the pipe-delimited tag values from Engage. Tags used for Contact classification (e.g., VIP, churned, marketing_consent) carry across for segmentation and reporting in Salesforce.

Engage Messaging Automations (message sequences, triggers, delays, conditional branches) are platform-specific configuration that does not export as executable logic. We do not migrate automations as code. We export every active Automation as a human-readable mapping document describing the trigger event, conditions, message sequence steps, delays, and actions, with a recommended Salesforce Flow equivalent for each. The customer's admin or a Salesforce partner rebuilds the automations post-migration.

Engage Messaging provisions dedicated and toll-free numbers that are locked to the platform. Numbers cannot be transferred between providers. We export the full phone number configuration (number, type, label, carrier details, active/inactive status) as a re-provisioning checklist. The customer coordinates with their new SMS provider (SMS Magic, Mogli, or another AppExchange app) to provision replacement numbers before the cutover window. This is a coordination task, not a data migration task.

Engage Messaging Subaccounts are organizational units for team separation and permissions with no Salesforce equivalent. Salesforce uses Profiles, Permission Sets, Queues, and Territories for access control and data sharing. We document the subaccount structure and the agents assigned to each as a reference for the customer's Salesforce admin to replicate using Salesforce's native security model. This is a design and configuration task outside data migration scope.

Delivery rates, open rates, click-through rates, and subscriber growth metrics are computed on-platform in Engage Messaging and not exposed via API as structured data. We do not migrate analytics. We recommend capturing screenshots of all relevant dashboards before the cutover window and storing them outside Salesforce. The customer can recreate key metrics as Salesforce Reports post-migration using the migrated Contact and Activity data.

Engage Messaging custom Contact properties (fields beyond the standard phone, email, opt-in set) migrate to Salesforce custom fields on Contact. We pre-create the Salesforce fields with type-mapped equivalents (text fields, picklists, dates, numbers) before any Contact data is inserted. The field mapping document lists every custom Engage field and its Salesforce API name for the customer's admin to validate against their data model before production migration.

Engage Messaging opt-in status for SMS and each channel (SMS, WhatsApp, MMS) maps to Salesforce's HasOptedOutOfEmail standard field on Contact. A true opt-in migrates as HasOptedOutOfEmail = false (meaning the contact has not opted out of email). Channel-specific opt-in flags migrate to custom boolean fields on Contact if the customer needs granular channel-level consent tracking beyond the standard Salesforce email field.