Migrate from ManageEngine ServiceDesk Plus to Salesforce Service Cloud

Requests map to Salesforce Case as the central ticket object. Standard fields (subject, description, status, priority, category, subcategory) map directly. Custom ticket fields are stored in a separate table in ServiceDesk Plus and require per-record detail API calls; we extract all custom field values during scoping and map each to a Salesforce custom field on Case. We resolve the technician assignment by email match to a Salesforce User record. Requester references resolve to the corresponding Salesforce Contact via the requester-to-contact lookup.

ServiceDesk Plus Requesters map to Salesforce Contacts. Name, email, phone, department, and site fields transfer directly. Requester-to-Request associations are preserved so that Cases in Salesforce are linked to the correct Contact via the ContactId field. We use the requester's email address as the dedupe key during import. If the destination org requires Contacts to be associated with Accounts, we create placeholder Accounts for requesters without an organizational mapping during migration.

ManageEngine Assets map to Salesforce Asset records. Fields including name, type, serial number, purchase date, vendor, and asset state transfer. Asset-to-Request associations (where a ticket references a configuration item) migrate as CaseAssetRelationship records linking the Case to the Asset. If the customer uses Salesforce Field Service, Asset records additionally link to Service Appointments. Asset discovery and scan history do not migrate as those are transient probe records.

ServiceDesk Plus Contracts map to Salesforce Contract records when the source Professional or Enterprise license includes the Contracts module. Contract vendor, start/end dates, terms, and cost transfer. Contract-to-Asset associations migrate as ContractAsset relationships in Salesforce. SLA terms embedded in ServiceDesk Plus Contract records do not activate as Salesforce Entitlement records; we document the SLA mapping gap for the customer's admin to configure post-migration.

ServiceDesk Plus Solutions (knowledge base articles) map to Salesforce Knowledge articles. Article title, content body, category assignments, and status migrate. Inline images and HTML formatting are preserved where the attachment extraction workflow successfully downloads the binary content. Solution Owner and Workaround type fields do not have direct Salesforce equivalents and are stored in custom Salesforce Knowledge fields for reference. Article approval workflows in ServiceDesk Plus do not migrate; we document the approval matrix for the admin to rebuild in Salesforce.

ServiceDesk Plus Problem records (ITIL Problem management entities that link multiple incidents) have no native Salesforce Service Cloud equivalent. During scoping we determine whether the customer wants Problems mapped to Cases with a custom Problem_Number__c field and manual linking, or whether they prefer to flatten Problem-linked incidents into standard Cases. We create a custom Case relationship or use a custom object (Problem__c) with a lookup to the primary Case if the destination org has the Service Cloud Einstein for Service ITSM data model or a partner CMDB. We document the chosen approach as a pre-migration decision item.

ServiceDesk Plus Change records capture change requests with approval workflows, risk assessments, and implementation plans. Salesforce Service Cloud has no native Change Management entity; we either map Changes to Cases with a custom type and status field capturing risk level and approval status, or we create a custom Change__c object with fields for risk, impact, and approval status. Approval Board configurations from ServiceDesk Plus do not migrate. We extract Change-to-Request associations and preserve them as linked Cases or custom relationship fields in the destination.

ServiceDesk Plus Release records track deployment packages and rollout checklists. These are an Enterprise-tier or add-on feature and have no direct Salesforce Service Cloud equivalent. We either flatten Releases into Cases with a custom Release__c type and schedule fields, or we create a custom Release__c object. Deployment checklists migrate as Salesforce Tasks or a custom Checklist__c object linked to the Release. Release templates and automated schedules do not migrate; we document the release calendar for the admin to reconfigure in the destination.

ServiceDesk Plus Projects track IT initiatives linked to requests and changes. If the destination Salesforce org includes the Salesforce Cloud for Projects app or a Project Management add-on, we map Projects directly. Otherwise we create a custom Project__c object with task lists migrated as Tasks and resource assignments resolved via User lookup. estimated_hours, actual_hours, estimated_cost, and actual_cost fields transfer with the field value limits documented during scoping (max estimated_hours 99999 per the ServiceDesk Plus SDP OP to OD migration limitations).

ServiceDesk Plus Service Catalog items define orderable services with request templates, approval workflows, and step-based fulfillment processes. Salesforce Service Cloud does not have a native service catalog equivalent. We map catalog item definitions to Salesforce Flow (for guided intake) or to a custom Catalog_Item__c object with approval configuration documented separately. Approval workflows and step-based fulfillment do not migrate; we deliver a written catalog mapping document for the admin to rebuild in Flow Builder.

Custom fields added to ServiceDesk Plus request forms are stored in a separate table and do not appear in the bulk REST API GET requests list response. We enumerate all custom field names and data types during scoping via the custom field API or UI schema report, then pre-create matching custom fields on the Salesforce Case object before migration begins. Each custom field requires a per-record detail API call in ServiceDesk Plus, which multiplies against the 60 req/min read throttle for large datasets. We batch these calls to stay within rate limits and implement retry logic with exponential backoff.

Attachments associated with ServiceDesk Plus Requests are stored as file references in the database and are not returned by standard bulk export. We extract attachment metadata (filename, size, type) from the request detail endpoint and download file binary content where the API permits. We re-upload files to Salesforce as ContentVersion records and link them to the migrated Case via ContentDocumentLink. Conversation threads (internal notes and public replies) are extracted via the request detail API and stored as Salesforce CaseComment or EmailMessage records on the Case.