Migrate from eTicket to Intercom

Discovery and scoping call

We audit the source eTicket instance to capture ticket volume, customer count, agent and team count, custom ticket field definitions and data types, attachment volume and file size distribution, KB article count and category depth, and any custom object structures. We pair this with a review of the target Intercom workspace configuration (seat count, plan tier, existing Data Attributes, Knowledge Hub collections, and any active Custom Object definitions). The discovery output is a written migration scope document that maps every eTicket object to its Intercom equivalent, flags any custom fields without a type match, and estimates the batch count for large ticket histories.

Workspace preparation in Intercom

We verify that the necessary Ticket Types and Ticket Attributes are configured in Intercom before data import. Any eTicket custom fields that require new Intercom Data Attributes are created during this phase. We confirm admin provisioning for all migrating agents, configure Team structures in Intercom, and disable phone number validation and active Outbound campaigns to prevent import failures. If Fin AI will be used post-migration, we document the KB articles that will serve as the Fin knowledge source so that article ordering and completeness are validated before cutover.

Schema mapping and transform design

We design the field-level mapping for every eTicket object. Ticket status values map to Intercom Ticket state; agent assignments map to Intercom admin references; team assignments map to Intercom team references. For conversations, we design the conversation_parts transform that splits messages by author type (admin vs user) and preserves created_at timestamps per part. Custom fields that lack an Intercom type match are documented as manual-configuration items with sample data for the customer's admin to review. We run a small sample migration (10-20 tickets) into the Intercom workspace to validate mapping correctness before committing to the full run.

Contact and company import

We import eTicket Customers as Intercom Contacts before any ticket data. Email address serves as the deduplication key. If the eTicket source stores both identified users and leads, we preserve the distinction by setting the role field appropriately. Companies from eTicket (if present) import as Intercom Companies linked to the corresponding Contacts. Any Contact without an email address is flagged for the customer's admin to handle manually because Intercom requires an email or external_id for contact creation.

Ticket and conversation migration with batch sequencing

We import eTicket tickets in dependency order: Ticket metadata first (subject, status, priority, timestamps), then conversation_parts in chronological sequence to preserve threading. Each ticket is linked to its resolved Contact record and assigned Team and Agent. Attachments upload concurrently with the conversation_parts they belong to, with files re-hosted on Intercom's CDN. Tags on tickets migrate as Intercom Tags. We chunk large ticket histories into import-safe batches to avoid timeout failures, with reconciliation row counts emitted after each batch.

Knowledge base and custom object import

KB Articles import into Intercom Collections and Sections, preserving the three-level hierarchy where it exists in eTicket. Author attribution maps to Intercom Admins by email match. If eTicket contains custom objects linked to tickets, we import the custom object records after ticket migration completes, then resolve the Intercom IDs and update the association fields in a second pass. We verify custom object linkage after import by spot-checking 20-30 records against the source.

Cutover, validation, and automation handoff

We freeze writes in eTicket during cutover, run a final delta migration of any records modified during the migration window, then enable Intercom as the system of record. We deliver a row-count reconciliation report comparing eTicket source counts to Intercom destination counts for every object. We deliver the automation and routing rule inventory document listing every eTicket workflow or automation that requires rebuild in Intercom's workflow builder. We do not rebuild these as code within the migration scope. We support a one-week hypercare window for reconciliation issues raised during the first week of live operation in Intercom.