Migrate from Support.ly by 500apps to Intercom

Support.ly Tickets map to Intercom Conversations. Ticket status (Open, Pending, Resolved, Closed) maps to Intercom Conversation state. Ticket priority maps to a custom Conversation priority attribute. The ticket channel source (email, chat, social) maps to Intercom's channel field. We preserve the original ticket number as a custom conversation attribute for reference. Custom ticket fields require field-level mapping against Intercom custom attributes, which must be created in Intercom before conversation import per Intercom's documented requirement.

Support.ly Customer records map to Intercom Contacts. Contact details (name, email, phone, address) migrate directly. Customer ticket history links to the contact via conversation association. Any missing optional fields receive sensible defaults. We resolve duplicate contacts by email address during import.

Support.ly Companies map to Intercom Companies. Company name, domain, and address details migrate. Multiple contacts link to the same Company record in Intercom. We build the company-contact linkage during contact import by matching the company_id reference from Support.ly.

Support.ly Agent profiles map to Intercom Teammates. Agent name, email, and team membership migrate. Agent permissions and role flags map to Intercom's teammate permission sets. We resolve agents by email match against the destination workspace.

Support.ly Teams group agents for routing. We reconstruct team membership in Intercom by mapping agent-team relationships and assigning agents to the corresponding Intercom Team. Team-level routing rules require manual configuration in Intercom's Inbox Settings post-migration.

Support.ly conversation threads attached to tickets carry message history and internal notes. We map the full message chain to Intercom Message parts, preserving timestamps (created_at, updated_at), sender identity (agent or contact), message body, and HTML/text formatting. We follow Intercom's documented guidance: conversations are created by simulating an inbound message from the contact, then posting the full transcript as a note or reply. Note that per Intercom's guidance, message-by-message migration inflates API calls by 10-100x versus simple conversation migration.

File attachments on tickets and KB articles are downloaded from Support.ly and re-uploaded to Intercom. We preserve original filenames and attachment ordering. Any size or format restrictions in Intercom (max 10MB per attachment) are flagged during discovery and communicated to the customer before migration.

Support.ly tags are a flat tagging structure applied to tickets and KB articles. We migrate tags as Intercom Tags, preserving the full tag vocabulary so existing filters and segments work in Intercom. Tags on tickets migrate as conversation tags; tags on contacts migrate as contact tags.

Support.ly KB articles include title, body content, category assignment, and publication status. We map article content and category assignments to Intercom Articles. HTML complexity that may not render identically in Intercom's article renderer is flagged during testing. Articles migrate as Draft status for admin review before publishing.

Support.ly KB categories group articles for navigation. We reconstruct the category hierarchy in Intercom as Collections and Sections. Article-to-collection assignments migrate during article import. Naming differences are handled by preserving the original category name in the collection.

Support.ly custom fields on tickets and customers require field-level mapping against Intercom's custom attributes. Per Intercom's migration documentation, custom data attributes must be created in Intercom before importing conversations so attribute values map correctly. We document custom field names, types, and sample values during discovery from a customer-provided record sample or screenshot, then pre-create the Intercom attributes before data migration begins.