Migrate from Awesome Support to HubSpot Service Hub

Awesome Support tickets (wp_posts with post_type 'ticket') map directly to HubSpot Tickets. Ticket ID becomes the subject prefix for traceability. Status, priority, and product association from wp_postmeta map to HubSpot Ticket status, priority, and custom properties respectively. We preserve the original ticket_created_date as a custom date property for chronological ordering. If the destination HubSpot account uses the Free tier, tickets ingest via the Tickets API with the default pipeline and status values.

Public ticket replies are stored as wp_comments with comment_type distinguishing agent responses from customer messages. We map each wp_comment to a HubSpot Conversation record attached to the parent Ticket. Comment body, timestamp, and author name transfer; we resolve the agent author to a HubSpot User by email match for conversation attribution.

Awesome Support private notes use comment_type='wpas_note' in wp_comments. We map these to HubSpot Conversations with the internal flag set so they are visible to agents but not exposed to the ticket submitter in the customer portal. The original note author and timestamp are preserved on the conversation record.

Agents are wp_users accounts with an Awesome Support role capability. We extract display_name, user_email, and user_login from wp_users and map them to HubSpot Users. The migration user requires the HubSpot Users API permission. If the destination has fewer seats than source agents, we map multiple Awesome Support agents to a single HubSpot User during scoping and document the reassignment.

Registered WordPress users who submitted tickets have a wp_users entry. We extract user_email, display_name, and any additional profile fields stored in wp_usermeta, then create HubSpot Contacts. The WordPress user_id is preserved in a custom property wpas_wp_user_id__c for cross-reference.

Guest submitters lack a wp_users entry. Their details live in wp_postmeta under wpas_user_email and wpas_user_name on the ticket post. We extract these, create HubSpot Contacts with the guest email and name, and link the Contact to the ticket. The guest flag is set in a custom property is_guest_submitter__c for segmentation.

Awesome Support custom fields store values in wp_postmeta with wpas_ prefixes or add-on-specific namespaces (wpas_cf_, wtas_, time_tracking_). We enumerate all custom field keys present across the ticket corpus during discovery, map each to a HubSpot Ticket custom property of the matching type (string, number, date, dropdown, checkbox), and create any missing destination properties before import. Picklist values in Awesome Support map to HubSpot dropdown or multi-select properties.

Tags live in wp_terms joined via wp_term_taxonomy where taxonomy='ticket_tag'. We extract the full tag taxonomy and apply each tag as a HubSpot Ticket Label. Labels are preserved as-is without transformation since both platforms support string-based tagging on tickets.

Awesome Support allows renaming default status labels (e.g., 'Open' renamed to 'In Progress') via wp_options. We read the current status label configuration during discovery, then configure matching Ticket Status values in the HubSpot destination pipeline before migration begins. Custom statuses added via the custom status add-on map as additional Ticket Status values.

Attachments are WordPress media library items linked to the ticket post. We extract attachment URLs from wp_postmeta (wpas_attachments), validate each URL returns HTTP 200, download the file, and re-upload it as a HubSpot Ticket attachment using the HubSpot Files API. Attachments larger than 25 MB require chunked upload handling. We flag any URLs returning 404 or redirect errors for customer-side resolution from the original email thread.

Survey results (star ratings and feedback text) live in wp_postmeta with wpas_satisfaction_ prefix when the satisfaction survey add-on is active. We export all survey entries, map them to HubSpot's native Feedback Survey feature, and link each survey submission to the corresponding Contact record by email. If the destination HubSpot account lacks a Feedback Survey add-on, survey results migrate as custom properties on the Ticket.

When the WooCommerce or EDD add-on is active, tickets carry product and order associations in wp_postmeta. We extract the associated product ID and order ID, map them to custom Ticket properties (product_id__c, order_id__c), and flag that these reference external WooCommerce records in the migration inventory so the customer's team can relink them post-migration if a WooCommerce-to-HubSpot integration is implemented.

Time tracking add-on entries store agent, duration, and billing notes in a dedicated table or postmeta with a time_tracking_ prefix. We export all time entries, aggregate total duration per ticket, and store as a custom numeric property total_time_logged__c in seconds on the HubSpot Ticket. Individual time entries are preserved in a migration inventory spreadsheet for the admin to rebuild in HubSpot Timer or a third-party time-tracking integration.

Awesome Support pipelines are configured in wp_options. We read all pipeline definitions, map each to a HubSpot Ticket Pipeline with matching status stages. If the customer uses multiple pipelines in Awesome Support, each becomes a separate HubSpot Ticket Pipeline, which are available from HubSpot Starter tier onward.