Migrate your Alemba Service Manager data
ITIL-aligned ITSM and ESM platform built for mid-enterprise organisations in regulated sectors, with a flexible multi-interface model and deep workflow automation baked into every deployment.
In its favor
Why people choose Alemba Service Manager
The signal that keeps Alemba Service Manager on the shortlist. Sourced from G2, Capterra, and customer scoping calls.
Mid-enterprise pricing that undercuts ServiceNow significantly while delivering comparable ITIL coverage, making it attractive to organisations priced out of enterprise ITSM platforms.
Strong regulatory positioning for healthcare, government, and financial services sectors where PinkVERIFY certification and audit trails are procurement requirements.
Alemba's federated CMDB architecture allows organisations to consolidate asset data from multiple sources without centralising everything physically, reducing migration complexity.
All modules ship out-of-the-box with no third-party add-ons required, meaning PPM workflows, Resource Manager, and automation tools are included at every tier rather than gatekept behind enterprise pricing.
Dual deployment options (on-premises or cloud) let organisations match the platform to existing security policies rather than forcing a single delivery model.
The learning curve is steeper than advertised — G2 reviewers report the user interface can be confusing for occasional users, leading to low adoption among self-service portal users.
The Classic API was deprecated with only limited support remaining, and organisations with legacy integrations built on it face a forced rewrite when migrating away.
The community and ecosystem is small compared to ServiceNow or Jira, making it harder to find third-party connectors, community workflows, or experienced implementers.
Reporting and analytics, while functional, lag behind competitors in dashboard customisation and real-time insight capabilities according to user reviews.
Migrations from Cherwell and similar platforms are quoted at 9–12 months, reflecting the complexity of transferring heavily customised rule sets and screen configurations.
Reasons to switch
Why people leave Alemba Service Manager
The recurring reasons buyers give for replacing Alemba Service Manager. Presented as facts, not knocks.
Platform scorecard
Strengths, weaknesses, and where Alemba Service Manager fits
Grades across six dimensions, plus a SWOT-style view of where the platform shines and where it falls short.
SWOT — strengths, weaknesses, and use-case fit
Strengths
Weaknesses
Where it works
Where it struggles
Pricing tiers
Alemba Service Manager pricing overview
Alemba uses a tiered interface model rather than gating features behind pricing tiers — all modules are included out-of-the-box at every licence level. Costs scale by the number of Analyst (Core) and Business User (Nano) licences, while the Self-Service Portal is licence-free for end users. The platform is available through G-Cloud for UK public sector organisations.
End-User Portal
Tier 1 of 3
License-free (included)
What's included
Need help selecting your Helpdesk?
Book a free 30 minute consultationPricing is informational. FlitStack AI does not bill on Alemba Service Manager's schedule — see our quote-based pricing →
What gets migrated
Alemba Service Manager object support
Object-by-object support for Alemba Service Manager migrations. Per-pair details surface during scoping.
Incidents
Fully supportedIncidents are the primary ticket object in ASM. The RESTful API exposes incident records including status, priority, assignment, and linked history entries. We perform a direct field-to-field mapping for standard incident properties. Custom incident properties require a pre-migration field audit.
Service Requests
Fully supportedService Requests are separate from Incidents and drive the Self-Service Portal workflow. We map Request records with their associated approval chains and catalogue item references. Approval history is extracted as a linked child object.
Changes
Fully supportedChange records carry full audit trails including CAB approvals, risk assessments, and associated CI links. The RESTful API exposes Change objects with their lifecycle status transitions. We preserve the full change chronology during extraction.
Problems
Fully supportedProblem records are linked to their related Incidents via a known relationship type. We extract Problems with their linked Known Error Records and root-cause annotations. Problem-to-incident linkage is maintained through relationship tables.
Tasks
Mapping requiredTasks are generated automatically by the rules engine for parent records. We extract all task records but note that task auto-generation rules may differ between source and destination systems, requiring manual post-migration review of task workflows.
Configuration Items (CIs)
Mapping requiredCIs belong to CMDB Item Types with a federated model allowing external discovery sources. We extract CI records with their type classification, relationship dependencies, and custom attributes. Federated CIs may have schema variation depending on the discovery connector used.
Assets
Mapping requiredAsset records share the CMDB Item Type taxonomy with Configuration Items but carry financial and lifecycle attributes. We map Assets separately from CIs and flag records with missing depreciation or procurement data for manual review.
Knowledge Base Articles
Mapping requiredKB articles are linked to service catalogue items and are accessible via the RESTful API. We extract article content, categories, and associations. Articles containing embedded HTML or attachments require separate file extraction passes.
Service Catalogue Items
Mapping requiredCatalogue items drive the Self-Service Portal and bundle related offerings. We extract catalogue entries with their associated workflows, pricing, and category assignments. Service bundle hierarchies require recursive extraction.
SLA Records
Fully supportedSLA definitions are attached to ticket types and define response and resolution windows. We preserve SLA assignments as properties on the ticket record. SLA breach history is extracted from the history log for compliance reporting.
Custom Screen Fields
Mapping requiredCustom fields are created via ASM Designer and follow naming conventions like BU_[fieldname]_[fieldtype]. Versioning of fields between build cycles is a known pattern we account for during schema extraction. Deprecated fields must be explicitly excluded or archived.
Users and Analysts
Mapping requiredASM distinguishes between End Users (Self-Service Portal, no license required), Business Users (Nano interface), and Analysts (Core interface). We extract user records with their role assignments and group memberships. Licence-tier assignments affect what data they can access.
Audit Logs and Compliance Records
Fully supportedFor regulated deployments in healthcare, government, and financial services, audit logs record every object state change with timestamps and actor attribution. We extract the full audit log table and map it to the destination's compliance object schema.
| Object | Support | Notes |
|---|---|---|
| Incidents | Fully supported | Incidents are the primary ticket object in ASM. The RESTful API exposes incident records including status, priority, assignment, and linked history entries. We perform a direct field-to-field mapping for standard incident properties. Custom incident properties require a pre-migration field audit. |
| Service Requests | Fully supported | Service Requests are separate from Incidents and drive the Self-Service Portal workflow. We map Request records with their associated approval chains and catalogue item references. Approval history is extracted as a linked child object. |
| Changes | Fully supported | Change records carry full audit trails including CAB approvals, risk assessments, and associated CI links. The RESTful API exposes Change objects with their lifecycle status transitions. We preserve the full change chronology during extraction. |
| Problems | Fully supported | Problem records are linked to their related Incidents via a known relationship type. We extract Problems with their linked Known Error Records and root-cause annotations. Problem-to-incident linkage is maintained through relationship tables. |
| Tasks | Mapping required | Tasks are generated automatically by the rules engine for parent records. We extract all task records but note that task auto-generation rules may differ between source and destination systems, requiring manual post-migration review of task workflows. |
| Configuration Items (CIs) | Mapping required | CIs belong to CMDB Item Types with a federated model allowing external discovery sources. We extract CI records with their type classification, relationship dependencies, and custom attributes. Federated CIs may have schema variation depending on the discovery connector used. |
| Assets | Mapping required | Asset records share the CMDB Item Type taxonomy with Configuration Items but carry financial and lifecycle attributes. We map Assets separately from CIs and flag records with missing depreciation or procurement data for manual review. |
| Knowledge Base Articles | Mapping required | KB articles are linked to service catalogue items and are accessible via the RESTful API. We extract article content, categories, and associations. Articles containing embedded HTML or attachments require separate file extraction passes. |
| Service Catalogue Items | Mapping required | Catalogue items drive the Self-Service Portal and bundle related offerings. We extract catalogue entries with their associated workflows, pricing, and category assignments. Service bundle hierarchies require recursive extraction. |
| SLA Records | Fully supported | SLA definitions are attached to ticket types and define response and resolution windows. We preserve SLA assignments as properties on the ticket record. SLA breach history is extracted from the history log for compliance reporting. |
| Custom Screen Fields | Mapping required | Custom fields are created via ASM Designer and follow naming conventions like BU_[fieldname]_[fieldtype]. Versioning of fields between build cycles is a known pattern we account for during schema extraction. Deprecated fields must be explicitly excluded or archived. |
| Users and Analysts | Mapping required | ASM distinguishes between End Users (Self-Service Portal, no license required), Business Users (Nano interface), and Analysts (Core interface). We extract user records with their role assignments and group memberships. Licence-tier assignments affect what data they can access. |
| Audit Logs and Compliance Records | Fully supported | For regulated deployments in healthcare, government, and financial services, audit logs record every object state change with timestamps and actor attribution. We extract the full audit log table and map it to the destination's compliance object schema. |
Gotchas
What to watch for in Alemba Service Manager migrations
Issues we've hit on past Alemba Service Manager migrations, tagged by severity. FlitStack AI handles every one — surfacing them up front because buyer engineering teams want to know.
Classic API deprecation requires RESTful API migration
Rules engine fires on all API-created objects
Session ID required for Classic API access
Custom field versioning creates duplicate schema entries
Federated CMDB may leave CIs with incomplete relationship graphs
| Severity | Issue |
|---|---|
| High | Classic API deprecation requires RESTful API migration |
| High | Rules engine fires on all API-created objects |
| Medium | Session ID required for Classic API access |
| Medium | Custom field versioning creates duplicate schema entries |
| Medium | Federated CMDB may leave CIs with incomplete relationship graphs |
Leaving Alemba Service Manager?
Where Alemba Service Manager customers move next
7 destinations Alemba Service Manager can migrate to.
How a Alemba Service Manager migration works
Four steps, Alemba Service Manager-specific
Connect
API key (RESTful API); Session ID (Classic API, deprecated) into Alemba Service Manager. Scopes limited to read-only on the data we move.
Map
We translate Alemba Service Manager-specific structures (custom fields, objects, value lists) to the destination's model.
Sample
Test with a 50–200 record subset to validate Alemba Service Manager quirks before production.
Migrate
Full migration with Alemba Service Manager rate-limit handling. Rollback available throughout.
FAQ
Alemba Service Manager migration FAQ
Answers to the questions buyers ask most during Alemba Service Manager migration scoping. Not seeing yours? Book a call.
Can't find your answer?
Walk through your Alemba Service Manager migration with a real engineer — 30 minutes, free, written quote within 24 hours.
Book a free 30 minute consultationOther helpdesks we support
Ready when you are
Migrate Alemba Service Manager.
Without the rebuild.
Free scoping call with a migration engineer. Tell us about your Alemba Service Manager setup and destination — written quote back within a business day.