Migrate from Request Manager to Zendesk

Request Manager Tickets map directly to Zendesk Tickets. Subject, description, priority, status, created_at, and updated_at migrate 1:1. We set the Zendesk ticket type (question, incident, problem, task) based on a type field added during scoping or default to 'question' for request-style tickets. The Zendesk Ticket ID is generated at insert time.

Requester records (submitting users with name, email, department, and contact details) map to Zendesk End User records. Email address is the dedupe key. We preserve the requester's department as a custom user field or map to an existing Zendesk Organization if departmental grouping is configured. Active status is set based on whether the Requester record was active in the source.

Request Manager approval chains with step-order, approver reference, approval status, and timestamp do not map to a single Zendesk object. We decompose the chain: the approvers themselves become Zendesk Agents (or Groups) assigned as ticket Assignees or CC'd Agents, and the approval workflow logic is documented as Zendesk SLA Policy conditions and escalation rules to recreate. The approval timestamp chain is preserved in a custom ticket field or in the ticket comment history.

File attachments on Request Manager tickets are extracted with filename, MIME type, and binary content. We upload to Zendesk via the attachments endpoint and link to the target Ticket by ID. Large file handling follows Zendesk's 50 MB per-file limit; files exceeding this threshold are flagged in the reconciliation report for customer review.

Ticket comments and internal notes map to Zendesk Comments. The author, timestamp, and body transfer directly. We set the Zendesk public attribute (true for requester-visible comments, false for internal notes) based on the Request Manager visibility flag. Rich text content is preserved as HTML in the comment body.

Request Manager priority values (Low, Medium, High, Critical) map directly to Zendesk Priority values with the same labels. We do not re-normalize priority scales unless explicitly requested. If the source uses a numeric priority score, we map it to a custom ticket field rather than overwriting the standard Priority dropdown.

Request Manager status values (Draft, Submitted, Under Review, Approved, Rejected, Closed) are mapped to Zendesk ticket status values (New, Open, Pending, Hold, Solved, Closed). The mapping is confirmed during scoping because each organization's Request Manager workflow states are custom. We preserve the original Request Manager status in a custom field for audit.

Organizations frequently add custom fields to Request Manager ticket objects. We extract the full custom field schema during scoping (field name, type, and all active values), then pre-create matching Zendesk custom fields in the target account before migration begins. Dropdowns map to Zendesk dropdowns, checkboxes to booleans, numeric fields to integers, and text fields to text. No two Request Manager deployments have identical custom field sets; every mapping is per-customer.

Department assignments on tickets or requester profiles are mapped to Zendesk Organizations. If the customer uses Zendesk's multiple-brand feature, department assignment may alternatively map to a Brand field on the ticket. The mapping choice is confirmed during scoping based on how Request Manager departments are used in the customer's reporting workflow.

Request Manager stores approval history as audit events tied to tickets. We extract each audit event (approver, action, timestamp, comments) and append them as private Zendesk comments on the ticket in chronological order, preserving the full approval audit trail for compliance and reference. This is the closest Zendesk equivalent to the structured audit log that Request Manager provides.