Migrate from Awesome Support to Zendesk

Awesome Support Tickets are custom post types stored in wp_posts with post_type 'ticket'. We extract ticket ID, subject, status, priority, product association, created date, and modified date, then map them to Zendesk Ticket records via the POST /tickets endpoint. The original ticket ID is preserved in a custom Zendesk ticket field (original_ticket_id) for audit traceability. Status mapping uses the custom status labels read from wp_options at migration time.

Public replies on Awesome Support tickets are stored as WordPress comments with comment_type 'ticket_reply'. We map these to Zendesk Ticket Comments via POST /tickets/{id}/comments, preserving author (agent or end user), body text, and created timestamp. HTML-formatted reply content is stripped to plain text or preserved as-is based on the destination's content settings.

Internal notes in Awesome Support are stored as comments with comment_type 'ticket_note'. We map them to Zendesk private comments via the public=false flag on the comment API call. Private notes are not visible to end users in Zendesk. The agent identity is preserved from wp_comments comment_author and comment_author_email.

Agents in Awesome Support are WordPress user accounts with a specific role or capability added by the plugin. We extract wp_users (ID, user_email, display_name, user_registered) and map them to Zendesk Agents via the POST /users endpoint. We flag any agent who has no corresponding Zendesk user before migration and hold them in a reconciliation queue. Agents without an email address in wp_users are skipped with a note because Zendesk requires email.

Customers who are authenticated WordPress users submit tickets as the logged-in user. Their WordPress user record (wp_users) is extracted and mapped to a Zendesk End User via POST /users. We preserve the original WordPress user ID in a custom field for reference. The wp_users email and display_name become the Zendesk user name and email.

Guest ticket submitters have no wp_users entry. Their details are stored in ticket meta under wpas_user_email and wpas_user_name keys. We extract these values from wp_postmeta, create a Zendesk End User record with only an email and name, and link the ticket to that user. Guest users without an email address are flagged and held for admin review.

Awesome Support custom fields use the wpas_ prefix in wp_postmeta or a custom field add-on namespace. We enumerate all distinct custom field keys across all tickets during discovery, determine the field type (text, dropdown, checkbox, numeric, date), pre-create the corresponding Zendesk ticket field via the Ticket Fields API, then populate values during the ticket import. Dropdown values from Awesome Support become Zendesk dropdown options or tag fields depending on value cardinality.

Tags in Awesome Support are WordPress post terms in wp_terms joined via wp_term_taxonomy where taxonomy equals 'ticket_tag'. We export the full tag taxonomy and apply tags to Zendesk tickets via the tags array on the ticket create or update API call. Tags with apostrophes or special characters are URL-encoded during import.

Awesome Support allows renaming default status labels via the WordPress admin settings. The current label map is stored in wp_options. We read this map during discovery, then configure Zendesk ticket statuses to match the renamed labels. Custom statuses beyond the five defaults require Zendesk Enterprise plan with custom statuses enabled.

Attachments are WordPress media items associated with the ticket post. URLs are stored in wp_postmeta and point to the WordPress media library. We download each attachment from the WordPress URL, then upload it to Zendesk via POST /tickets/{id}/attachments. Attachments exceeding Zendesk's 50 MB per-file limit are flagged for splitting. Attachments that return HTTP 404 or redirect errors are logged with the original ticket for manual resolution.

Satisfaction survey results are stored in wp_postmeta under wpas_satisfaction_ keys when the Satisfaction Survey add-on is active. We extract the rating value (star score) and any feedback text, then post them to Zendesk via the Satisfaction Ratings API on the closed ticket. Migrations without this add-on produce zero satisfaction records — we confirm add-on status during scoping.

When the WooCommerce or EDD add-on is active, tickets are linked to specific products or orders via postmeta keys. Product names and order IDs are extracted and mapped to a Zendesk ticket text field or multi-select field depending on cardinality. True order-to-ticket linkage in Zendesk requires a Zendesk Sunshine or external object integration, which is documented as a post-migration configuration option.

Time tracking entries are stored in a dedicated add-on table or postmeta namespace (time tracking bundle). Each entry includes agent, duration in minutes, and optional billing notes. We export time entries as internal Zendesk comments formatted as '[Time tracked: X minutes] agent: notes', preserving the data in a queryable form. Native Zendesk time tracking (Zendesk Suite Premium) requires separate configuration post-migration.