Migrate from OpenText Service Request Center (SRC) to Zoho Desk

SRC Service Requests map directly to Zoho Desk Tickets. We tag each migrated Service Request with a source_object tag of 'ServiceRequest' so agents can filter migrated records by origin type in Zoho Desk's ticket list view. The SRC request title maps to Ticket Subject, description maps to the initial thread (first comment), and status maps to Zoho Desk Ticket Status with a status mapping table built during scoping. Priority from SRC maps to Zoho Desk Priority field.

SRC Incidents are distinct from Service Requests and track IT infrastructure disruptions with impact and urgency fields. We map Incidents to Zoho Desk Tickets tagged with source_object = 'Incident', preserving Impact and Urgency as custom fields incident_impact__c and incident_urgency__c. If the customer maintains a separate Incident lifecycle (separate from Service Request workflow), we create a Zoho Desk department for Incidents and route them there during import so that department-specific SLA policies apply.

SRC User records map to Zoho Desk Agents. We resolve by email address as the dedupe key. SRC group memberships and role assignments map to Zoho Desk Teams and Role Profiles respectively. Passwords cannot migrate from SRC and agents must reset credentials in Zoho Desk post-migration. Any SRC User without a matching email in the destination goes to a reconciliation queue for the customer's admin to provision before record import resumes.

SRC Customer records (external requesters) map to Zoho Desk Contacts. The Contact's email address is the dedupe key. If the customer uses Zoho CRM alongside Zoho Desk, we check for existing Contact records in CRM and link migrated Contacts to the corresponding Account. If CRM is not in scope, Contacts are imported without Account association and the customer reconciles Account linking post-migration.

SRC Companies (external organizations associated with Customers) map to Zoho Desk Accounts. Support Groups map to Zoho Desk Teams. We distinguish between an external company Account and an internal routing Team by inspecting the SRC record type field during discovery. Teams are created before Contacts are imported so that ticket assignment routing works at import time.

SRC KB Articles map to Zoho Desk Articles. The article body undergoes HTML sanitization before import: tables are converted to Zoho Desk's supported formatting, embedded images are extracted and re-hosted as inline attachments, and links are preserved as-is. SRC article categories map to Zoho Desk Sections; if categories have a hierarchical structure (parent/child), we map to Section hierarchy in the destination Help Center. Author and last-modified metadata migrate as article properties. Zoho Desk does not migrate KB article attachments natively; we retrieve files attached to KB articles during the attachment audit phase and attach them to the corresponding Articles in Zoho Desk.

SRC KB Categories map to Zoho Desk Sections in the Help Center. If SRC uses a two-level category structure (parent category with subcategories), we map the parent to a Zoho Desk Section and subcategories to Sub-sections. Section creation must precede Article import so that the Section ID is available for the article record.

Attachments on SRC Service Requests and Incidents migrate to Zoho Desk Ticket Attachments. This requires resolving external repository references during discovery: if attachments are stored in OpenText Content Suite or another external system, we retrieve the files via the repository API before import and attach them inline to the parent ticket. If external references cannot be resolved, we document the broken links in a migration issues log and the customer resolves them manually post-migration. Zoho Desk imposes per-file and per-ticket attachment limits that we validate against during the attachment audit phase.

SRC Service Request custom fields map to Zoho Desk custom fields on the Ticket module. We audit the SRC custom field inventory during discovery, create equivalent custom fields in Zoho Desk scoped to the target department before migration, and map picklist values to Zoho Desk picklist options. Unsupported field types (e.g., SRC-specific data types with no Zoho Desk equivalent) are flagged and recreated as text fields with a note field documenting the original type.

SRC Incident custom fields map to separate custom fields on the Ticket module, distinguished from Service Request custom fields by API naming convention (incident_ prefix). We create incident-specific custom fields in Zoho Desk before migration and apply them to the Incident-department ticket layout so that only Incident-origin tickets expose these fields.

SRC SLA definitions (priority-tiered response and resolution targets tied to business-hour calendars) map to Zoho Desk SLA Policies scoped to the relevant department. During discovery, we audit the calendar assignments per SRC service category and map each to a Zoho Desk business-hours configuration. If a SRC calendar defines non-standard hours (e.g., 24/7 for critical infrastructure incidents), we configure a matching Zoho Desk business-hours entry or flag it as requiring a non-standard SLA policy that the customer's admin reviews before production migration.

SRC workflow definitions are tightly coupled to the platform's internal process engine and are not exportable in a portable format. We document the workflow logic for each Service Request and Incident type during discovery, including trigger conditions, routing rules, escalation stages, and notification actions. We deliver a written workflow inventory document with Zoho Desk Blueprint or macro equivalents for the customer's admin to rebuild. This documentation is included in the standard migration scope; active workflow rebuild is outside scope and is a separate engagement.

SRC Service Catalog items and request offerings are not exported as structured records. We extract catalog item metadata (name, description, category, associated SLA, request form fields) from SRC during discovery and deliver a catalog reconstruction guide with Zoho Desk form field equivalents for the customer's admin to rebuild the service catalog in Zoho Desk's Help Center.

SRC Service Request and Incident comments (including internal notes and public responses) map to Zoho Desk ticket threads. We preserve the author name, timestamp, and comment body. Internal notes from SRC map to Zoho Desk Private Comments with the isPrivate flag set. Thread ordering is preserved by sorting on the original SRC timestamp. Zoho Desk's thread model supports both public and private threads; we inspect the SRC comment visibility flag to determine the correct Zoho Desk thread type during migration.