Migrate from OpenText Service Request Center (SRC) to Zendesk

SRC Service Requests map to Zendesk Tickets with ticket type set to 'request'. The SRC request title maps to Zendesk subject, description maps to comment body, priority maps to priority field, and status maps to status. Service category from SRC becomes a custom ticket field or tag. We preserve the SRC Service Request ID in a custom field src_service_request_id__c for cross-reference audit.

SRC Incidents track IT infrastructure or service disruptions separate from user-initiated requests. We map to Zendesk Tickets with type = 'incident', preserving impact and urgency fields as custom ticket fields. SRC incident resolution notes migrate to Zendesk ticket comments. Incident-specific custom fields map to Zendesk custom ticket fields using the same discovery and type-equivalency audit as Service Requests.

SRC User records (internal support agents) map to Zendesk Agent accounts. We export display name, email, department, and role from SRC. Passwords cannot migrate; agents receive Zendesk setup instructions for initial login. Group memberships map to Zendesk Groups and we set default group assignment on the User record during migration.

SRC Customer records (external requesters distinct from internal Users) map to Zendesk End Users. Contact information including name, email, phone, and department migrates. The SRC Customer ID is preserved in a custom field src_customer_id__c. If the customer email matches an existing Zendesk Agent account, we flag for manual disambiguation to prevent requester-agent record collision.

Attachments inline with SRC ticket records migrate as Zendesk ticket comments with file attachments via the Zendesk Attachments API. Attachments stored in external OpenText Content Suite repositories require resolution during discovery: we scan for external references, retrieve files where accessible, and migrate them inline. Any Content Suite references we cannot resolve are documented as broken links for manual customer follow-up. Zendesk file size limits apply per attachment.

KB Articles in SRC map to Zendesk Guide articles via the Help Center API. Article HTML content requires sanitization before import: we convert HTML markup to Zendesk Guide's supported format, preserve heading structure and inline text formatting, and flag embedded images that reference external repositories for manual retrieval. Article-to-ticket associations are preserved by creating a Zendesk custom field that references the original SRC article ID. Zendesk Help Center API rate limits (200-2,500 req/min by plan) govern the import throughput.

SRC SLA configurations define response and resolution targets tied to priority levels and service categories. We export SLA definitions and map them to Zendesk SLA Policies with business-hours schedules. SRC calendar-based hours-of-operation definitions migrate as Zendesk Business Hours records. Any SLA targets that cannot be expressed in Zendesk SLA Policy format (due to complex calendar exceptions or conditional tiers) are flagged in the discovery report for manual configuration review.

SRC custom fields on Service Requests and Incidents require discovery audit to map to Zendesk custom ticket fields. We capture the SRC field name, data type, picklist values, and validation rules. SRC text fields map to Zendesk text or description fields; picklist fields map to Zendesk tagger or dropdown fields; date fields map to Zendesk date fields. Any SRC field types without a Zendesk equivalent (e.g., complex conditional validation rules) are flagged for manual recreation post-migration.

SRC Support Groups and team assignments define ticket routing and agent ownership. We export group membership, reporting hierarchies, and email routing aliases and recreate them as Zendesk Groups. The Zendesk Groups structure maps to SRC team definitions. Group-based email routing in SRC (e.g., [email protected] routing to a group inbox) requires manual configuration in Zendesk as a separate email or forwarding rule step.

SRC workflow definitions are tightly coupled to the internal ITSM process engine and are not exportable in a portable format. We document the workflow logic during discovery (trigger conditions, approval stages, escalation rules, and assigned actions) and deliver a written map of every active SRC workflow with recommended Zendesk Trigger or Automation equivalents. The customer's admin rebuilds the automation logic in Zendesk Admin Center post-migration. This is standard scope: we do not migrate workflows as executable code.