Migrate from Awesome Support to Gorgias

Awesome Support Tickets are custom post types in wp_posts with post_type 'ticket'. We extract ticket ID, subject, status, priority, product association, creation date, and last-modified date. Status values map to Gorgias Ticket Status (open, pending, resolved, spam); custom status labels renamed in Awesome Support wp_options are resolved to their current label before mapping. Priority from wpas_priority postmeta maps to Gorgias Ticket Priority (low, normal, high, urgent).

Responses and internal notes are stored as wp_comments attached to the ticket post type. We query comment_type to distinguish public responses from private agent notes, then map public responses to Gorgias Message with channel 'email' and private notes to Message with channel 'note' (internal). The message body, author name, author email, and timestamp migrate. Comment order is preserved for conversation threading.

Agents are WordPress user accounts with the Awesome Support agent role or capability. We map wp_users (display_name, user_email, user_registered date) to Gorgias Agents, preserving email as the primary identifier. If an agent email already exists in the destination Gorgias account, we link rather than create a duplicate. Agent role (admin vs agent) maps to Gorgias Agent permission level.

Registered WordPress users who submitted tickets are mapped to Gorgias Customers using their wp_users display_name and user_email. We preserve the customer email, name, and registration date. Customer records are created before the ticket migration so that the customer association is satisfied at insert time.

Guest ticket submitters have no wp_users entry. We extract their email and name from ticket postmeta (wpas_user_email, wpas_user_name), create a Gorgias Customer record for each distinct guest email, and link it to the associated ticket. Guest customers without an email are flagged during scoping and handled on a best-effort basis using available postmeta fields.

Custom field values stored in ticket postmeta with wpas_ prefixes and any custom field add-on namespaces are enumerated per ticket. We map each distinct meta key to a Gorgias Ticket Property with a type matching the field value (text, number, checkbox, select). Properties unique to one or two tickets are flagged as sparse and optionally omitted; properties used across 80%+ of tickets are created as standard Ticket Properties for all tickets.

Tags are WordPress post terms from wp_terms joined via wp_term_taxonomy where taxonomy is 'ticket_tag'. We export the full tag list and apply each tag as a Gorgias Tag on the associated ticket. Tag count and tag assignment per ticket are preserved. If the destination Gorgias account already has tags with matching names, we link rather than duplicate.

Attachments are WordPress media items associated with the ticket post. We extract attachment URLs from wp_postmeta and re-upload each file to Gorgias as a Message Attachment linked to the ticket. Large media libraries (over 1,000 attachments) require batched re-upload with retry logic. We validate each URL during extraction and flag any that return 404 or redirect errors for the customer's admin to resolve from a backup source.

Satisfaction survey responses (star ratings and feedback text) are stored in postmeta with a wpas_satisfaction_ prefix, gated behind the Satisfaction Survey add-on. We export available survey data and map it to Gorgias Ticket CSAT Rating and message content. Not all installations have this add-on active; we confirm add-on status during discovery and only migrate survey data where present.

When the WooCommerce or EDD add-on is active, tickets are linked to specific products or orders via postmeta. We preserve the order ID, product ID, and order status as Ticket Properties in Gorgias so that the customer admin can re-link tickets to the Shopify order context during onboarding if the site migrates to Shopify alongside the helpdesk.

Time Tracking add-on entries are stored in a dedicated table or postmeta namespace with agent, duration, and billing notes. We export these as Internal Notes on the Gorgias ticket with a structured format (agent name, duration, date) so that billing audit trails are preserved even though Gorgias does not have a native time tracking module in the same structure.

Private notes are distinguishable from public responses by comment_type in wp_comments. We preserve the internal/private flag by mapping these to Gorgias Messages with channel 'note', ensuring they are not exposed to the end customer. The author agent, note content, and timestamp migrate. This mapping depends on the Private Notes add-on being active in the source installation.