Migrate from Alemba Service Manager to HubSpot Service Hub

Alemba Incidents map directly to HubSpot Tickets using the Incident ID as an external reference field. Status (Open, In Progress, Resolved, Closed) maps to HubSpot Ticket Status using the relevant pipeline stage. Priority and assigned Analyst resolve to HubSpot Ticket Priority and Owner respectively. The Incident's description, resolution notes, and linked history entries migrate as Ticket conversations (initial message as the opening thread entry, history entries as subsequent thread comments). ASM Incident category is stored as a custom ticket property for filtering after migration.

Alemba Service Requests map to HubSpot Tickets with a custom Service_Request__c checkbox or category property set to distinguish them from Incidents. Approval chains attached to the Service Request do not have a HubSpot native equivalent; we store approval status as a custom property and flag the approval chain for manual rebuild in HubSpot Workflows if Professional tier is licensed. Catalogue item references migrate as custom text properties linking to the Knowledge Base articles migrated in parallel.

Alemba Change records carry CAB approvals, risk assessments, implementation plans, and CI links that do not map directly to any HubSpot object. We map Change records to Tickets with a Change_Request__c tag and store CAB approval status, risk level, and implementation timeline as custom Ticket properties. The formal Change workflow, CAB sign-off records, and backout plans do not migrate; we deliver a written Change Management inventory documenting every active ASM Change template and recommended HubSpot Workflow equivalent for the customer's admin to rebuild.

Alemba Problem records with linked Known Error Records and root-cause annotations map to HubSpot Tickets with a custom Problem_Ticket__c property set to True and root-cause text stored in a custom long-text property. Problem-to-incident linkage migrates by setting the HubSpot Ticket's linked_ticket_ids property to reference the related Incident tickets. Known Error Records migrate as separate Ticket records with a Known_Error__c flag. HubSpot has no native Problem Management module; formal Problem workflows require a separate rebuild engagement.

Alemba Tasks (auto-generated by the rules engine or manually created) map to HubSpot Tasks. We extract task records with their parent reference (Incident, Request, Change, or Problem), status, priority, and assigned Analyst. ASM auto-generated tasks that resulted from rules-engine triggers may need manual recreation in HubSpot depending on whether equivalent automation rules are rebuilt post-migration. We flag auto-generated task counts per parent record during discovery so the customer can decide whether to include them or apply a date filter.

Alemba CMDB Configuration Items map to HubSpot Companies using the CI Name as Company Name and CI Type as a custom Company property ci_type__c. CI relationship data (CI-to-CI dependency links) has no native HubSpot equivalent; we store relationship references as a custom text property ci_relationships__c in a structured format and flag broken references for CI records where the related item originates from an external federated source that will not be present in HubSpot. CIs from federated discovery sources that are not fully synchronised with ASM's native relationship tables are flagged during discovery.

Alemba Asset records share the CMDB Item Type taxonomy with CIs but carry financial and lifecycle attributes (purchase date, depreciation, warranty expiry, serial number). We map Assets to HubSpot Companies using Asset Name as Company Name and store financial attributes as custom Company properties (purchase_date__c, warranty_expiry__c, serial_number__c, depreciation_status__c). Assets that reference a parent CI in ASM link to the equivalent Company record via the ci_relationships__c property. Missing depreciation or purchase date data is flagged per record during discovery for customer review before import.

Alemba SLA definitions attached to Incident, Request, and Change types do not map to a native HubSpot object. We store SLA name, response window, and resolution window as custom Ticket properties (sla_name__c, sla_response_hours__c, sla_resolution_hours__c, sla_breach_time__c). On HubSpot Professional and above, conditional SLA policies can be configured post-migration to enforce the SLA windows natively; on Starter tier, SLA enforcement remains a manual or reporting-only function. SLA breach history migrates as a custom Ticket property sla_breached__c set from the ASM audit log.

Alemba Knowledge Base articles with category assignments and portal associations map to HubSpot Knowledge Base articles. We extract article content, category hierarchy, and portal links during a dedicated KB extraction pass. Articles containing embedded HTML require sanitisation before import to match HubSpot's knowledge base rendering. Attachments embedded in articles are extracted as separate files and linked via a custom HubSpot property. Article-to-catalogue-item associations are stored as a custom article property for rebuild of the service catalogue in HubSpot.

Alemba Service Catalogue items with bundled offerings, pricing, and workflow assignments do not have a native HubSpot equivalent. We map catalogue entries to HubSpot Knowledge Base articles with a custom catalogue_item__c flag, and document the workflow association and pricing for the customer's admin to rebuild using HubSpot Customer Portal categories and Workflows post-migration. Service bundle hierarchies are preserved as a structured mapping document listing the parent-child relationships.

Alemba ASM Designer custom fields with BU_ prefix convention map to HubSpot custom ticket properties using the field type to determine the HubSpot property type. Field versioning between build cycles creates duplicate schema entries with different IDs; we identify the active version of each field during schema extraction and discard deprecated field versions. Multi-select or checkbox fields in ASM map to HubSpot multi-select or checkbox properties. Required-field constraints in ASM must be reviewed against HubSpot's required property setting during destination schema design.

Alemba End Users, Business Users (Nano), and Analysts (Core) map to HubSpot Users. We extract user records with role assignments, email, and active/inactive status. ASM analyst licences may constrain concurrent API session availability; we work with the customer's licence allocation during discovery to ensure sufficient analyst sessions for data extraction. Inactive ASM users with historical ticket ownership are created as inactive HubSpot Users so that ticket history retains the original assignee. ASM role assignments map to HubSpot Teams and permission sets.

Alemba audit logs recording every object state change with timestamps and actor attribution do not migrate into a native HubSpot compliance object. We export the audit log as a structured dataset and store compliance-relevant fields (last modified by, last status change, SLA breach events) as custom Ticket properties. For regulated deployments in healthcare, government, and financial services, we deliver a separate compliance log export file and a written mapping document describing where each audit event type appears in HubSpot's equivalent logging. HubSpot's standard ticket revision history is preserved alongside the compliance export.