Migrate from Alemba Service Manager to Salesforce Service Cloud

ASM Incidents map to Salesforce Case with Status, Priority, and Assignment preserved. The ASM incident identifier migrates to a custom field ASM_Incident_ID__c for cross-system reference. Linked history entries and work notes migrate as CaseComments or EmailMessages. SLA response and resolution assignments are preserved as a linked Entitlement record with milestones keyed to ASM SLA window definitions, with breach timestamps computed from ASM's SLA breach history table.

ASM Service Requests map to Salesforce Case with Case Origin = 'Self-Service Portal' and a custom ASM_Case_Type__c = 'Service Request'. Approval chains and catalogue item references from ASM migrate to a custom Approval_Request__c object with the requester, approver, and status fields preserved. The Self-Service Portal submission channel is recorded in a custom channel field to maintain source attribution.

ASM Change records map to Salesforce Case with Case Origin = 'Change Management' and ASM_Case_Type__c = 'Change'. CAB approvals, risk assessments, and CI links are preserved in a custom Change_Detail__c object with risk_level, cab_approval_status, and affected_ci_ids fields. The Change category (Normal, Standard, Emergency) migrates to a custom picklist. Standard Changes that follow a known template are flagged for the customer's admin to configure as Salesforce Flow templates post-migration.

ASM Problem records have no native Salesforce equivalent. We map Problems to Case records with Case Origin = 'Problem Management' and ASM_Case_Type__c = 'Problem'. The linked Known Error Record and root-cause annotation migrate to custom fields problem_root_cause__c and known_error_description__c. The problem-to-incident linkage is preserved via a custom Problem_Linked_Incidents__c field holding a semicolon-delimited list of migrated ASM incident IDs for cross-reference. If the organisation uses Problem Management at scale, we recommend a custom Problem__c object to separate Problem records from regular Cases entirely.

ASM CMDB Item records map to Salesforce Asset with CI Type mapped to Asset Type, serial number to Name or StockKeepingUnit, and custom attributes to typed custom fields. We extract CI relationship dependencies as a custom CI_Relationship__c junction object with parent_ci_id__c and child_ci_id__c lookups, because Salesforce's native Asset relationship does not scale to the many-to-many dependency graphs common in federated CMDBs. We flag any CI relationship originating from an external discovery tool that will not be migrated, as those CI links resolve to broken references in Service Cloud.

ASM Asset records share the CMDB Item Type taxonomy with CIs but carry financial and lifecycle attributes (purchase date, depreciation, warranty end date). We extract these into Salesforce Asset fields including PurchaseDate, Status, InstallDate, and custom fields for depreciation_schedule__c and financial_class__c. Duplicate detection uses serial number or asset_tag as the dedupe key. We flag any Asset records with missing depreciation or purchase price as requiring manual review before import.

ASM auto-generated and manually created Task records map to Salesforce Task with Status, Priority, and assigned user preserved. Tasks linked to parent Incidents, Requests, Changes, or Problems carry the migrated ASM parent identifier to maintain the WhoId and WhatId linkage in Salesforce. Auto-generation rules differ between ASM and Salesforce, so we disable Salesforce Auto-Create Tasks on Case during import and re-enable once migration is complete.

ASM Knowledge Base articles migrate to Salesforce Knowledge with article type mapped to Salesforce Knowledge article type and category hierarchy mapped to Salesforce Data Category Groups. We extract article versions, HTML body content, and associated service catalogue item links. Embedded attachments migrate as ContentDocument records linked to the article. Articles with HTML content containing script tags are sanitised during import. Version history migrates as article revision records. The customer's KB administrators review post-import to validate category assignments and article rendering in Lightning Experience.

ASM SLA definitions attached to ticket types migrate to Salesforce Entitlement Processes with response and resolution milestone definitions and associated Business Hours. Each Case-import batch references the matching Entitlement record by Account or Contact. The SLA breach history table (timestamps and breach reason) migrates as a structured CSV attached to the Entitlement record as an Entitlement History detail object. Service Contracts that define which SLAs apply to which customer accounts require manual configuration in Service Cloud and are not migrated as records.

ASM End Users, Business Users (Nano), and Analysts (Core) all map to Salesforce User records. We resolve ASM analyst records by email match against the destination Salesforce org's User table, and flag the Analyst versus Business User distinction via Role and Profile assignments. Any ASM user without a matching Salesforce User is held in a reconciliation queue for the customer's admin to provision before record import begins. ASM organisations in healthcare and financial services frequently have role structures tied to compliance mandates that require manual mapping by the customer's security team.

ASM audit logs record every object state change with timestamps, actor attribution, and object type. We extract the full audit log table as a structured CSV and load it into a custom Compliance_Audit_Log__c object with event_timestamp__c, actor_email__c, object_type__c, object_id__c, action__c, and old_value__c and new_value__c fields. This applies to organisations in healthcare, government, and financial services where audit trail preservation is a regulatory requirement. Salesforce's native Field History Tracking is enabled on Case fields as a supplementary audit mechanism post-migration.