Migrate from Serviceaide Intelligent Service Management to Intercom

ISM CCTI tickets map to Intercom Conversations. The CCTI ticket number becomes the conversation id stored in a custom attribute for cross-reference. Title and description migrate as the first message in the conversation thread. CCTI status (New, In Progress, Resolved, Closed) maps to Intercom conversation state (open, resolved, closed). CCTI priority maps to a custom conversation priority attribute in Intercom since Intercom's native priority is tied to SLA tiers rather than ticket-level priority fields. Assigned analyst maps to Intercom part assignments on the conversation. Requester maps to the Intercom contact record.

ISM formal ticket lifecycle stages (Open, Assigned, In Progress, Pending Customer, Resolved, Closed) map to Intercom conversation states plus tag application. We do not migrate SLA-triggered state transitions as automation. We document every ISM workflow rule that governs status change, including conditional branching, and deliver a written equivalent using Intercom Rules and actions to the customer's admin for rebuild.

ISM user records (end-user requesters) map to Intercom Contact records. The ISM user's email, name, and department migrate as Contact attributes. ISM role assignment (end-user vs. analyst) determines whether the record lands as an Intercom Contact (end-user) or whether the analyst record requires Team member provisioning separately. Role, department, and location from ISM migrate as custom Contact attributes in Intercom.

ISM analyst and agent accounts map to Intercom Team members. We extract ISM user records where role is analyst or agent, including email, name, and group assignment. Group assignments from ISM map to Intercom team inboxes so that ticket routing by group during migration preserves the analyst's team context. Individual agent inboxes are provisioned by the customer's admin during Intercom setup before migration begins.

ISM Knowledge Manager articles migrate to Intercom Help Center articles. Article title, body content, and status (draft, published, archived) transfer directly. ISM article tags migrate as article labels in Intercom. The approver metadata (approver name and approval comments stored as separate ISM metadata fields not visible in the article body) is extracted as a structured header block and appended to the article body during migration so the approval chain is preserved and can be manually entered into Intercom's article workflow if needed.

ISM stores article approver names and comments as separate metadata fields outside the article body. This metadata has no native Intercom equivalent since Intercom's article approval workflow is editor-based rather than metadata-driven. We extract this data as a structured JSON header and include it in the migration deliverable as a reference table for the customer's admin to re-enter if article approval tracking is required in Intercom's Help Center editorial workflow.

ISM Configuration Items store hardware and software asset relationships, CI approval phases, and CI type classifications that have no native equivalent in Intercom. We do not migrate CI records as a standalone object. For ISM tickets that reference CIs, we extract the CI name and type as custom attributes on the related Intercom Contact or Conversation record, preserving the reference without the full relationship graph. CI approval phase data (which has been flagged as a source of workflow corruption in ISM defect ISM-13238) is excluded from migration unless specifically requested by the customer after we flag the risk.

ISM Asset Center records hold hardware and software inventory with relationship to CIs. Intercom has no asset management module. We extract asset records associated with ISM contacts and merge relevant fields (primary asset type, asset identifier) into custom attributes on the corresponding Intercom Contact. Full asset inventory does not migrate; we deliver a separate asset export CSV for the customer's ITSAM team to manage outside Intercom.

ISM Change Manager records with risk assessment, approval phases, and change scheduling have no equivalent object in Intercom. Change records represent a formal ITSM process that Intercom's conversational support model does not support. We do not migrate change records. We deliver a written change management inventory documenting every active ISM change record, its associated CI, its risk score, and its approval status, so the customer's ITSM team can manage these records in an alternative tool post-migration.

ISM Service Catalog entries define services with associated SLAs and workflows. Intercom has no native service catalog. We extract service names and SLA thresholds associated with migrating tickets and store them as custom conversation attributes so that the service context is preserved even though the formal catalog structure does not exist in Intercom. SLA escalation policies are documented separately for rebuild in Intercom Inbox SLA settings.

ISM SLA policies with breach flags and escalation actions are configuration objects rather than data records and do not migrate. We extract every ISM SLA definition (target resolution time, breach threshold, escalation action, affected service) as a written inventory and map each to the equivalent Intercom Inbox SLA setting so the customer's admin can rebuild SLA enforcement in Intercom's inbox configuration.

Files attached to ISM CCTI tickets (screenshots, logs, documents) migrate as conversation attachments in Intercom. We extract attachment URLs or binary content from ISM, upload to Intercom's file hosting (which has a 10 MB per-file limit), and link to the corresponding conversation or contact record. Attachments exceeding the size limit are flagged and delivered as a separate download archive.

ISM multi-tenant deployments for MSP and BPO providers map to Intercom's workspace structure. Each ISM tenant organization maps to a dedicated Intercom inbox or, for multi-brand MSPs, a separate Intercom workspace. We scope every extraction query to the specific ISM organization ID to respect tenant isolation boundaries, validated before staging. Customer branding and SLA template differences per tenant are documented for Intercom inbox-level configuration post-migration.