Migrate from Awesome Support to Salesforce Service Cloud

Awesome Support tickets (post_type = 'ticket' in wp_posts) map to Salesforce Case records. The WordPress ticket ID becomes the Case CaseNumber or a custom field src_ticket_id__c for traceability. Ticket subject migrates to Case Subject, ticket status (wpas_status) maps to Case Status with custom status values created in Salesforce to match renamed labels from Awesome Support settings. Priority and product associations from postmeta keys wpas_priority and any WooCommerce/EDD product link migrate to Case Priority and a custom product reference field.

Public replies stored as wp_comments with comment_type = 'ticket_reply' map to Salesforce EmailMessage records linked to the Case via ParentId. The WhoId on EmailMessage references the Contact (or Guest Contact) created from the ticket submitter. Body content migrates as HTML with inline images preserved via ContentDocument re-upload. We preserve the original reply timestamp as EmailMessage.MessageDate for conversation timeline ordering.

Internal agent notes stored as wp_comments with comment_type = 'ticket_note' map to Salesforce Note records linked via ContentDocumentLink to the parent Case. The private flag is preserved in a custom field is_internal_note__c so the customer's admin can configure visibility logic in Salesforce. Private notes are not exposed to the end customer in either system.

WordPress users with the Awesome Support agent role map to Salesforce User records. We extract display_name, user_email, and the agent role designation from wp_usermeta. User provisioning is sequential: the customer's Salesforce admin creates matching active Users before the Case migration phase runs, because Case.OwnerId requires a valid Salesforce User lookup. Agents without a matching Salesforce User are held in a reconciliation queue.

Ticket submitters who are registered WordPress users (wpas_user_id in postmeta) map to Salesforce Contact records. The WordPress user_email and display_name become Contact Email and Name. We use Contact Email as the dedupe key during import to prevent duplicate Contact creation if the same user submitted multiple tickets. The Contact is created before the associated Case import so that Case.ContactId lookup is satisfied.

Guest ticket submitters lack a WordPress user account and appear only in ticket postmeta (wpas_user_email, wpas_user_name). We extract these values, create a Contact record with the IsGuestContact flag set, and link it to the Case. Email address is preserved as the dedupe key. If a guest later registers, the customer can merge or link the records manually in Salesforce.

Awesome Support custom fields use postmeta keys prefixed wpas_ or the active add-on namespace. We enumerate every distinct custom field key across all tickets during discovery, map each to a typed Salesforce Custom Field (Text, Number, Picklist, Date, Checkbox) on Case or a related Custom Object, and create the schema before migration begins. Add-on-gated fields (Gravity Forms, billing, WooCommerce product) are mapped to equivalent Salesforce fields with a note in the scope document identifying which add-on originally owned the data.

Tags stored as WordPress post terms (taxonomy = 'ticket_tag') migrate to Salesforce Case Labels or to a custom multi-select picklist field on Case, depending on the customer's preference. The customer selects tag strategy during scoping. Multi-select picklist values are migrated as delimited strings in a single field; Labels create Salesforce TopicAssignment records linked to the Case.

Attachments stored as WordPress media items linked to the ticket post type are extracted as URLs from wp_postmeta (wpas_attachments) and wp_posts guid fields. We validate each URL for a 200 response, re-upload valid files as Salesforce ContentVersion records, and link them to the Case via ContentDocumentLink. Files returning 404 or redirect errors are flagged in the reconciliation report with the source ticket reference for manual recovery from the original email thread or backup.

Satisfaction survey data (wpas_satisfaction_rating, wpas_satisfaction_feedback) is only present when the Satisfaction Survey add-on is active. We check for the add-on during discovery, and if present, map the rating to a custom Number field cs_satisfaction_rating__c and feedback text to a custom Text Area field cs_satisfaction_feedback__c on Case. If the add-on is inactive, this object is omitted from the migration scope with a note in the scope document.

Time tracking entries stored by the Time Tracking add-on exist in a custom table or postmeta namespace (wpas_timetracking_). Each entry includes agent ID, duration in minutes, and optional billing notes. We map these to a custom Time_Entry__c object with fields for Case lookup, Agent lookup, Duration__c (Number), and Billing_Notes__c (Text), or to custom fields on Case if the customer prefers a simpler schema. The choice is confirmed during scoping.

Awesome Support allows renaming default status labels via settings (e.g., renaming 'Open' to 'In Progress'). We read the current status label configuration from wp_options during discovery, map each renamed label to a corresponding Salesforce Case Status picklist value, and configure the Case Status picklist in Salesforce to match the renamed labels exactly. Agents see the same label names in Salesforce that they saw in Awesome Support.