Migrate your OpenText Service Manager data

Incidents are the core ticket object in both Service Manager and SMAX. SMAX uses a service-oriented schema where Incidents are tied to lifecycle services; Service Manager uses a traditional record structure. We map fields one-to-one where possible but flag custom fields, priority mappings, and assignment rules that require explicit configuration in the destination.

Service requests submitted through the portal or API. SMAX surfaces requests through a service catalog with workflow routing; Service Manager uses a more rigid request record model. We preserve request type, status, and fulfillment data, then remap catalog item associations to match the target system's service structure.

Problem records are linked to Incidents via a known relationship. Both platforms support Problem management but with different field naming conventions and lifecycle stages. We map the Problem title, description, root cause, status, and linked Incidents, flagging any custom Problem categories that require a new entry in the destination.

Change records follow ITIL workflows with approval stages, risk ratings, and implementation plans. SMAX and Service Manager expose different field sets for Change scheduling and CAB signoff. We carry forward Change categories, risk levels, affected CIs, and approval history, re-creating the workflow routing rules in the destination.

Knowledge articles are well-structured in both platforms with title, body (HTML/RTF), author, publish date, and status. We export articles in their structured format and re-import them via the knowledge import tool, preserving article IDs in a cross-reference table so existing ticket links remain resolvable after migration.

SMAX is architected around services as first-class objects — each service defines its own request fulfillment workflow, SLA rules, and catalog visibility. Service Manager does not have an equivalent service-centric model. We flatten service-level configurations into discrete workflow rules and catalog mappings when migrating from SMAX to Service Manager, and reconstruct the service layer when migrating to SMAX.

CIs represent managed infrastructure assets and their relationships. SMAX includes a native CMDB and configuration management module. Service Manager uses a CI table with relationship records. We map CI types, attributes, and relationship graphs, noting that relationship cardinality and CI hierarchies may differ between the two and require a reconciliation step.

User records include login credentials, roles, group memberships, and contact details. SMAX and Service Manager use different role and permission models. We map the identity fields (name, email, department, title) and create a role crosswalk to align the source permission set with the closest equivalent in the destination.

Attachments on tickets and knowledge articles are stored as files linked to records. We export the binary files and their association metadata, re-importing them into the destination and re-establishing the parent record link. Large attachment batches are chunked to avoid API timeout thresholds.

Both platforms allow administrators to add custom fields to ticket records. We extract the full custom field schema — name, data type, picklist values, and display order — and reproduce it in the destination before importing data, avoiding silent data loss from unknown fields.

SLA records define response and resolution time targets tied to priority levels and service categories. SMAX SLA rules are service-scoped; Service Manager SLA rules are global or linked to categories. We preserve the time targets and business hours calendars, then re-apply them in the destination's SLA configuration interface.

Workflow definitions — including approval chains, escalation rules, and conditional routing — are tightly coupled to the platform's runtime engine and are not exported as portable data. We do not migrate workflow definitions. Instead, we document the active workflow rules during discovery and provide a specification for manual re-implementation in the destination.

Both platforms maintain a full audit log of record changes with timestamps, actor, and field deltas. Audit logs are append-only and not accessible via standard export endpoints. We do not migrate audit history. We confirm the audit trail in the destination will capture future changes from the point of migration.

Saved reports and dashboard configurations are proprietary binary or JSON blobs that do not have a documented export format. We do not migrate reports. We capture the list of active reports and their parameters during scoping and recommend rebuilding them in the destination using equivalent query constructs.