Migrate from Engage Messaging to HubSpot

HubSpot has no native conversation or message thread object — Engage message history must be flattened into notes

Engage Messaging stores individual SMS and MMS messages in threaded conversations with per-message direction, timestamp, and delivery status. HubSpot has no conversation object; the closest native construct is the contact timeline built from emails, calls, meetings, and notes. We write each Engage message as a HubSpot note on the contact record, prefixed by channel and direction, preserving the timestamp and content. Delivery receipt flags (delivered, failed, undelivered) are aggregated as per-contact custom number fields (SMS_Messages_Delivered__c, SMS_Messages_Failed__c). This means the visual thread view available in Engage is not reproduced in HubSpot — the team will see a chronological note feed rather than a chat-style thread.

HubSpot's marketing contact billing model and Engage's subscriber volume billing are structurally different

Engage Messaging prices on subscriber count and message volume — the billing model maps directly to your Engage list size. HubSpot separates CRM seat pricing from marketing contact pricing: contacts stored in HubSpot's CRM are free up to 1,000,000 lifetime, but contacts flagged as 'marketing contacts' for email campaigns incur per-contact billing. If your Engage subscriber list includes contacts who should never receive marketing emails (e.g., transactional-only SMS subscribers), they must be excluded from HubSpot's marketing contact model to avoid unexpected billing. We flag these contacts with a custom property (SMS_Transactional_Only__c) during migration and do not add them to any HubSpot marketing list.

HubSpot requires an email address for contacts — Engage subscribers without email create orphan records

HubSpot's contact model requires an email address as the primary identifier for deduplication and certain features (email tracking, HubSpot email unsubscribe). Engage subscribers frequently have only a phone number, particularly in markets where SMS-first communication dominates. We create HubSpot contacts with phone as the identifier in these cases, but flag them with a custom property (Email_Missing__c = true) so your team knows to enrich the email address. Contacts without email cannot use HubSpot's email nurturing, marketing automation triggers, or certain reporting features that rely on email domain intelligence.

Engage automation sequences (autoresponders, keyword triggers, time-based drip) have no HubSpot workflow equivalent

Engage sequences are built from triggers: keyword opt-in rules, time delays between messages, conditional branches based on reply keywords, and A/B send logic. HubSpot workflows automate based on contact property changes and list membership, but the trigger vocabulary and action set differ. Keyword autoresponders in Engage (e.g., 'TEXT JOIN to receive a link') cannot be migrated directly — they must be rebuilt as HubSpot workflows using 'Form submission' or 'Contact property' triggers. We export your Engage sequence definitions as a rebuild reference document and surface the trigger logic so your HubSpot admin can reconstruct the automation.

HubSpot Lists are not equivalent to Engage campaign recipient lists — metric parity is limited

Engage tracks per-contact engagement metrics on a campaign send (delivered, opened, clicked, replied). HubSpot's Campaign Member records track list membership and email-level engagement only for HubSpot-sent emails — they do not replicate SMS open and click rates from Engage sends. The last-send date and delivery status are preserved as custom contact properties (Last_SMS_Send_Date__c, SMS_Messages_Delivered__c) during migration, but ongoing SMS engagement analytics require HubSpot's built-in reporting to be rebuilt against those custom properties rather than relying on HubSpot's native campaign reporting.