Migrate from Startly to Salesforce Service Cloud

Startly Tickets map directly to Salesforce Cases. The Startly ticket status (open, pending, resolved) maps to Salesforce Case Status with a custom picklist reflecting the original lifecycle. Startly priority (low, medium, high, urgent) maps to Salesforce Priority. Assignee maps to Case OwnerId via User email lookup. Requester maps to Contact via email on the Case's ContactId. SLA configuration maps to Salesforce Entitlements and Milestones, recreated manually from an SLA reference document we produce during extraction.

Startly ticket conversation threads (customer and agent replies) map to Salesforce EmailMessage records linked to the parent Case. EmailMessage.Status, FromName, FromAddress, ToAddress, Subject, and TextBody migrate directly. We preserve internal notes as CaseComments or Chatter Case Feed posts depending on whether the original note was marked internal. Parent Case lookup is resolved at migration time using the Startly ticket ID carried through the import.

Startly Asset records map to Salesforce Asset. Asset.Name, Type, Status, InstallDate, and Location migrate directly. Assigned user maps to Contact or User via email lookup. Startly custom asset properties map to Salesforce custom Asset fields pre-created in the destination org. If the destination Salesforce edition does not include Field Service or Experience Cloud with asset management, we may recommend a custom Asset object or an AppExchange ITSM package.

Startly CMDB entries (servers, software, network devices) have no direct Salesforce standard object equivalent. We create a custom Configuration_Item__c object with fields matching the Startly CI schema: CI_Name__c, CI_Type__c, Status__c, IP_Address__c, Serial_Number__c, and Relationship_Type__c. CI-to-CI relationships and CI-to-Asset linkages are preserved as junction records on a Configuration_Item_Relationship__c junction object. If the customer licenses Field Service, CIs map to ServiceAppointment-related assets instead.

Startly Change Requests map to Salesforce Cases using a custom Record Type (Change_Request) so that Change Request workflows and statuses are isolated from standard incident Cases. Risk assessment, approval fields, and change scope from Startly map to custom Case fields (CR_Risk_Level__c, CR_Approval_Status__c, CR_Scope__c). The CMDB CI linkage from the original Change Request is preserved via lookup to the Configuration_Item__c object. Approval routing is not migrated as a Salesforce approval Process; it is documented in a reference sheet for rebuild in Flow.

Active Startly Users map to Salesforce Users by email. We resolve Startly owner references on Tickets, Assets, and Change Requests to Salesforce OwnerId during import. Inactive or disabled Startly accounts are flagged in a reconciliation report and excluded from import unless the customer explicitly requests them for historical completeness. Role and department from Startly map to Salesforce Role and Department on User.

Startly Projects bundle tasks, budgets, and time entries under a single record. Project metadata (name, status, description, start date, end date) migrates to a custom ITSM_Project__c object. Startly's project-level budget and profitability fields are flagged as requiring explicit mapping decisions because they have no standard Salesforce equivalent; we preserve the values in a supplemental CSV for the customer to re-associate with a Finance or ERP integration if needed.

Standalone Startly Tasks and Project-linked tasks map to Salesforce Task. Status, Priority, Subject, Description, and ActivityDate migrate directly. Task assignment resolves Startly owner to Salesforce User by email. If the task is linked to a Startly Project, we create a lookup from the Task to ITSM_Project__c using the project ID carried through import. Custom task properties map to custom Task fields pre-created in the destination.

Startly Time Entries track labor against Tickets and Projects. We create a custom Time_Entry__c object with fields for Startly_ticket_ID__c (lookup to Case), Startly_project_ID__c (lookup to ITSM_Project__c), Hours__c, Billable__c, and Description__c. Time entry IDs are not portable; they are recreated in Salesforce with references back to the original Startly IDs for audit. If the customer uses Salesforce Field Service, time entries may map to ServiceAppointments instead.

Startly SLA policies (response time, resolution time, business hours tied to priority) have no direct Salesforce equivalent that migrates as code. We extract all SLA configuration values as a structured reference document during extraction: the SLA name, the priority tier it applies to, response hours, resolution hours, and business hours definition. Your Salesforce admin recreates these as Entitlement Processes and Milestones scoped to the Case Record Type in Setup. The Startly SLA-to-priority mapping is preserved as a custom field on Case for reference until Entitlements are live.

Startly Knowledge Base articles migrate to Salesforce Knowledge with a custom article type matching the Startly category structure (How_To__kav, Troubleshooting__kav, Policy__kav). Article title, body content, and summary migrate directly. Article-to-category and article-to-service-catalog-item relationships do not survive migration as foreign keys; we extract each relationship independently and re-establish links in Salesforce Knowledge where the destination's category model supports the same relationship type. We document the original linkage for manual re-association.

Startly Service Catalog items (requestable services with associated forms, approval workflows, and KB article links) migrate as custom Service_Catalog_Item__c records with fields for Name, Description, Category__c, and KB_Article_ID__c. Approval routing rules and workflow triggers do not migrate as code; we document each catalog item's approval chain in a reference sheet for rebuild in Salesforce Flow or an AppExchange request-for-service tool.