Migrate from Rooftop to Intercom

Rooftop Customer records map to Intercom Contacts. The Rooftop email field becomes the Contact email (used as the primary key in Intercom). Name, phone, and custom properties migrate to Intercom's standard contact attributes or custom contact attributes. We run a dedupe check against existing Intercom contacts by email before inserting to avoid duplicates during migration.

Rooftop Company records map to Intercom Companies. The company name becomes the Company name, and the domain field maps to the Website attribute. We create Company records before Contact import so that the company_id lookup relationship can be resolved at Contact insert time. Rooftop companies without a domain are still created with a placeholder website value.

Rooftop Conversation threads map to Intercom Conversations. Each conversation's message body, timestamp, sender attribution (agent or customer), and internal note flag migrate. Intercom's API requires the contact to exist before a conversation can be created, so we sequence Contact migration before Conversation migration. The Rooftop channel type (email, chat) maps to Intercom's channel field on the conversation.

Rooftop Agent records map to Intercom Admins (full workspace access) or Teammates (inbox-restricted). Role and team assignment from Rooftop map to Intercom's inbox permissions and team membership. We resolve agents by email match against the Intercom workspace user list and flag any Rooftop agent without a matching Intercom user for admin provisioning before record migration.

Rooftop custom ticket fields vary by deployment. We inventory all field names, data types, and values during scoping. String and number fields map to Intercom custom contact attributes; ticket-specific fields that do not apply to the contact record map to conversation attributes on the individual conversation. Picklist-style custom fields map to Intercom select or multiselect custom attributes with the same option set.

Tags applied to Rooftop tickets migrate as Tags on the corresponding Intercom Conversation. Tag names are preserved verbatim. If the destination Intercom workspace already has tags with the same names, we reuse them to avoid tag proliferation. Tags used for internal categorization rather than customer-facing labeling are prefixed with an underscore in Intercom per the workspace's tagging convention.

File attachments associated with Rooftop conversations migrate as Intercom attachments. We extract the file URL from Rooftop, download the file, and re-upload it to Intercom's attachment endpoint linked to the corresponding conversation part. Attachment size limits (Intercom caps at 20MB per file) may require splitting large files or flagging them for manual re-upload. We validate attachment integrity by checksum before re-upload.

Rooftop KB articles and their category hierarchy migrate to Intercom Help Center articles and collections. Article body content (HTML or plain text) migrates as article body text. We recreate the category-to-article parent relationship as Intercom collection-to-article links. Internal article IDs do not carry forward; Intercom generates new article IDs. Article-level permission settings default to public at migration time and require admin review post-migration.

Rooftop ticket status values (Open, Pending, Resolved, Closed) map to Intercom conversation states (Open, Snoozed, Closed). We define the status mapping during scoping and apply it as a transform rule during migration. Any custom status values in Rooftop map to Intercom conversation tags or notes rather than states, since Intercom has a fixed state model.

Rooftop ticket creation timestamp and last-modified timestamp migrate to Intercom conversation created_at and updated_at fields. Message timestamps within conversations migrate as part_created_at on each conversation part. We validate timestamp ordering after migration to ensure that no message appears before the parent conversation creation date.