Migrate from Pylon to Intercom

Pylon Issues map to Intercom Conversations. External comments migrate as customer-side messages; internal notes migrate as internal notes in Intercom (available on Essential and above). Created_at and Updated_at timestamps from Pylon preserve the original conversation start time and last modification time in Intercom. We set the conversation state based on Pylon's Issue status (Open, Resolved, Closed) mapping to Intercom's Open, Snoozed, or Closed state. Attachment handling follows the Intercom limit of five attachments per message; messages exceeding this threshold create an additional comment with the remaining attachments per Intercom's documented behavior.

Pylon Accounts map directly to Intercom Companies. Account-level custom fields migrate as Company attributes in Intercom. The Account name becomes the Company name, and the primary domain associated with the Account becomes the Company website field used for Intercom's domain-based contact matching. Intercom does not include Pylon's Account Intelligence health scores as native fields; we migrate these values as custom Company attributes (e.g., health_score__c as a number field or a custom dashboard tag) so that customer success teams retain the health context post-migration.

Pylon Contacts map to Intercom Contacts. Contact-level custom fields migrate as custom attributes on the Intercom Contact record. If the customer's Intercom plan is Starter or Essential (which supports only contacts without full company association), we flatten the Pylon Account-Contact relationship by associating each Contact with its corresponding Intercom Company record during migration. Phone number validation should be disabled in Intercom before migration (Settings > Your Workspace > People Data > Phone) because invalid phone formats in Pylon will otherwise block contact creation.

Pylon Teams map directly to Intercom Teams. Team membership and routing assignments migrate by matching team members by email address against the Intercom destination admin list. Intercom's team-based inbox routing uses the Inbox > Teams configuration; we pre-create the destination Teams in Intercom before migrating any conversations so that routing assignments resolve at import time rather than requiring post-migration reassignment.

Pylon Users (agents) map to Intercom Admins. User profiles, display names, and email addresses migrate directly. Agent-level custom fields in Pylon (handle time, CSAT scores) migrate as custom Admin attributes in Intercom where the plan supports them. We resolve each Pylon User by matching email against the Intercom destination admin table; any Pylon User without a matching Intercom Admin goes to a reconciliation queue for the customer's admin to provision before conversation import resumes.

Pylon Issue custom fields migrate as Conversation attributes in Intercom. The customer must create the corresponding custom attribute in Intercom (Settings > Data > Attributes > Conversation attributes) before migration runs, because Intercom requires the attribute schema to exist before data can be written. We generate a schema diff during discovery that lists every Pylon custom field, its data type, and the recommended Intercom attribute type (text, number, date, boolean, list) so that the customer can pre-create them.

Pylon Knowledge Base Articles map to Intercom Help Center Articles. Article body content migrates as HTML blocks with author and original created_at timestamps preserved. Images embedded in Pylon articles migrate as media files attached to the Intercom article. The primary restructuring concern is Pylon's flexible hierarchy: if Pylon articles exist in flat Collections with no sub-structure, they map directly to Intercom Collections with Articles inside. Any Pylon articles without a Collection assignment create a default 'Imported' Collection in Intercom during migration.

Pylon Collections (categories) map to Intercom Collections in the Help Center. Nested sub-collections in Pylon map to Intercom Sections (the middle level of Intercom's three-level Category-Section-Article hierarchy). If the customer's Pylon knowledge base uses only two levels (Collection > Article), we map Pylon Collection to Intercom Collection and create default Sections named after the original Collection to satisfy Intercom's enforced three-level structure. Collection-level permissions migrate where Intercom supports equivalent access control.

Pylon Notebooks from the Account Intelligence layer store account-level notes and context that do not have a native Intercom equivalent. Intercom does not include a Notebook analog in its standard object model. We offer two migration paths: create an Intercom Custom Object named 'Notebook' with a name field, content field, and account lookup (to the mapped Company), or migrate Notebook content as Notes attached to the corresponding Company via ContentDocumentLink. The customer chooses the strategy during scoping based on their Intercom plan tier (Custom Objects require Advanced or Custom plan).

Pylon Tasks from the Account Intelligence layer (separate from Pylon Issues, which map to Intercom Conversations) do not map to a standard Intercom object because Intercom does not include a standalone task management feature for account-level follow-ups. We migrate these as either Intercom Tasks (if the customer's plan supports task records) or as a Custom Object named 'Account Task' linked to the corresponding Company. Task priority, due date, and assignment migrate as custom fields on the destination record.

Pylon Projects from the Account Intelligence layer are account-level initiative records with no Intercom standard equivalent. We migrate Projects as a Custom Object named 'Project' in Intercom with fields for project name, status, start date, end date, and a lookup to the associated Company. This requires the customer to be on Intercom Advanced or Custom plan. Projects without a linked Account in Pylon are migrated as standalone Custom Object records without a parent Company reference.

Pylon Activity records capture account-level interaction history in the Account Intelligence layer. Since Intercom does not have a native Activity log at the account level, we migrate Activities as Notes attached to the corresponding Company record, or as tags on the Company with a standardized naming convention (e.g., activity_type__timestamp). The choice depends on the customer's volume: low-volume activity histories (under 5,000 records) use Notes; high-volume histories use tagged metadata to avoid inflating the Notes count.