Migrate from Tikit.Info to Intercom

Tikit.Info Tickets map to either Intercom Conversations or Intercom Tickets. This is the most consequential design decision in the migration. Conversations are best if the Tikit tickets were primarily customer-facing communication threads; they appear in the Intercom Messenger and support real-time replies. Tickets are best if the tickets are structured, trackable requests with custom attributes that require defined states. We scope this decision with the customer during discovery by reviewing ticket volume, average comment count, and whether custom attributes drive routing. The chosen model is locked before any data moves, because switching post-migration requires a second migration pass.

Tikit.Info Agents map to Intercom Admins. We reconcile by email address: each Tikit agent email is matched against an existing or provisioned Intercom Admin account. Tikit agents sourced from Entra may have UPNs (userprincipalname) that do not match Intercom email addresses directly; we flag mismatches in a reconciliation queue and require the customer's admin to provision matching Admin accounts before Agent migration begins. Active versus inactive agent status is preserved so the Intercom admin team matches the original Tikit licensing posture.

Tikit.Info Requesters map to Intercom Contacts (or Leads if the customer chooses to separate anonymous from identified users). We migrate display name, email address, department, and organization membership. Entra-sourced identity fields are preserved in a custom attribute entra_upn__c so the customer can trace the relationship back to the source identity. Any requester without a valid email address is flagged for manual review because Intercom requires email or an external_id on Contact creation.

Tikit.Info Teams (mapped to Microsoft 365 Groups in Entra) map to Intercom Teams. We create Intercom Teams during workspace setup and reassign Admin memberships during migration. Multi-department Tikit configurations create multiple Intercom Teams, one per Tikit department, so routing logic is preserved.

Tikit.Info Departments define organizational hierarchy for routing and reporting. Where Tikit uses separate Teams and Departments (multi-department mode), we consolidate these into Intercom Teams, using the Tikit department name as the team name and department membership as the team membership source. This is a structural simplification that Intercom's flat team model supports.

Tikit.Info KB articles (title, body, category, publish status, view count) map to Intercom Help Center Articles. We transfer article content, categorization, and publish status. Article-to-ticket relationships are not preserved natively because Intercom Articles do not link to Conversations or Tickets in the same way. We preserve the original Tikit ticket IDs in a custom attribute source_ticket_ids__c on each Article so the customer's admin can manually reconnect articles to related conversations after migration. KB article re-linking is documented in the migration handoff report.

Tikit.Info ticket comments (body, author, timestamp, is-public flag) migrate as Intercom Conversation Parts. Parts preserve the chronological order and author attribution within each Conversation. The Tikit is-public flag maps to part visibility settings in Intercom. If the ticket is migrated as a Conversation, comments from the requester and agents appear as separate Parts; if migrated as a Ticket, comments appear as Ticket Replies.

Tikit.Info file attachments on tickets are downloaded from Azure blob storage and uploaded to Intercom as Conversation or Ticket attachments. We flag attachments exceeding Intercom's 100MB/file limit and handle filename encoding issues. The migration process requires access to the Azure blob container; if Tikit's vendor-supported export does not include attachment URLs, we coordinate with Cireson to obtain the blob access.

Tikit.Info custom ticket fields (dropdowns, text fields, dates, user references) map to Intercom Ticket Attributes (if migrating as Tickets) or custom Data Attributes on Contacts or Conversations (if migrating as Conversations). We map each field by data type, flag fields with picklist values that require expansion in Intercom, and note any Tikit field types without an Intercom equivalent. Custom attribute creation in Intercom is a pre-migration configuration step.

Tikit.Info SLA policies (response time, resolution time, business hours) map to Intercom SLA policies. Intercom SLA policies are available on the Pro plan and above. We confirm the customer's Intercom plan tier during discovery and note that SLA assignment rules in Tikit may need to be recreated as Intercom rules or saved as documentation for the admin to rebuild post-migration.