Migrate from OpenText Service Manager to Zoho Desk

OpenText Service Manager Incidents map directly to Zoho Desk Tickets. The Incident number becomes Ticket Number or a custom external ID field (TicketExtId). Priority, status, and category fields map to Zoho Desk's priority, status, and category picklists. We preserve the original OpenText Incident ID in a custom field opentext_incident_id__c for cross-reference and audit. Incidents must import before Requests if both exist, because Zoho Desk ticket threads reference the parent ticket order.

Service Manager service requests map to Zoho Desk Tickets with a distinct request type or category value that distinguishes them from Incidents in reporting. The service catalog item from Service Manager maps to a Zoho Desk product or a custom field request_category__c. We preserve the requester, assignee, and any fulfillment group assignment as ticket fields.

Problem records in Service Manager do not have a native Zoho Desk equivalent; Problems represent known-error analysis linked to multiple Incidents. We map Problems to Zoho Desk Tickets and encode the Problem-Incident linkage in a custom field related_problem_id__c and in a Zoho Desk Ticket lookup field if the Enterprise edition supports it. The customer admin rebuilds the full Problem-Change-Incident linkage matrix in Zoho Desk's Blueprint or through Zoho Creator customizations post-migration.

Service Manager Change records carry approval stages, risk ratings, implementation schedules, and CAB signoff data that Zoho Desk's standard Ticket object cannot fully represent. We migrate Change records as Zoho Desk Tickets with custom fields for risk_rating, approval_status, and scheduled_start/scheduled_end dates. If the customer requires a richer Change management module, we recommend a Zoho Creator application as a post-migration configuration step, with the migration data seeded into it.

Knowledge Articles are well-structured in both platforms with title, HTML body, author, publish date, and status. We export articles in structured format and re-import them via the Knowledge Base API or CSV with the Zoho Desk expected column order (Title, Content, Status, Author Email, Publish Date). Attachments on Knowledge Articles are migrated as separate file records and re-linked via ContentDocumentLink. Note: Zoho Desk's native Zwitch tool explicitly states that KB attachments will not migrate, so we handle this manually via API.

Service Manager CI records represent managed infrastructure assets (servers, software, locations) with relationship maps. Zoho Desk's standard Product object is product-centric (for services sold) rather than asset-centric (for IT infrastructure tracked). We migrate CI data as Zoho Products with custom fields for asset_tag, location, serial_number, and status. CI relationships require reconstruction as Zoho Creator linked-record applications post-migration.

Service Manager user records (with login credentials, roles, group memberships, and contact details) map to Zoho Desk Agents (via email match) and Contacts (via contact details). The role and permission model differs significantly: Service Manager uses a complex role-based access matrix while Zoho Desk has Agent, Light Agent, and Support Administrator profiles. We map the identity fields and flag any Service Manager role without a Zoho Desk equivalent for manual reassignment. Agents must exist in Zoho Desk before any ticket import because tickets reference assignee_agentExtId.

Service Manager's service catalog defines request fulfillment workflows, SLA rules, and catalog visibility per service. Zoho Desk uses Departments as the primary organizational boundary with department-scoped layouts and fields. We map each Service Manager service to a corresponding Zoho Desk Department, and configure the department's layout with the relevant SLA and request-type fields. This requires pre-configuration of departments before data migration begins.

Service Manager SLA rules define response and resolution time targets tied to priority and service category. Zoho Desk SLA enforcement is available in the Enterprise tier via Business Rules with threshold-based triggers. We document every active Service Manager SLA (name, target in minutes, priority mapping, escalation action) in a written SLA inventory for the customer's admin to configure in Zoho Desk's Business Rules editor post-migration. SLA migration is configuration-only; SLA records are not imported as data.

Attachments stored on Incidents, Requests, Problems, Changes, and Knowledge Articles are exported as binary files with their record association metadata. We re-import them into Zoho Desk via the API and re-establish the parent record linkage. Note that Zoho Desk's Zwitch tool explicitly excludes KB article attachments; we handle KB attachments through the Knowledge Base API post-KB article import. File size limit is 10 GB total per upload batch per Zoho Desk's documentation.

Service Manager custom fields (name, data type, picklist values, display order) are extracted in full during discovery. Zoho Desk custom fields are scoped to individual departments, so we create each field per department that requires it, matching the data type (string, integer, decimal, currency, checkbox, picklist). Zoho Desk Enterprise allows up to 230 fields per module; Professional 150; Standard 50; custom fields are not available in the Free edition. We verify the destination edition's field limit before schema creation.

Workflow definitions in Service Manager — including approval chains, escalation timers, conditional routing, and SLA-triggered actions — are stored in a proprietary internal format that cannot be exported as portable data. We do not migrate them. We deliver a written inventory of every active workflow with its trigger, conditions, actions, and escalation timer values, plus recommended Zoho Desk Blueprint and Macro equivalents for the customer's configuration team to rebuild. Zoho Desk's Standard and Professional tiers have limited automation compared to Service Manager's full ITSM workflow engine; the customer should evaluate whether Enterprise-tier Blueprint capabilities cover their automation requirements before migration.