Migrate from ManageEngine ServiceDesk Plus MSP to Intercom

ManageEngine Requests map to Intercom Conversations. The Request subject becomes the Conversation name; Request description becomes the initial user message in the thread. We preserve the original created_at timestamp and the last modified timestamp on the Conversation. Request status (Open, Pending, Resolved, Closed) maps to Intercom conversation_state (open, closed). Priority is stored as a custom conversation attribute. The mapping resolves the Author by matching the Requester email to an Intercom User or Lead. Conversations with no associated Requester (system-generated) are attributed to an admin User we provision for migration purposes.

ManageEngine's threaded conversation history on a Request is the highest-risk migration object because the standard XLS export omits it entirely. We pull conversation threads via the REST API v3 using paginated requests with the rate-limit window respected (15 request creations per 10 seconds, 30 updates per minute). Each message in the thread becomes a separate Intercom Message record within the parent Conversation. The message author type (Requester reply vs Technician note) maps to message_type (user vs admin) in Intercom. Timestamps are preserved for conversation ordering. Notes and internal comments in ManageEngine become internal notes in Intercom Conversations with the note flag set.

ManageEngine Requesters (end-users who submit requests within an Account) map to Intercom Users if they have an email that exists in the destination workspace, or to Leads if they are imported as unqualified contacts. We use the Requester email as the dedupe key. First name and last name map directly. Additional Fields on Requester (phone, department, site) map to custom Intercom custom_attributes fields that we configure before migration. Any Requester without an email is flagged for manual review since Intercom requires a contact identifier.

ManageEngine Accounts (customer organizations in the MSP multi-tenant model) do not have a direct Intercom equivalent because Intercom operates in a single workspace. We recommend mapping each Account to an Intercom Team for agent routing accountability, or to Tags for segmentation. The choice depends on whether the MSP wants to route conversations by customer organization (Teams) or label them for reporting (Tags). We scope this decision during discovery. Customer Domains do not migrate from On-Premises to Cloud; this is a known ManageEngine constraint we flag during scoping.

ManageEngine Assets (IT and Non-IT workstations, network gear, software licenses, contracts) do not map to any native Intercom object. We export Assets via CSV using the Import template and create them as a custom Intercom custom_object with fields for asset name, type, serial number, and linked Account. However, the Request-Asset associations (which Assets were linked to which Requests) are lost in ManageEngine's own SDP-to-SDP migration guidance because Assets require a fresh scan in the new instance. We export these associations as a lookup table and provide it to the customer for manual re-linking post-migration.

ManageEngine Contracts are billing instruments tied to Accounts. We export Contract records via CSV and map them to an Intercom custom_object named Contract with fields for contract name, contract type, start date, end date, and associated Account tag. Contract billing rules and bill-rule configurations do not have an Intercom equivalent and must be re-established in the customer's billing system post-migration.

ManageEngine Solutions (Knowledge Base articles) map to Intercom Articles. We export via the dedicated KB export tool referenced in the ManageEngine PitStop community. The article title maps to the Intercom Article title; body content maps to the body with HTML formatting preserved where possible. Article author, creation date, and last updated date transfer directly. Collections in Intercom serve as the equivalent of Solution categories. Published status migrates as-is; draft Solutions remain drafts in Intercom pending the customer's editorial review.

ManageEngine Change Management records track CAB approvals, change types, and schedules. We export Change records via the standard request export path. Change-specific workflows, Approved Change Records, and CAB approval chains do not migrate. We create Change records as Intercom custom_objects with fields for change type, status, scheduled date, and approval state. The customer must rebuild Change workflows as Intercom rules or macros if the same approval-gated change process is required.

Problem records link to multiple Requests in ManageEngine. We export Problem records and their linked Request associations as a lookup table. Problem workflows and closure rules are not portable and must be reconfigured. The Problem record title and description migrate as an Intercom custom_object; the linked Request IDs are preserved in a custom attribute for reference.

Projects and Milestones (Enterprise tier) are exported as Intercom custom_objects with project name, status, start date, and end date. Task dependencies and milestone relationships are not preserved. We note that estimated_effort fields in ManageEngine have published maximum constraints (9999 days, 999 hours) that we validate against during the pre-scan phase; records exceeding these constraints are flagged for cleanup before migration.

Additional Fields on Requests are mapped to Intercom custom_attributes on the Conversation object. We pre-validate Additional Field values against ManageEngine's published maximum constraints (additional_cost up to defined limits, estimated_effort fields). Records with values exceeding constraints are flagged in a cleanup report before migration runs. Field data types are mapped to Intercom attribute types: text fields become string attributes, numeric fields become number attributes, date fields become date attributes.

SLA definitions, escalation policies, schedules, and notification rules are stored in the ManageEngine admin configuration layer with no documented export mechanism. We do not migrate SLA configurations. They must be defined fresh in Intercom or replaced with Intercom's SLA feature if the customer is on the Intercom Advanced Support plan. We provide an SLA requirements worksheet during planning that enumerates each original SLA tier, its response and resolution time targets, and the customer-facing SLA that Intercom should enforce.