Migrate from Alemba Service Manager to Intercom

Alemba Incidents map to Intercom Conversations as the primary ticket record. Incident status (New, In Progress, Resolved, Closed) maps to Intercom conversation state (open, resolved, closed). Incident priority (P1-P4 or Critical/High/Medium/Low) maps to Intercom conversation priority flag and triggers SLA policy assignment. The Alemba Incident ID is preserved as a custom conversation attribute inc_id__c for cross-system audit. Linked history entries (status changes, analyst notes, customer updates) replay as Intercom conversation parts in chronological order. Incidents without a linked Contact resolve to an unlinked Conversation in the default Inbox.

Alemba Service Requests map to Intercom Conversations with request type preserved in a custom attribute request_type__c. Approval chains and catalogue item references from the ASM Self-Service Portal do not migrate as automated workflows — they are documented in the automation inventory as manual process candidates for Intercom approval routing or human-in-the-loop workflows. The Request's current approval status is logged as a conversation note if relevant to the record context.

Alemba Problems link to their related Incidents via a known relationship type. We create the Problem as a separate Intercom Conversation in the same Inbox and add a custom attribute problem_id__c. Incidents that have a Problem link receive a custom attribute related_problem__c pointing to the Problem conversation ID. Known Error Records and root-cause annotations are appended as internal notes (visible to agents only) on the Problem conversation. This preserves the problem-incident linkage without recreating Alemba's formal KEDB structure, which Intercom does not support natively.

Alemba Change records carry CAB approvals, risk assessments, and CI links that have no structural equivalent in Intercom. We do not migrate Changes as conversation records because they represent IT-internal change advisory board process data rather than customer-facing support content. We deliver a written inventory of all active and recent Changes including their status, CI associations, and risk level for the customer's admin to evaluate for retention in a separate IT audit system or manual documentation in Intercom's internal notes if the team uses Intercom for internal IT support.

Alemba Tasks generated by the rules engine (child tasks on parent Incidents or Changes) migrate as Intercom internal Tasks attached to the relevant Conversation. Task description, due date, assignee, and completion status transfer. Auto-generation rules from Alemba do not recreate in Intercom; we document the original task generation logic in the automation inventory for the customer to rebuild using Intercom Workflows or Rules if desired. Tasks that were completed in Alemba before migration import as completed Intercom Tasks with historical timestamps preserved.

Alemba End Users (no licence required) and Business Users (Nano interface) map to Intercom Contacts. Each user record maps name, email, and phone to the corresponding Intercom Contact fields. Role assignments (End User, Business User, Analyst) are not Intercom-native; if the customer needs role distinction (for example, to separate IT-internal contacts from end customers), we create a custom Contact attribute role_type__c and populate it from the ASM role. Multiple contacts with the same email in ASM are flagged for deduplication before import.

Alemba Analysts (Core licence) map to Intercom Admins or Agents depending on the customer's team structure. We extract analyst records by email match against the destination Intercom workspace and assign the nearest permission level (Agent for first-line responders, Admin for supervisors and config administrators). Any ASM analyst record without a matching Intercom user is held in a provisioning queue for the customer's Intercom admin to create before migration proceeds.

Alemba SLA definitions attached to Incident and Service Request types do not migrate as records. Instead, we create Intercom SLA Policies that mirror the original SLA response and resolution windows. The mapping translates Alemba's SLA type (Incident SLA, Request SLA) and priority (P1-P4) into Intercom SLA policy rules attached to the relevant Inbox. SLA breach history from Alemba's history table does not transfer to Intercom because Intercom tracks SLA compliance live rather than historically; we preserve breach count as a custom conversation attribute sla_breaches__c on migrated records.

Alemba ASM Designer custom fields (BU_fieldname convention) migrate to Intercom custom conversation attributes. We handle type translation: Alemba checkbox becomes boolean; Yes/No text becomes string or list; numeric fields become number; date fields become date. Deprecated field versions (a known ASM pattern where a field type changes between sprints and both versions coexist in schema) are identified and only the current active version is mapped. Fields with no active ASM screen reference are discarded to prevent attribute proliferation in Intercom.

Alemba KB articles linked to service catalogue items migrate to Intercom Articles in the Help Center. Article title, body content (HTML or plain text), and category assignments transfer. Embedded attachments migrate as file URLs if hosted externally, or as separate file attachments in Intercom if a hosting strategy is agreed. Articles without a destination collection are placed in a default Intercom collection with the original ASM category noted. Live/archived status from ASM maps to published/draft in Intercom.

Alemba Service Catalogue items drive the Self-Service Portal with associated workflows, pricing, and category assignments. Intercom does not have a service catalogue or request-for-item product. We do not migrate catalogue items. We deliver a written inventory of all active catalogue items with their category, pricing (if any), and associated workflows for the customer to evaluate whether a product catalogue rebuild in Intercom or a separate ordering portal is appropriate for their use case.

Alemba CMDB CIs belong to a federated model where relationship data may originate from external discovery tools. Intercom has no CMDB equivalent — Contacts and Companies are the only entity types. We do not migrate CI records. We flag CI references embedded in Alemba tickets (for example, a CI name stored on an Incident's custom attribute or linked relationship) and resolve them as custom conversation attributes with the CI identifier preserved as a string value. This maintains audit traceability without a formal CI record in Intercom.