Migrate from Support.ly by 500apps to Salesforce Service Cloud

Support.ly Tickets map to Salesforce Case as the primary helpdesk object. The ticket subject becomes Case Subject, ticket description becomes Case Description, ticket status maps to Case Status (Open, In Progress, Waiting on Customer, Closed), and priority maps to Case Priority. We resolve the linked Customer record to a Salesforce Contact and the Company record to an Account, attaching both as CaseContactId and AccountId respectively. Any incident management flags (escalation level, SLA breach indicators) map to Salesforce Entitlement and Milestone tracking if the destination org has Service Cloud with Entitlement Management enabled.

Support.ly Customer records map to Salesforce Contact. Contact name, email address, phone, and address fields migrate directly. We use the email address as the external ID for deduplication during import. The customer's ticket history attaches to the Contact via Case records. If the customer has no Company link in Support.ly, the Contact is created without an AccountId (person account not used unless specifically configured in the destination org).

Support.ly Company records map to Salesforce Account. Company name becomes Account Name, domain or website becomes the Account Website field, and address fields map to Account Billing Address. We use the company name as the external ID for deduplication. All Contacts linked to the same Company in Support.ly are attached to the same Account in Salesforce via AccountId lookup. If the destination org uses Person Accounts, individual-level companies without a separate contact structure are handled during scoping.

Support.ly Agent records map to Salesforce User by email match. We extract the agent list from the vendor export and resolve each against the destination org's User table. Agents without a matching User go to a reconciliation queue for the customer's admin to provision before Case import begins, because OwnerId is a required reference on Case records. Agent team membership maps to Salesforce Public Group or Queue membership based on the scoping choice between team-based routing and skills-based routing.

Support.ly Teams group agents for routing purposes. We reconstruct team membership in Salesforce as either Public Groups (for group-based visibility) or Queues (for case assignment routing). The customer selects the routing model during scoping: Omni-Channel with Skills-based routing is the destination-native approach; simple Queue-based assignment is the alternative. We document the mapping of each Support.ly team to its Salesforce equivalent in the handoff inventory.

Conversation threads on Support.ly Tickets migrate to Salesforce EmailMessage records linked to the Case. Each message in the thread becomes a separate EmailMessage with the original sender, recipient, body, and timestamp preserved. HTML formatting is preserved where supported; plain-text fallbacks handle content that does not render cleanly. The thread ordering is maintained by timestamp. If Support.ly stores internal notes separately from public replies, internal notes map to CaseComments with IsPublished set to false.

File attachments on Support.ly Tickets are downloaded from the vendor export package and uploaded to Salesforce as ContentVersion records, then linked to the parent Case via ContentDocumentLink. We preserve original filenames and attachment ordering. File size and format restrictions are documented during scoping; Salesforce limits individual file uploads to 25 MB per ContentVersion, and certain file types are blocked at the org level. Any attachments exceeding these limits are flagged for the customer's admin to store in an alternative location (Google Drive, SharePoint) with a link recorded on the Case.

Support.ly Tags are a flat tagging vocabulary applied to Tickets and KB articles. We migrate tags as Salesforce Case Tags (TopicAssignment records) or as a custom multi-select picklist field on Case, depending on the destination org's tagging strategy. The customer selects during scoping. We preserve the full tag vocabulary so that existing filter logic can be replicated in Salesforce List Views and Reports. Tag count and usage frequency are documented for the admin to prioritize which tags become filterable fields versus general classification.

Support.ly KB articles (title, body content, category assignment, and publication status) map to Salesforce Lightning Knowledge articles. We migrate article title, rich-text body, summary, URL name, and publication status. HTML complexity in article bodies is handled with a transformation pass that strips unsupported markup while preserving readable content. Articles are imported as a specific article type (ArticleType) configured in the destination org, with Data Category assignments mapped from Support.ly KB Categories. We flag whether the destination org uses Classic Knowledge or Lightning Knowledge during scoping because the migration tooling differs.

Support.ly KB Categories define the article navigation hierarchy. We reconstruct this hierarchy in Salesforce using Data Category Groups (top-level) and Data Category records (child levels). Category names migrate as-is; the customer renames any that conflict with existing Data Category naming conventions in the destination org. Articles are assigned to their target Data Categories during import, preserving the original browsing structure for agents who rely on category-based article discovery.

Survey and feedback data attached to Support.ly Tickets (CSAT scores, response text, NPS ratings) migrates as custom fields on Case or as a linked custom object depending on the data structure complexity. If Support.ly stores only a single satisfaction rating, we create a custom CSAT field (numeric or picklist) on Case. If the survey data includes multi-question responses, we create a custom CaseSurveyResponse object with a lookup to Case. The customer's Salesforce admin enables Field Audit Trail or Data Archive if survey history must be retained for compliance.

Support.ly custom fields on Tickets and Customers require field-level mapping against the destination Salesforce schema. Since 500apps does not publish custom field schema documentation publicly, we ask the customer to provide a sample record export or screenshots of the custom field configuration during discovery. From that sample, we identify field names, types (text, number, date, picklist, checkbox), and values, then create equivalent custom fields on the Salesforce Case or Contact object before migration. Picklist values migrate as-is with a mapping check for any values that exceed Salesforce's 500-value picklist limit per field.