Migrate from Alemba Service Manager to Zendesk

ASM Incidents map directly to Zendesk Tickets. The ASM Incident status (Open, In Progress, Pending, Resolved, Closed) maps to Zendesk Ticket Status, and ASM priority P1-P4 maps to Zendesk Priority (Urgent, High, Normal, Low) via a pre-configured value mapping during migration scoping. We resolve ASM assignee (analyst) to Zendesk Agent by email match and ASM requester (end user) to Zendesk Requester. Incident description and history entries migrate as Ticket Comments in chronological order, with the ASM incident_id stored in a custom Zendesk field for cross-reference.

ASM Service Requests map to Zendesk Tickets with a custom field asm_request_type__c set to 'Service Request' and the original catalogue item reference preserved. Approval chain status from ASM migrates as a custom field asm_approval_status__c, and the associated catalogue item name migrates to the Ticket subject or a custom field. SLA assignments for requests migrate as Zendesk SLA Policy references applied post-import via the policy API.

ASM Change records require a type-tag strategy in Zendesk because Zendesk has no native Change object. We create Zendesk Tickets with a custom field asm_change_type__c set to 'Change', and preserve CAB approval status, risk score (Low/Med/High/Critical), implementation date, and rollback plan as custom ticket fields. CAB approval comments and sign-off records migrate as internal Zendesk Comments. The ASM Change status lifecycle maps to Zendesk Ticket status with a custom mapping table. Change-to-CI links (which CI is affected by the change) map to Zendesk Asset lookup fields if the Zendesk instance has Assets enabled.

ASM Problem records (root-cause analysis documents linked to known error records) map to Zendesk Help Center Problem Articles or to a Zendesk custom Problem object depending on the customer's Zendesk plan. The Problem-to-Incident linkage is preserved as a custom field problem_linked_incidents__c containing a comma-separated list of migrated ticket IDs. Problem resolution notes and known error record content migrate as article body content with structured sections.

ASM Tasks generated by the rules engine for parent Incidents or Requests migrate as Zendesk internal Comments on the parent Ticket if the task is informational. If the task represents a discrete work item requiring separate assignment and tracking, we create a Zendesk Child Ticket linked via the parent_id field. Task status from ASM (Not Started, In Progress, Complete) maps to a custom field asm_task_status__c on the child ticket.

ASM CMDB Item records map to Zendesk Assets. ASM CI Type (Server, Network Device, Software, Application, Location, etc.) maps to Zendesk Asset Type. ASM CI custom attributes (hostname, serial number, IP address, purchase date) migrate as Zendesk Asset custom fields. We flag records where the CI relationship graph references external federated discovery sources outside the migration scope, as these CI links will resolve to broken references in Zendesk Assets and require manual re-linkage post-migration.

ASM Asset records share the CMDB Item Type taxonomy with Configuration Items but carry financial attributes (purchase price, depreciation schedule, vendor contract, warranty expiry). These financial fields migrate as Zendesk Asset custom fields. Asset-to-CI linkage (which CI the Asset relates to) maps to Zendesk Asset relationship fields where the destination Zendesk instance supports asset-to-asset relationships, or is preserved in a custom field for manual reconciliation.

ASM Knowledge Base articles migrate to Zendesk Guide articles. We extract article content, category hierarchy, and service catalogue associations. Articles with embedded HTML or inline images require preprocessing before import to Zendesk Guide's HTML sanitisation rules. Attachment files linked to KB articles migrate as Zendesk article attachments via the Zendesk Help Center API. ASM article publish status maps to Zendesk Draft/Published state.

ASM Service Catalogue items (bundled offerings with workflows, pricing, and approval chains) do not have a direct Zendesk equivalent in standard Support Suite. We map catalogue item names and descriptions to Zendesk ticket subject templates and custom field defaults for request type routing. Approval chains are preserved in a custom field asm_approval_chain__c listing the approver roles and order, and the customer rebuilds the approval workflow using Zendesk triggers, macros, or a third-party approval app post-migration.

ASM SLA definitions (response time and resolution time targets per ticket type and priority) map to Zendesk SLA Policies. We create Zendesk SLA Policies for each ASM SLA definition during the schema phase, with first response and next agent reply targets matched to ASM's response and resolution windows. SLA breach history is extracted from ASM's history table and preserved in a custom field asm_sla_breach__c on each migrated Ticket for compliance audit purposes.

ASM custom fields created via ASM Designer follow the BU_[fieldname]_[fieldtype] naming convention and may have deprecated versions coexisting in the schema between build cycles. We identify the active version of each BU_ field during schema extraction, discard deprecated field versions, and create Zendesk custom ticket fields of the equivalent type (text, dropdown, checkbox, date, number). Field-level mapping is documented in the schema mapping deliverable before any data moves.

ASM distinguishes between End Users (Self-Service Portal, no licence), Business Users (Nano interface), and Analysts (Core interface). All three roles map to Zendesk End Users and Agents. We extract user records with their role assignments and map ASM analyst licences to Zendesk Agent seats. ASM external (unauthenticated portal users) map to Zendesk End Users. Email is the dedupe key for user matching during migration.