Migrate from UserEcho to Salesforce Service Cloud

EchoDesk tickets migrate to Salesforce Case with full reply thread history reconstructed as Case Comments or EmailMessages linked to the Case. Status (Open, Pending, Resolved, Closed) maps to Case Status values we configure in the destination Salesforce org before migration. Priority, assignee, and custom fields transfer to corresponding Case Priority, OwnerId, and custom Case fields. We resolve UserEcho agent identifiers to Salesforce User records via email match during import. Original UserEcho ticket ID is preserved in a custom field ue_ticket_id__c for cross-reference.

EchoForum topics present a structural gap: Salesforce Service Cloud has no native feedback or ideas board. We convert EchoForum topics to Case records with a custom topic_category__c field holding the original forum category name, and a custom ue_vote_count__c field preserving the upvote score. EchoForum status values (planned, under review, completed, dismissed) have no native Salesforce equivalent and are stored in a custom ue_forum_status__c field. Comment threads reconstruct as nested Case Comments. Customers who need a native ideas portal should plan to deploy Experience Cloud Ideas after migration; we document the topic list for that rebuild.

EchoSmart articles migrate to Salesforce Knowledge if the destination org has the Knowledge feature enabled (available with Service Cloud Enterprise, Unlimited, or Knowledge add-on at $30/article/month). Article title, body content, category assignments, and publication status transfer to the Knowledge data model. Inline images download from UserEcho and re-upload as Salesforce ContentDocument records linked to the article. If Knowledge is not enabled in the destination, articles migrate as Cases with a custom kb_source__c flag and article body stored in Description, with a note recommending Knowledge deployment.

EchoChat sessions transfer to Salesforce Case records with the Origin field set to Chat and the chat transcript stored in the Case Description or as a linked EmailMessage record. Session timestamps, agent identifiers, and visitor identifiers preserve in custom fields ue_chat_started__c, ue_agent_id__c, and ue_visitor_id__c. Duration is calculated from transcript timestamps and stored in a custom ue_chat_duration_min__c field. EchoChat sessions without an attached customer profile are linked to a generic Contact or created as Cases on a placeholder Account determined during scoping.

UserEcho agent profiles (any user with moderation or helpdesk access) map to Salesforce User records by email address. The agent role and permissions are noted in a custom field ue_agent_role__c but do not directly set Salesforce Profile or Permission Set assignments; the customer's Salesforce admin provisions Profiles and Permission Sets based on role requirements post-migration. Agent seat counts scoped during discovery ensure the destination Salesforce org is licensed for the correct number of agents before migration begins.

UserEcho customer profiles (end-users who submitted tickets, forum posts, or chat sessions) map to Salesforce Contact records on the primary Account. We separate customer profiles from agent profiles during extraction to avoid importing customer-only users as Salesforce agents, which would inflate licensing costs. Customer activity counts (ticket count, forum post count, chat session count) transfer to custom Contact fields for reporting. Email address serves as the primary dedupe key; duplicates resolve to the most recent profile update.

Tags applied across EchoDesk tickets, EchoForum topics, and EchoSmart articles export as flat label sets with their object associations. In Salesforce, Tags apply at the record level and can be queried across objects via TagDefinition. We preserve the tag-to-record relationship using a junction mapping table during migration so that records retain their tag context in the destination. Tag naming convention is preserved as-is; no normalization is applied unless the customer requests it during scoping.

UserEcho's two-level KB and Forum category hierarchy has no direct Salesforce equivalent. We flatten the hierarchy into a custom text field category_path__c on the destination object (Case for forum topics, Knowledge Article for KB), storing the full path as 'Parent Category / Child Category' for readability. Parent-child relationships are noted in the migration inventory so that the customer can decide whether to rebuild a category tree in Salesforce Knowledge or in a connected CMS. No Salesforce category object is created as part of the standard migration scope.

Files attached to EchoDesk tickets, EchoSmart articles, and EchoForum posts download individually from UserEcho and re-upload to Salesforce as ContentDocument records linked via ContentDocumentLink to the parent Case, Knowledge Article, or record. Original filenames and MIME types preserve; inline images embedded in KB article body are extracted separately and re-hosted as ContentDocument records with the image URL updated in the article body. Attachment count and total size feed into the scoping estimate for migration duration.

UserEcho custom fields on EchoDesk tickets (text, number, date, dropdown) map to Salesforce custom fields on the Case object, created before migration begins. Field data types translate to Salesforce equivalents: text to Text(255) or Text Area, number to Number, date to Date, dropdown to Picklist. Required field constraints in UserEcho map to Salesforce Required validation rules on the custom field. If UserEcho is on the free plan at migration time, some custom fields may be inaccessible; we confirm the active plan tier and flag any data requiring a paid-plan feature to extract.

Historical timestamps from EchoDesk and EchoChat require Salesforce audit field configuration before import. The destination org's admin must enable 'Set Audit Fields upon Record Creation' and grant 'Update Records with Inactive Owners' to the migration user in Setup > User Interface. We use the Salesforce Bulk API to write CreatedDate, LastModifiedDate, and ClosedDate values directly; without this configuration, Salesforce ignores timestamp values on insert and sets them to the import time, losing the original creation and resolution dates that are critical for support SLA reporting.

EchoDesk workflow rules (auto-assignment, status escalation, email triggers) have no direct Salesforce equivalent in the data migration scope. We extract a written inventory of every active EchoDesk rule including its trigger, conditions, and actions, with a note on the recommended Salesforce Flow or Omni-Channel replacement. The customer's Salesforce admin or a certified Salesforce partner rebuilds these post-migration. We do not migrate workflow logic as code because the trigger models are structurally incompatible between platforms.