Migrate from iTop to Salesforce Service Cloud

iTop UserRequest maps to Salesforce Case as the primary ticket object. We export title, description, requester_id (Contact lookup), service_id, priority, status, and assignee from iTop. The iTop requester_id resolves to a Salesforce Contact record by email match. Title maps to Case Subject, description maps to Case Description, and iTop status values (New, Assigned, Pending, Resolved, Closed) map to Salesforce Case Status picklist values that we configure during schema setup.

iTop Incident inherits from Ticket and includes caller, impacted_ci, and assignment fields. We export Incidents as Salesforce Cases with a custom field itop_incident_type__c = true to distinguish them from UserRequests in the migrated dataset. The impacted_ci reference resolves to the CI custom object or Account depending on whether the CI maps to a Salesforce custom record or an Account-level asset.

iTop ChangeRequest has no direct Salesforce standard object equivalent. We map ChangeRequest to a Salesforce custom object Change_Request__c with fields for type (normal/urgent/emergency), approval status, rollback plan, and impacted CIs. The approval statistics from iTop migrate as a custom field for manual reconciliation. ChangeRequest workflows and approval chains do not migrate and are documented separately for Flow rebuild.

iTop Services with linked SLA definitions map to Salesforce Entitlement records. We export service hierarchies and SLA names, then configure Salesforce Entitlements with Milestones that mirror the iTop response and resolution time targets. Service catalog structures in iTop do not migrate as-is because Salesforce has no native service catalog object; we recommend Salesforce Service Cloud's Entitlement Management or a custom Service Catalog Lightning component as the rebuild path.

iTop CMDB CI classes (Server, NetworkDevice, Application, Database, and any custom XML-defined CI classes) map to a Salesforce custom object CI__c with a custom CI_Type__c picklist. We preserve CI relationships (parent-child, logical connection, runbook links) as custom lookup fields on CI__c. Each custom iTop CI extension requires individual schema review during scoping. We do not map iTop CIs to standard Salesforce objects because the class naming and attribute schema differ fundamentally.

iTop Contacts map directly to Salesforce Contact. We export person details (name, email, phone, organization_id) and preserve organization linkage by resolving organization_id to the Salesforce Account mapping. The iTop contact person_id migrates as an external ID field itop_contact_id__c for dedupe and reconciliation.

iTop Organizations map to Salesforce Account. Organization hierarchies in iTop (parent-child org structures) map to Salesforce Account hierarchies. We use the iTop organization name as the Account Name and preserve the itop_org_id__c as an external ID for dedupe. If the iTop organization is also a CI (as a business service), we link the Account to the corresponding CI__c record.

iTop User accounts (login, role assignments, profile) cannot migrate as functional Salesforce Users because password hashes and authentication tokens are not portable. We export user metadata (name, email, profile, role) as a CSV with role-to-profile mapping. The customer's Salesforce admin provisions Salesforce User accounts before production migration, and we match by email during the migration run. Inactive iTop users migrate as Contacts with a custom flag user_recreated__c = false.

iTop allows custom class definitions via XML extensions that vary between instances. We export custom object data for any non-standard iTop classes and map each to a Salesforce custom object with matching field types. Each custom class schema requires individual review during scoping because we cannot auto-detect the meaning of custom fields. We flag any custom class that has no clear Salesforce equivalent for manual mapping decisions.

iTop attachments store files in a local file system path structure tied to object class and ID. We export attachment metadata (filename, size, linked object, file path) separately from the raw files. During Salesforce import, we re-upload files as ContentDocument records linked via ContentDocumentLink to the parent Case, Contact, Account, or CI__c record. File URLs from iTop are not preserved because they reference the source file system.

iTop FAQ and KB articles have title, content, and category fields. We export article content in structured format and import into Salesforce Knowledge as KnowledgeArticle records. Category structures in iTop do not map directly to Salesforce Knowledge data categories; we recommend a manual category mapping as part of the post-migration Knowledge setup. KB article visibility (public, internal) requires manual configuration in Salesforce Knowledge.