Migrate from Stames to Intercom

Stames Tickets map directly to Intercom Conversations. The original ticket status (open, pending, resolved, closed) migrates as a custom conversation attribute stames_original_status for post-migration reporting. Ticket priority migrates as a custom attribute stames_priority. Any SLA metadata attached to the ticket migrates as stames_sla_deadline for manual rebuild validation in Intercom workflows.

Stames Customer records map to Intercom Contacts. Contact fields (name, email, phone, custom attributes) migrate with email as the primary dedupe key. If a Customer record has no email, we generate a unique placeholder and flag the record for admin review. Customer-to-Ticket associations migrate as conversation-part relationships in Intercom.

Stames Conversation message threads migrate to Intercom Conversations preserving message order, timestamps, and attribution (agent vs customer). Each inbound message is imported as a conversation part via the Intercom API. We simulate inbound messages for customer-side parts to ensure Messenger visibility per Intercom's import documentation.

Channel attribution (Facebook, Instagram, WhatsApp, Email, API, Contact Form) from Stames migrates as a custom conversation attribute stames_channel_source. Intercom derives channel from the source at conversation creation; we preserve the original Stames channel value so that historical reporting by channel remains intact post-migration.

Stames Tags and Labels applied to Tickets migrate to Intercom Tags on the corresponding Conversation. Tag naming consistency is validated before import; duplicate tags are deduplicated. Intercom Tags are flat labels with no parent-child hierarchy, which aligns with Stames' flat tag model.

Stames Users and Agents with roles and permissions map to Intercom Teammates. We match by email address and assign the nearest Intercom role (admin, agent, or observer) based on the Stames role metadata. If a Stames user has a permission not supported by Intercom's role model, we flag it for admin review and assign the closest equivalent role.

File attachments on Tickets and Conversations are downloaded from Stames storage and re-uploaded to Intercom via the File API. Attachment metadata (filename, mime type, size, upload timestamp) migrates. URL references on the Intercom side point to Intercom's storage. Large attachments may require extended batch processing time.

Reminder and notification settings attached to Tickets migrate as custom conversation attributes (stames_reminder_date, stames_notification_type) for post-migration validation. Intercom does not have a native SLA or reminder object; the customer rebuilds notification triggers in Intercom's workflow engine post-migration.

Self-service portal configurations, including custom forms, portal access controls, and branding settings, are not exposed via the Stames API. We do not migrate portal configurations. We deliver a written portal-equivalent checklist mapping each Stames portal element to its Intercom Articles or operator-configurable equivalent so the customer's admin can rebuild post-migration.

Custom fields on Stames Tickets and Customers migrate as custom conversation or contact attributes in Intercom. We pre-create the custom attribute schema in Intercom before importing any conversation data. Attribute data types are mapped (string to string, number to number, date to date) with type mismatches flagged for admin confirmation.