Migrate from OASYS to Zendesk

OASYS Tickets map directly to Zendesk Tickets using the standard ticket ID as the external reference. We preserve ticket status (open, pending, resolved, closed), priority (low, normal, high, urgent), subject, description, and full status transition history. The created_at and updated_at timestamps migrate as Zendesk created_at and updated_at. Requester email and assignee resolve against migrated User records. Internal notes from OASYS become Zendesk public or private Comments depending on the visibility flag in the source export.

OASYS Customer records map to Zendesk Users with role = end-user (requesters) or agent depending on whether the record has ticket assignment history. We resolve by email as the dedupe key. Customer name, email, phone, and any custom properties map to the corresponding Zendesk User fields. If a Customer is associated with a Company in OASYS, we create the Organization first and link the User to it via the organization_id field in Zendesk.

OASYS Company records map to Zendesk Organizations. We preserve company name, domain, and any associated custom fields. Organization is created before User import so that the organization_id lookup is satisfied at the moment of User insert. Organizations also serve as the deduplication key when merging multiple OASYS accounts into a single Zendesk instance.

OASYS Agents map to Zendesk Users with role = agent or admin. We resolve by email against the destination Zendesk instance. If an agent in OASYS has no corresponding Zendesk User, we add them to a reconciliation queue for the customer admin to provision before record import. Inactive agents in OASYS migrate as inactive Zendesk Users to preserve historical assignment accuracy on tickets.

OASYS Teams map to Zendesk Groups. We audit team rosters and queue assignment rules during the discovery phase and create equivalent Groups in Zendesk before ticket migration. Agent-to-Group membership resolves at migration time using the agent mapping. Note that Zendesk Groups do not have a native hierarchy; nested team structures in OASYS flatten to top-level Groups with naming conventions that preserve the original relationship.

OASYS custom fields on Tickets map to Zendesk ticket fields (dropdown, text, numeric, checkbox, date). OASYS custom fields on Customers map to Zendesk user fields. We audit field types during discovery and flag any OASYS field types that do not have a direct Zendesk equivalent. These fields must be created in Zendesk Admin Center before data import, or the values are stored as plain text in a custom properties field. Multi-select picklists in OASYS map to Zendesk tag-based fields or multi-select custom fields depending on the customer's preference.

OASYS conversation threads (customer replies and agent responses attached to a Ticket) map to Zendesk Comments on the corresponding Ticket. We preserve full thread chronology by setting the Comment created_at timestamp to the original OASYS timestamp. Public vs. private visibility migrates from OASYS internal/external flags. Comment author resolves against the migrated User record. If the author is an inactive agent, we link to the inactive User record to maintain attribution.

File attachments on OASYS Tickets and Conversations are downloaded during extraction and validated against Zendesk's 50 MB per-file limit and supported file type list. Oversized files are flagged during the audit phase so the customer can decide whether to compress, re-upload manually, or exclude them. We re-upload attachments to Zendesk using the Attachments API and link them to the corresponding Comment or Ticket record. Inline images within comments migrate as separate attachments linked to the parent Comment.

Tags from OASYS Tickets and Customers migrate to Zendesk Tags. Zendesk Tags are case-sensitive and flat (no hierarchy), so tag names are preserved exactly as exported from OASYS. If OASYS uses a hierarchical tag taxonomy, we document it during scoping and the customer can reorganize in Zendesk post-migration. Tags used for reporting or workflow triggers in OASYS may need to be recreated as Zendesk views or triggers by the admin.

OASYS SLA rules use internal naming conventions and condition logic that do not export as structured data. We capture screenshots and written documentation of all SLA definitions during the audit phase, including response time targets, resolution time targets, and business hours definitions. Post-migration, we provide a written SLA configuration guide that maps each OASYS rule to the equivalent Zendesk SLA Policy configuration in Admin Center. The customer's Zendesk administrator rebuilds SLA Policies using the guide; this is a manual step not included in the automated migration scope.

OASYS allows multiple Customers to be associated with a single Company record. We preserve this association by creating the Organization first, then linking each migrated User to the Organization via the organization_id field. If a Customer in OASYS has no associated Company, we create an Organization named after the Customer's email domain as a default grouping.