Migrate from SYDLE ONE to Intercom

SYDLE ONE Contact records map directly to Intercom Contacts. Standard fields (name, email, phone, lifecycle stage) transfer 1:1. Custom properties on SYDLE ONE Contacts require field-level mapping against Intercom's custom attribute system. We preserve any lifecycle stage or segment data from SYDLE ONE as a custom attribute on the Intercom Contact for segmentation and reporting continuity.

SYDLE ONE Account records map to Intercom Companies. The Account-Contact relationship is preserved during migration by resolving the Account reference on each Contact and linking it to the corresponding Intercom Company via the external_id mapping. Company domain and industry data transfer to Intercom Company fields.

SYDLE ONE Service Desk Tickets map to Intercom Conversations (preferred for messaging-channel history) or Intercom Tickets (preferred for structured trackable cases). The choice depends on the source ticket's primary channel: email and chat history migrates as Conversations; structured back-office cases migrates as Tickets. Ticket statuses map to Intercom Conversation state or Ticket status values via an explicit status-mapping table built during scoping.

SYDLE ONE ECM Documents attached to Tickets or Contacts export as files and re-attach to the corresponding Intercom Conversation or Contact record. File metadata (filename, owner, date) is preserved in the attachment record. Large document trees organized by folder hierarchy do not retain hierarchy in Intercom; we export the folder structure as a separate mapping document for the customer's admin to reference during manual reorganization.

SYDLE ONE BPM Process definitions with BPMN notation, forms, and execution history export as structured JSON. Intercom has no BPM engine or process execution layer. We deliver the exported JSON plus a human-readable process summary as an inventory document. The customer's admin rebuilds process-triggered routing as Intercom Workflows using Rules and Fin AI. Active process instances mid-execution at migration time are flagged as a separate scope item for case-by-case handling.

SYDLE ONE Service Portal page configurations and routing rules export as JSON. Intercom Help Center Articles provide a self-service knowledge base but do not replicate portal page structures or routing logic. We deliver the Service Portal JSON export as a reference document for rebuilding portal pages in Intercom's Help Center. Any portal-page-to-ticket linking references require manual reconfiguration in Intercom's routing rules post-migration.

SYDLE ONE Chatbot flows for WhatsApp, Facebook, Telegram and other channels export as process-like JSON structures. Intercom's Fin AI Agent and bot builder use a different configuration model. We deliver the chatbot flow logic as an inventory document; the customer's admin rebuilds bot flows in Intercom's resolution bot or Fin configuration. Channel-specific routing (WhatsApp vs Messenger) rebuilds using Intercom's channel routing settings.

HR Recruitment Candidate records, Job Openings, and Application statuses export as structured data. Intercom is not an ATS or HR platform. Candidate and application data exports as CSV/JSON for import into a dedicated ATS (Greenhouse, Lever, Workday) if the customer continues using a separate HR system. This SYBOX module does not have a native Intercom equivalent.

Agile Project Management Projects, Sprints, and Task records export with velocity and burndown history preserved in a separate export sequence. Intercom is not a project management platform. Project and sprint data exports as structured JSON for import into a dedicated PM tool. This SYBOX module does not have a native Intercom equivalent.

Billing records including Contracts, Orders, and Payment history export from SYDLE ONE's Planet/Star-tier Billing module. Intercom does not include billing or ERP functionality. We export billing data as structured JSON for import into the customer's target billing or ERP system. Cross-references between Billing records and migrated Contacts or Companies are preserved in the mapping table so that the customer's billing team can re-establish relationships in their target system.

SYDLE ONE custom objects with implementation-specific schemas map to Intercom Custom Objects. We read the live SYDLE ONE instance schema via the admin interface before building the field map, and we pre-create the destination Custom Object definition in Intercom (Advanced tier and above) with all custom attributes, reference types, and data connector configurations before importing data. Custom field names with special characters are normalized to avoid Intercom validation errors.

Tags applied to Contacts, Accounts, Tickets, and Processes in SYDLE ONE migrate as Intercom Tags. We normalize tag names that contain special characters before importing to avoid validation errors. Tags used for cross-module classification (Process tags vs Ticket tags) are preserved as separate tag sets in Intercom to maintain the original organizational logic.