Migrate from Alemba Service Manager to Gorgias

ASM Incidents map directly to Gorgias Tickets as the primary ticket object. We map Incident number to Gorgias Ticket ID reference, priority to Gorgias priority (high/medium/low), status to Gorgias status (open/pending/solved/spam), and description to ticket body. Linked Incident history entries migrate as ticket reply messages in chronological order. Assignment from ASM analyst to Gorgias agent is resolved via email lookup against the Gorgias user table. Incidents with a resolved SLA status preserve the SLA window and breach flag as custom fields since Gorgias tracks SLA limits per plan rather than as named SLA definitions.

ASM Service Requests map to Gorgias Tickets using a separate tag (src_type: service_request) to distinguish them from Incidents in the destination. Request approval chains and catalogue item references from ASM do not migrate as structured approval workflows; we store the approval status at time of migration as a custom text field and flag the approval chain for manual reconfiguration in Gorgias Rules or as a separate admin process. Request bundles and hierarchies flatten into individual ticket records with a parent reference where Gorgias allows.

ASM Change records have no direct Gorgias equivalent. We offer two strategies: (1) migrate Changes as tagged tickets with custom fields for risk_level, CAB_approval_status, and CI_links, preserving the full audit trail and risk assessment as ticket notes; or (2) flag Changes as out-of-scope for Gorgias migration and document them in the written handoff with a recommendation to manage Change records in a separate ITSM tool post-migration. The customer chooses the strategy during scoping. CAB approval dates and e-signature records do not migrate.

ASM Problem records and their Known Error Records do not have a native Gorgias object. We model Problems as parent tickets with a custom problem_reference field, and Known Errors as linked child tickets tagged with known_error. Root-cause annotations migrate as ticket notes. The Problem-to-incident linkage is preserved via the ticket tagging strategy. If the customer requires a formal Problem Management process post-migration, we recommend a separate ITSM tool or a Gorgias Enterprise plan custom object configuration.

ASM Tasks generated by the rules engine (child tasks on Incidents, Changes, or Service Requests) migrate as Gorgias subtickets linked to the parent ticket with a task_tag. Tasks that are standalone (not linked to a parent) migrate as tickets tagged with standalone_task. Auto-generated task patterns from ASM rules engine (which may fire on migrated records) are not recreated in Gorgias; we flag the original task generation rules for the admin team to rebuild as Gorgias Rules or Macros.

ASM CMDB records do not migrate to Gorgias because Gorgias has no CMDB or CI relationship model. We extract CI records with their Item Type, relationship dependencies, and custom attributes, and store them as customer attributes (for CI records linked to end users) or as a JSON-serialised text field on the related ticket for reference. CI relationship graphs are not recreated in Gorgias. Federated CMDB records sourced from external discovery tools that will not be migrated are flagged as broken reference risks during discovery.

ASM Asset records share the CMDB Item Type taxonomy with CIs but carry financial and lifecycle attributes that Gorgias does not model. Asset tag and financial attributes (purchase date, depreciation, maintenance contract) migrate as customer custom fields or as text attributes on the customer record. Full asset lifecycle management is outside Gorgias's scope and is flagged for the customer's admin to manage in a dedicated asset management tool post-migration.

ASM KB articles migrate to Gorgias Help Center articles. Article content, categories, and associations transfer directly. Articles with embedded HTML require pre-processing before Gorgias import because Gorgias uses a specific HTML subset for Help Center rendering. Attachments on ASM KB articles migrate as Gorgias article attachments or as external links at the customer's preference. Service catalogue linkage in ASM (linking KB articles to catalogue items) does not have a direct Gorgias equivalent and is documented as a rebuild item.

ASM Service Catalogue items and bundles drive the Self-Service Portal request workflow and bundle related offerings. Gorgias does not have a native Service Catalogue or request bundling model. We migrate catalogue item names and descriptions as Help Center articles under a dedicated category, preserving the item names for reference. Any workflow, approval, or pricing logic attached to catalogue items does not migrate and must be rebuilt in Gorgias Rules or handled manually.

ASM SLA definitions (response and resolution windows attached to ticket types) have no named Gorgias SLA equivalent because Gorgias tracks SLA limits per plan tier rather than as configurable definitions. We preserve SLA assignments as custom fields on the migrated ticket (sla_response_target, sla_resolution_target, sla_breach_flag) and attach the SLA breach history from ASM as ticket notes. SLA breach count and business hours configuration are stored as custom number fields. The customer configures new SLA rules in Gorgias Settings post-migration.

ASM End Users (Self-Service Portal users with no licence requirement) map to Gorgias Customers. Email address is the primary dedupe key. ASM user attributes (name, email, phone, location, organisation) map to Gorgias customer fields. End User role assignments and access levels from ASM do not migrate because Gorgias does not have a role-based access model for end users beyond agent versus customer.

ASM Analysts (Core and Nano licence holders) map to Gorgias Agents. We resolve ASM analyst records by email against Gorgias user accounts. ASM analyst group memberships and queue assignments map to Gorgias team structures. Analyst licence counts and session constraints on the source do not constrain the Gorgias agent count; the customer's Gorgias plan tier limits the number of active agents on the destination. We flag any ASM analyst records that cannot be matched by email for admin provisioning before production migration.

ASM audit logs recording object state changes with timestamps and actor attribution do not have a native Gorgias equivalent. For regulated deployments in healthcare, government, or financial services, we migrate the audit log as a structured CSV or JSON export stored as a ticket note on the related record (for audit traceability) or as an external log file delivered alongside the migration. Compliance record metadata (regulation type, audit date, findings) migrates as custom fields on the related ticket if traceability is required in the new system.

ASM Designer custom fields (BU_[fieldname]_[fieldtype] naming convention) migrate to Gorgias custom fields of the equivalent type (string, number, date, boolean, dropdown). We resolve field versioning during discovery: deprecated field versions with different IDs are discarded and only the active field definition is mapped. ASM Text Area fields used in conditional branching rules do not migrate their rule dependency; we flag these for manual rebuild in Gorgias Rules. Custom fields with cross-record references (QD fields) are stored as text attributes in Gorgias since the underlying entity type may not exist in the destination.