Migrate from Sqanit to Intercom

Sqanit's Device records (serial number, model, install date, owner metadata, device status) map to an Intercom Custom Object named 'Device' with external_id set to the Sqanit device identifier and external_created_at set to the Sqanit created_at timestamp. Device owner maps to the Contact lookup on the Device custom object. We create this custom object in Intercom during migration setup before any contact or conversation records load.

Sqanit Organization records (manufacturer or enterprise account name, contact details, address) map directly to Intercom Company. The Organization ID becomes the Company external_id. This object loads before End Users and Service Tickets so that Company lookup is satisfied at the moment records insert.

Sqanit End Users (consumers who scan the QR code) map to Intercom Contacts. Minimal profile data (name, email, language preference, device ownership) migrates directly. The link between End User and Device is preserved as a custom attribute device_id__c on the Contact that references the Device custom object by external_id. Contacts without an email address receive a generated placeholder email unless the customer specifies an alternative resolution strategy.

Sqanit Technicians (internal staff assigned to tickets) map to Intercom Admins or Team Members depending on their role in Sqanit. Role and team assignment fields migrate to Intercom team membership and permission group custom attributes. Technicians who are also end-users in Sqanit receive a separate Contact record in addition to their Admin/User account in Intercom.

Sqanit Service Tickets (status, priority, assignee, timestamps, linked device context) map to Intercom Conversations. The Sqanit ticket ID becomes the Conversation external_id. Ticket status (Open, In Progress, Resolved, Closed) maps to Intercom's Open, Snoozed, Closed state model. Device context from Sqanit (which device was scanned, what the issue was) migrates as custom conversation attributes (device_id__c, device_serial__c, asset_model__c) to preserve the product-linked service history.

Sqanit interaction records (every scan, AI-assisted resolution step, technician reply, status change) migrate as Intercom Conversation Parts within the corresponding Conversation. Timestamps preserve as created_at on each part. Multilingual message content migrates with locale tags preserved in custom attributes (locale__c). The chronological order of interactions is maintained by ordering parts by original timestamp during import.

Sqanit device compliance records (inspections, certifications, regulatory inspection dates, EU Digital Product Passport data) map to an Intercom Custom Object named 'Compliance Record'. Each record carries external_id from Sqanit, a lookup to the Device custom object, compliance_type (inspection, certification, DPP), status, expiry_date, and regulatory metadata fields. The customer specifies the exact schema during discovery because compliance record structure varies by industry (medical devices, automotive, industrial equipment).

Sqanit self-service content (524+ language variants) maps to Intercom Articles within Collections. The Sqanit article title, body content, locale tag, and parent section identifier migrate directly. Locale is set per article using Intercom's multi-language article support. The article-to-device linkage (if Sqanit articles are scoped to specific product models) is preserved as a custom attribute on the Article record in Intercom.

Sqanit AI triage rules and guided workflows (routing logic that activates at first QR scan) do not migrate. These are configuration objects specific to Sqanit's scanning context and have no equivalent in Intercom's workflow model. We deliver a written inventory of every active Sqanit workflow with its trigger conditions, routing logic, and self-help content references. The customer's Intercom admin rebuilds routing inside Intercom's Rules and Fin AI Agent configuration.

Sqanit's modular deployment means each customer activates different combinations of modules that introduce custom fields per account configuration. We capture these during discovery, map them to equivalent Intercom custom attributes on the appropriate custom object (Device, Compliance Record, Contact), and configure the destination schema before migration. Schema varies by customer which is why scoping happens before finalizing the migration map.