Migrate from ManageEngine ServiceDesk Plus MSP to Zoho Desk

Requests are the core ticket object in ServiceDesk Plus MSP and map directly to Tickets in Zoho Desk. We use the REST API v3 to pull full request payloads including status, priority, category, subcategory, requester reference, and account reference. The request_id becomes a custom field sdp_request_id__c in Zoho Desk for audit traceability. Status mapping follows: Open → Open, Pending → Pending, On Hold → On-Hold, Resolved → Resolved, Closed → Closed. Priority maps from Low/Medium/High/Urgent to Zoho Desk's Low/Normal/High/Critical.

Requesters represent end-users who submit requests within an Account. We map Requesters to Zoho Desk Contacts, using email as the dedupe key. First Name, Last Name, Phone, and Mobile map to the corresponding Zoho Desk Contact fields. The requester_is_primary_contact flag from ServiceDesk Plus MSP determines whether the Contact is flagged as Primary in Zoho Desk. Requesters without email addresses receive a generated placeholder email and are flagged for admin review.

Accounts are top-level customer organizations in the MSP model and map directly to Zoho Desk Accounts. Account Name, Account Site, Industry, and Phone migrate as written. We preserve the Customer Domains setting from ServiceDesk Plus MSP as a custom field original_domain__c for reference since Zoho Desk does not have an equivalent Customer Domains feature. The Account must be created before any Contact import so that the Account-Contact lookup is satisfied at insert time.

Conversation threads are not included in the standard XLS export from ServiceDesk Plus MSP. We pre-fetch all conversation records using the SDP MSP REST API v3 endpoint for request notes and comments with pagination, storing each thread entry with its request_id reference, author, timestamp, and body. These migrate as Zoho Desk Ticket Comments with the is_public flag preserved (customer-visible comments vs internal technician notes). Thread ordering is maintained via the original timestamp. This is the highest-risk object in the migration because the 15-request-creation-per-10-second rate limit on SDP MSP requires batch sizing and backoff handling.

Attachments are excluded from the XLS export and must be pulled via the REST API. We pre-fetch attachment metadata (filename, MIME type, size, URL) using paginated API calls, download each file to local storage, then upload to Zoho Desk using the Ticket Attachments API, linking each to the migrated ticket by sdp_request_id__c. Files exceeding Zoho Desk's attachment size limit are flagged for customer review. The total attachment volume is a key scoping input because large attachment sets can extend the migration timeline significantly.

IT and Non-IT Assets from ServiceDesk Plus MSP migrate to Zoho Desk Assets. Asset Name, Asset Tag, Serial Number, Asset Type, Purchase Date, and Vendor map to the corresponding Zoho Desk fields. The key caveat is that ServiceDesk Plus MSP asset discovery scans do not carry over; assets require re-association to tickets post-migration. We export the Request-Asset associations as a lookup table (request_id, asset_id) and re-link assets using Zoho Desk's Asset-Ticket association after the ticket migration completes. Customers should budget for post-migration verification of asset-linked tickets.

Contracts in ServiceDesk Plus MSP are billing instruments tied to Accounts, tracking contract type, start and end dates, billing frequency, and total contract value. We export contract records via the Contracts API endpoint and import to Zoho Desk Contracts with Account lookups resolved from the Account migration phase. Contract terms, billing rules, and SLA terms require manual verification post-migration because Zoho Desk's contract model has a different structure (Name, Number, Account, Start Date, End Date, Total Amount) and does not natively model MSP-specific billing tiers.

Solutions serve as the Knowledge Base for known errors and resolutions in ServiceDesk Plus MSP. We export Solutions via the dedicated KB export path referenced in the PitStop community documentation, then import to Zoho Desk Articles. Article Title, Summary, Details (rich text), Topic, and Published status map directly. Article-to-category mapping uses the Solution's topic structure as Zoho Desk Article categories. Draft status is preserved for unpublished solutions.

Change Management records in ServiceDesk Plus MSP (available in Enterprise tier) track CAB approvals, change type, risk level, and schedule. Zoho Desk does not have a native Change Management object, so Change records migrate as Tickets with a custom field change_type__c (Normal/Standard/Emergency), risk_level__c, and approval_status__c. Change-specific workflows and CAB approvals do not migrate and must be rebuilt as Zoho Desk Blueprint flows or documented as requirements for manual configuration.

Problem records in ServiceDesk Plus MSP link multiple Incidents/Requests to a root cause investigation. We export Problem records and their linked Request associations, then migrate Problems to Zoho Desk Tickets with a custom field problem_id__c and the original linked request IDs preserved as a text field linked_requests__c. Problem workflows and closure rules are not portable. If the MSP uses Problem Management as a formal ITIL process, we recommend rebuilding the Problem-Ticket linkage logic in Zoho Desk using custom fields and Blueprint flows.

Projects and Milestone Tasks in ServiceDesk Plus MSP are available in the Enterprise tier and map to Zoho Desk Projects if the destination account includes the Projects module (available in Zoho Desk Advanced and above). Project Name, Description, Start Date, End Date, Status, and Owner migrate. Milestone Tasks migrate as sub-tasks under the Project. We pre-validate estimated_effort fields against documented maximums (9999 days, 999 hours) and provide a cleanup report for any values that exceed Zoho Desk constraints before migration runs.

Additional Fields on Requests in ServiceDesk Plus MSP migrate to Zoho Desk Custom Fields on the Ticket object. We pre-scan field values against Zoho Desk type constraints (maximum length, picklist whitelist, numeric ranges) and flag violations before migration. Records created before a field constraint was tightened in ServiceDesk Plus MSP may contain values that exceed destination maximums; we provide a cleanup report for the customer to resolve these proactively. Field mapping is created during the configuration phase with field type translation (text → single-line, textarea → multi-line, checkbox → checkbox, picklist → picklist).

SLA definitions, schedules, and escalation rules in ServiceDesk Plus MSP are stored in the admin configuration layer with no export mechanism. Even the official SDP to SDP MSP migration guide acknowledges that SLAs must be recreated at the destination. We exclude SLA configurations from migration scope entirely and provide a requirements worksheet during the planning phase that captures each SLA name, business hours definition, first response and resolution targets, and escalation action for the customer to define fresh in Zoho Desk SLA Policies (available in paid tiers).

Automated workflows, approval chains, and notification rules in ServiceDesk Plus MSP are stored in the admin configuration layer with no export path. We do not migrate Business Rules as code. We deliver a written inventory of every active Business Rule in ServiceDesk Plus MSP with its trigger condition, actions, and a recommended Zoho Desk Blueprint or Macro equivalent, so the customer's admin can rebuild them post-migration. Approval workflows specifically require Zoho Desk's Blueprint feature which uses a different model (state-based transitions vs rule-condition-action).