Migrate from SMART Service Desk to Salesforce Service Cloud

SMART Service Desk Requests are the core ticket object and map directly to Salesforce Case. We preserve Request ID, Status, Priority, Category, Requester (Name, Email, Department, Site), Assigned Technician, Request Type, and full conversation history (public replies and internal notes) as Case Comments or Chatter posts. SLA First Response and Resolution milestones migrate as Entitlement Milestones if Entitlements are active in the destination org. Request attachments migrate as ContentDocument records linked via ContentDocumentLink to the parent Case.

SMART Service Desk Problem records have no direct Salesforce standard equivalent; we map Problems to Case with a custom picklist field problem_type__c set to 'Problem' to distinguish them from standard Cases, preserving the Problem description, root cause, Impact, Urgency, Priority, Assigned Analyst Group, and Problem-Request linkage via a custom lookup field original_problem_id__c. Problem-to-Request associations are preserved as a custom junction object or as linked Cases with a parent-child relationship, depending on the destination org's data model.

SMART Service Desk Change records carry ITIL-specific lifecycle fields including Change Category (Standard, Normal, Emergency), Risk level, Impact level, and approval status. We map Changes to Case with custom fields change_category__c, risk_level__c, impact_level__c, and approval_status__c. Change ID sequences are regenerated post-migration without a configuration toggle, so original RITM-identifier-style names do not carry over unless you contact SMART Service Desk support before migration begins and request a workaround. We raise this during scoping and flag the contact-support step.

Release records in SMART Service Desk follow a scheduled deployment lifecycle with Planned Start, Planned End, Assigned Technician, and Status. We map Releases to Case with a custom picklist field record_type_label__c set to 'Release' and custom date fields release_planned_start__c and release_planned_end__c. Release-to-Change associations migrate as linked Case records with a custom junction relationship or as a custom Release__c object if the customer requires full release record fidelity in the destination.

SMART Service Desk Assets include workstation records, components, consumables, and allocation details. We map Asset Name, Serial Number, Asset Type, Location, Assigned User, and Current Status directly to Salesforce Asset fields. Component and consumable sub-types that do not map to standard Salesforce Asset Type values migrate as custom fields or to a custom Asset_Detail__c object, depending on the volume and complexity of sub-asset records.

SMART Service Desk Solutions are knowledge-base articles with title, body content, summary, category, and publication status. We map to Salesforce Knowledge ArticleVersion with article title, rich-text body, summary field, DataCategoryGroup assignment for routing, and publication status (Draft, Published, Archived). Articles linked to specific Requests or Problems migrate with the article URL preserved in a custom field and flagged for URL update post-import since links point to the SMART Service Desk instance.

Contract records in SMART Service Desk store vendor agreement terms, SLA tier, start and end dates, and associations to Requests or Assets. We map Contract Name, Type, Vendor Reference, Start Date, End Date, and Status to Salesforce Contract. Multi-document attachments migrate as ContentDocument records linked to the Contract. Contract associations to Assets are preserved via the Asset.ContractId lookup if both objects migrate concurrently.

SMART Service Desk Vendor records store contact information and associations to Contracts and Purchase Orders. We map Vendor Name, Contact Name, Phone, Email, and Vendor Type to Salesforce Account with a custom field vendor_type__c set to 'IT Vendor' or the appropriate classification. Vendor associations to Purchase Orders and Contracts migrate as linked records referencing the Account.

Purchase Orders in SMART Service Desk are linked to Vendors and contain PO Number, vendor reference, line items, total amount, and status. We map these to a custom Purchase_Order__c object with fields for po_number__c, vendor_reference__c (lookup to Account), total_amount__c, status__c, and line_items__c (as a custom related list or as a separate Line_Item__c custom object). PO associations to Assets or Contracts are preserved via custom lookup fields.

SMART Service Desk Categories form a taxonomy used to classify Requests, Problems, and Changes. We export the full category tree and recreate it in the destination using a custom picklist or custom metadata type (Category_Mapping__mdt) that preserves the hierarchy structure. Category assignments on migrated records reference the new destination values via a static mapping table. The category tree structure is documented as a separate deliverable for the customer's admin to configure as Data Categories in Salesforce Knowledge if relevant.

User records from SMART Service Desk (Name, Email, Department, Site, Role) map to Salesforce User records by email match. We flag inactive or deprecated accounts and do not provision new Salesforce Users during migration; the customer's admin provisions any missing Users before the migration window. Department-level role resolution differs between on-premises (requester's department) and cloud (request's own department field) in SMART Service Desk, which affects approval routing mapping. We detect the deployment variant during discovery and adjust the User-to-Queue and User-to-CaseTeam mapping accordingly.

Change Advisory Board membership is stored on SMART Service Desk Change records. We extract CAB members and their roles and present them as a CAB_Member__c custom object or as CaseTeamMember records in Salesforce. Members without an active SMART Service Desk login are silently omitted from export; we cross-reference all CAB member records against the user list during discovery and raise a flag for each member without a login, so the customer can provision accounts or document which CAB roles require manual re-population after go-live.