Migrate from Watermelon to Intercom

Watermelon Contacts map to Intercom Contacts (users with email) or Leads (unidentified visitors or contacts without email). We use email as the dedupe key. Any Watermelon Contact with an @ domain email maps to Intercom Contact; contacts without email or with only a phone number map to Intercom Lead. All Watermelon custom Contact fields map to Intercom custom attributes on the Contact or Lead object, which must be pre-created in the Intercom workspace settings before import begins.

Watermelon Conversations map directly to Intercom Conversations. Each Conversation is linked to a Contact or Lead (resolved via the Contact mapping above). We preserve the channel metadata (WhatsApp, Instagram, Facebook, live chat) as Intercom Conversation tags so that channel origin is visible in the Intercom inbox. Conversation state (open, resolved) migrates as Intercom Conversation state.

Watermelon Messages map to Intercom Parts within the parent Conversation. Each Part carries sender type (agent, bot, customer), message content, timestamp, and channel metadata. We preserve the full chronological message sequence within each Conversation to maintain conversational context. Attachment URLs from Watermelon migrate as Intercom Attachment objects linked to the corresponding Part.

Watermelon Channels (WhatsApp Business, Meta Facebook, Meta Instagram, live chat, email) are OAuth-based integrations scoped to the Watermelon installation. These cannot be transferred. We inventory every active channel with its business account ID, page ID, phone number, or inbox configuration and provide step-by-step reconnection instructions for Intercom's channel setup. The customer must have admin access to each Meta Business account and WhatsApp Business account.

Watermelon Tags applied to Contacts and Conversations migrate as Intercom Tags. If there are fewer than 50 unique tags, we map them 1:1 to Intercom Tags. If the tag vocabulary exceeds 50, we recommend mapping to Intercom Topics for better inbox management and article association. The customer chooses the strategy during scoping.

Watermelon Contact-level custom fields are exposed via API with varied data types (string, number, date, boolean, array). We discover all custom fields during scoping, map each to an Intercom custom attribute of matching type, and pre-create the attribute schema in the Intercom workspace before any contact import begins. Custom fields that have no direct Intercom equivalent (for example, array-type fields) are serialized as JSON strings in a single custom attribute.

Watermelon Notes attached to Contacts migrate as Intercom Activity records of type note on the Contact timeline. Note body migrates as the activity body text with the original creation timestamp preserved. Notes are imported after Contacts to ensure the Contact record exists and can accept the activity association.

Watermelon Flow automations (trigger conditions, routing logic, action sequences) are stored server-side and inaccessible via API. We do not migrate them as code. We document every active Watermelon Flow with its trigger event, condition branches, and action sequence in a structured written inventory that the customer's admin uses to rebuild equivalent rules in Intercom Rule Builder post-migration.

Watermelon AI Actions and model finetuning settings control bot response behavior and are platform-specific configurations with no export path. We do not migrate AI Actions or finetuning as configuration. We document the current AI behavior (common FAQ coverage, escalation thresholds, supported languages) and provide a Fin AI Agent configuration guide so the customer's admin can set up equivalent automated resolution rules in Intercom.

Watermelon webhook endpoint URLs and subscribed event types are exported as a configuration inventory. We provide the event type mapping to equivalent Intercom webhook events (contact.created, conversation.created, conversation.part.created) and instructions for re-registering each webhook endpoint in Intercom's developer settings. Outbound webhook re-registration is a manual step performed by the customer during the post-migration window.