Migrate from Siit to Intercom

Siit Requests map to Intercom Conversations. Each Request's title becomes the Conversation subject, description becomes the initial message, status (open, pending, resolved, closed) maps to Intercom's Open, Snoozed, Closed states, and Priority (low, medium, high, urgent) becomes a custom Conversation attribute priority__c. The submitted_from channel (slack, ms_teams, employee_portal, mail) is preserved as a custom attribute source_channel__c for routing analysis. Communication threads (employee messages, admin replies, internal notes) migrate as Conversation parts ordered by timestamp.

Siit People records map to Intercom Contacts. The department, team, office location, legal entity, employment_type, and lifecycle_stage fields migrate as custom Contact attributes. Email is the dedupe key. Employees who are also Admins in Siit (the billable seat type) are provisioned as Intercom Admins rather than regular Contacts so they can access the inbox. Non-admin requesters migrate as standard Contacts without inbox access.

Siit Services catalog items represent internal IT request types (Laptop Provisioning, Access Requests, Password Reset). We create corresponding Help Center collections in Intercom and map each Service to a collection title. Service-specific instructions that were embedded in Siit's form structure migrate as Article content within the collection so employees referencing a migrated request can see the original service context. Workflow associations on Services are documented separately in the Workflow inventory.

Siit Application inventory records (software assets with ownership, lifecycle status, and category metadata) map to an Intercom Custom Object named Application with fields for app_name, owner_email, lifecycle_status, and category. The relationship between Application and Contact (which employee owns which license) is preserved as a Custom Object association. Intercom Custom Objects are available from the Essential plan onward.

Siit Equipment records (physical and virtual devices with ownership, lifecycle attributes, and configuration fields) map to an Intercom Custom Object named Device. We create the Device schema before migration with fields matching Siit's equipment lifecycle states (active, in_repair, retired, lost). The employee_device_relationship maps as a Contact-to-Device association via the Custom Object linking feature.

Siit Inboxes route requests to specific teams or queues. We map each Siit Inbox to an Intercom Team (Advanced and Expert plans support multiple Teams) and configure assignment rules within each Team's Inbox. Inbox rules (which Admin receives which request type based on category or tag) are documented and recommended as Intercom assignment rules or workflow conditions for the customer's admin to configure post-migration.

Tags on Siit Requests (via tag_uids arrays) migrate to Intercom Conversation tags. Intercom supports conversation tagging natively. We extract the complete Siit tag taxonomy during scoping and recreate it in Intercom before migration so that tagging associations are preserved on every migrated Conversation. Tags used for taxonomy beyond requests (on People, Services) are documented for the admin to apply manually or via workflow.

Siit Request records include first_replied_at and first_completed_at timestamps. SLA timers and escalation configurations are preserved as custom attributes sla_first_responded_at__c and sla_resolved_at__c on each Conversation. Intercom's native SLA rules (available on Advanced and Expert plans) require manual configuration by the customer's admin based on the migrated SLA metadata; we provide the documentation of each SLA threshold and the rule recommendation during handoff.

Siit Requests support arbitrary custom_form_inputs as label/value pairs with no fixed schema across organizations or request types. We extract all unique custom input labels during the migration scan, create corresponding custom Conversation attributes in Intercom for labels that repeat across multiple request types, and serialize all remaining inputs as a structured JSON blob attached to each Conversation as custom_attribute__c. This preserves the full data without requiring Intercom's schema to anticipate every possible label in advance.

Siit Workflows include trigger conditions, approval chains, and automated actions defined in a low-code builder. These workflow definitions are structurally incompatible with Intercom's conversation-triggered workflow model. We do not migrate Workflows as code. We extract every active Siit Workflow (title, trigger, conditions, actions, state: Live/Paused/Draft) and deliver a written inventory mapping each to a recommended Intercom workflow trigger and action sequence for the customer's admin to rebuild. Workflows in draft state are documented but not flagged as requiring rebuild priority.