Migrate from Experia to Zendesk

Experia Tickets map to Zendesk Tickets. Standard fields (subject, description, status, priority, created_at, updated_at) map directly. Original Experia ticket IDs are stored in a Zendesk custom field original_experia_ticket_id__c for cross-reference. Custom ticket fields migrate to Zendesk custom fields pre-created in the Admin Center under Objects and rules > Tickets > Fields. We cannot confirm Experia's exact field schema without admin access, so discovery must include a field inventory export from Experia before migration begins.

Experia Customers map to Zendesk Users with role=end-user. Contact fields (name, email, phone, address) map to corresponding Zendesk user fields. The customer's Experia ticket history attaches to the User record in Zendesk via the ticket requester relationship. We resolve User duplicates by email during import and flag any Experia Customer with no valid email for manual review.

Experia Companies map to Zendesk Organizations. Organization name maps to name; domain or website maps to the external_id or domain field for dedupe. Multiple Experia Customers associated with a single Company link to the Organization in Zendesk via organization_id on the User record. We confirm the Experia Company-to-Customer relationship cardinality during discovery because multi-contact deduplication logic depends on it.

Experia Agents map to Zendesk Users with role=agent. Agent identity (name, email) maps directly; role assignment and permission levels map to Zendesk Agent permissions (light_agent, agent, admin). Role hierarchy depth in Experia is not publicly documented and requires verification during discovery. Agents must be provisioned in Zendesk before any ticket import because tickets require an Assignee (agent) reference.

Experia Teams map to Zendesk Groups. Team membership determines ticket routing in Experia; we map this to Zendesk Group assignment via the ticket Group field or business rules. Zendesk's Group model supports nested groups on Enterprise; we verify Experia's team hierarchy depth during discovery. Routing rules that assign tickets to Teams in Experia must be rebuilt as Zendesk business rules or triggers post-migration.

Message threads attached to Experia Tickets migrate to Zendesk Comments on the corresponding Ticket. Public comments from the requester map to Zendesk Comment with public=true; internal notes map to public=false. Author information (agent or customer) resolves to the Zendesk User record by email. Full conversation chain ordering is preserved by setting the Zendesk comment created_at to the original Experia timestamp. Attachment links within comments migrate as Zendesk comment attachments via the API.

Files attached to Experia Tickets or Conversations migrate to Zendesk Ticket Attachments. We use the Zendesk API (not CSV import) to preserve binary files and maintain the ContentDocumentLink relationship to the parent Ticket. Files exceeding 1MB may have been excluded from CSV exports in Experia; we attempt API-based extraction and flag any unretrievable files during discovery. Post-migration, we spot-check a sample of attachments to verify link integrity.

Experia Tags that categorize Tickets or Customers migrate directly to Zendesk Tags. Tag taxonomy and naming conventions may differ between the two platforms; we preserve Experia tag names as-is and note any conflicts with existing Zendesk tag patterns. If Experia uses tags for workflow triggers, we flag these during discovery because Zendesk tags do not automatically replicate Experia's automation behavior.

Experia custom ticket fields migrate to Zendesk custom ticket fields. We cannot confirm the Experia custom field schema without admin access; the customer must provide a field inventory listing field names, types (text, dropdown, checkbox, numeric, date), and any conditional requirements. We create matching Zendesk custom fields in the Admin Center before migration and map field values by ID rather than display name to avoid naming conflicts.

Experia workflow automation rules do not migrate as code. Triggers, automations, and SLA policies are Zendesk configuration objects that require manual rebuild in Zendesk Admin Center or via the Zendesk API post-migration. We deliver a written inventory of every active Experia workflow with its trigger conditions, actions, and a recommended Zendesk equivalent (trigger, automation, or SLA policy) so the customer's admin can rebuild them in Zendesk. This is outside standard migration scope.

Experia views that organize the agent queue do not migrate as code. Zendesk Views are created under Admin > Objects and rules > Views and define filters, sorting, and column visibility. We document Experia's view configuration (filters, sort order, visible columns) during discovery and provide step-by-step setup instructions for rebuilding each view in Zendesk. Views are not migrated via API because the underlying filter syntax differs between platforms.