CRM migration
Field-level mapping, validation, and rollback between The Service Manager and Salesforce Sales Cloud. We move data and schema; workflows are rebuilt natively in Salesforce Sales Cloud.
The Service Manager
Source
Salesforce Sales Cloud
Destination
Compatibility
12 of 12
objects map 1:1 between The Service Manager and Salesforce Sales Cloud.
Complexity
BStandard
Timeline
48–72 hours
Overview
The Service Manager organizes data around ITIL-aligned service-management concepts: Incidents, Problems, Changes, Service Requests, and Configuration Items organized in a class-inheritance model. Salesforce Sales Cloud organizes data around CRM concepts: Accounts, Contacts, Leads, Opportunities, and Cases with a RecordTypeId-keyed schema. The migration maps Incidents to Cases, Problems to Cases with a custom Problem_Reference__c link, Change Requests to Cases with a Type=Change pick-list value, and CIs to Salesforce's native Asset object or a custom Asset__c object for non-standard CIs. Automations, SLA policies, approval sequences, and ITIL workflow rules are Service-Manager-specific constructs that have no direct Salesforce equivalent — these must be rebuilt using Salesforce Flow, validation rules, and Omni-Channel routing. Knowledge articles can migrate to Salesforce Knowledge or remain as custom Article_Title__c and Article_Body__c fields. The migration runs via Salesforce Bulk API with a staged-record approach and a 24–48 hour delta-pickup window during cutover so your team keeps working in Service Manager until the moment of switchover.
Every standard and custom field arrives verified.
AI proposes the map; you confirm before any record moves.
Parent–child, lookups, and ownership stay linked.
Calls, emails, meetings — with original timestamps.
Documents, uploads, and inline notes move with the record.
Why teams make this switch
Leaving
What's pushing teams away
Choosing
What's pulling them in
Object mapping
Each row shows how a The Service Manager object lands in Salesforce Sales Cloud, including any object-level transformations, lookup resolution, or schema-design dependencies.
Typical mapping — final map is confirmed during the sample migration step.
The Service Manager
Incident
Salesforce Sales Cloud
Case
1:1Direct map. Service Manager incidents translate to Salesforce Cases with Incident_ID preserved as Source_System_ID__c for traceability. Priority and Urgency fields combine into Salesforce Case Priority using a value-mapping table. The Assigned_To technician resolves by email match to a Salesforce User record.
The Service Manager
Problem
Salesforce Sales Cloud
Case + custom Problem_Reference__c
1:1Service Manager Problems have no direct Salesforce equivalent. We create a Salesforce Case for each Problem with Type='Problem' and store the original Problem_ID as Problem_Reference__c so incident links remain queryable. Problem-Incident associations migrate as Related_Case__c custom lookups on the incident Cases.
The Service Manager
Change Request
Salesforce Sales Cloud
Case
1:1Change Requests map to Salesforce Cases with Type='Change'. The ITIL change lifecycle (Draft, Submitted, Approved, Scheduled, Implemented, Closed) maps to Salesforce Case Status values via a value-mapping table. Change-risk rating and change-type category migrate as custom pick-list fields. Each ITIL status is evaluated against your Salesforce pick-list configuration to ensure all values map correctly, and unmapped statuses are flagged for manual resolution before migration.
The Service Manager
Service Request
Salesforce Sales Cloud
Case
1:1Service Requests translate to Salesforce Cases with Type='Service Request'. The Service Catalog item identifier migrates as Catalog_Item_ID__c on the Case. Requested-Item details migrate as Description. If a Service Request includes an approval workflow, the outcome migrates as an Approval_Status__c field — the workflow itself must be rebuilt in Salesforce.
The Service Manager
CI (Configuration Item)
Salesforce Sales Cloud
Asset
1:1Standard CIs (servers, workstations, software instances) map directly to Salesforce Asset. CI class and type map to Asset.Name and a custom CI_Class__c pick-list. Parent-CI hierarchy maps to Asset.ParentAssetId for up to two levels of nesting. Deeper hierarchies require a custom CI_Relationship__c junction object.
The Service Manager
CI (non-standard / custom class)
Salesforce Sales Cloud
Custom Asset Object
1:1Non-standard CI classes in Service Manager (business services, applications, data entities) have no Salesforce native equivalent. We create a custom Asset__c object with custom fields for each CI property. The custom object name and plural label are configured before migration so field mapping targets the correct API name.
The Service Manager
Incident Attachment
Salesforce Sales Cloud
ContentDocument / Salesforce Files
1:1Service Manager attachments on incidents download and re-upload to Salesforce as Salesforce Files attached to the target Case. File size limits (Salesforce default 25MB per file) apply. Inline images in notes are extracted, downloaded, and rehosted as Salesforce Files with the ContentDocument linked to the Case.
The Service Manager
Work Note / Analyst Note
Salesforce Sales Cloud
EmailMessage on Case
1:1Service Manager work notes and analyst notes migrate as EmailMessage records on the Salesforce Case. Original author, timestamp, and note body are preserved. EmailMessage allows internal (IsExternallyShared=false) work notes to stay hidden from portal users in Salesforce. The IsExternallyShared flag is set based on Service Manager's note visibility settings to maintain appropriate access controls after migration.
The Service Manager
Knowledge Article
Salesforce Sales Cloud
Knowledge__kav or custom Article__c
1:1Service Manager knowledge articles can migrate to Salesforce Knowledge (requires Salesforce Knowledge license) or to a custom Article__c object. Article title, body, and categories map to custom fields. If migrating to native Salesforce Knowledge, DataCategoryGroup assignment requires pre-configuration in Salesforce before the migration wave runs.
The Service Manager
Support Group / Assignment Group
Salesforce Sales Cloud
Queue
1:1Service Manager assignment groups map to Salesforce Queues. We create Queues in Salesforce before migration and map the Group_ID to QueueId via a lookup table. Records assigned to a group rather than an individual land in the corresponding Queue, from which a Salesforce admin assigns them to a User.
The Service Manager
SLA Policy / Entitlement
Salesforce Sales Cloud
Entitlement Process + Milestone
1:1Service Manager SLA policies have no direct Salesforce equivalent. We preserve SLA name, business-hours definition, and first-response/resolve targets as custom fields on the Case. The Salesforce Entitlement Process must be configured manually post-migration to activate Salesforce-native SLA tracking. During migration, we store all SLA metadata in custom fields to maintain reporting continuity until your admin configures and activates the Entitlement Process in Salesforce.
The Service Manager
Service Catalog
Salesforce Sales Cloud
Custom Catalog_Item__c object
1:1Service Catalog items and offerings have no Salesforce native equivalent. We migrate catalog item name, description, category, and price as a custom Catalog_Item__c object. Item-to-request linkage is preserved via a Request_ID__c lookup. The catalog display UI must be rebuilt in Salesforce Experience Cloud if a self-service portal is needed.
| The Service Manager | Salesforce Sales Cloud | Compatibility | |
|---|---|---|---|
| Incident | Case1:1 | Fully supported | |
| Problem | Case + custom Problem_Reference__c1:1 | Fully supported | |
| Change Request | Case1:1 | Fully supported | |
| Service Request | Case1:1 | Fully supported | |
| CI (Configuration Item) | Asset1:1 | Fully supported | |
| CI (non-standard / custom class) | Custom Asset Object1:1 | Fully supported | |
| Incident Attachment | ContentDocument / Salesforce Files1:1 | Fully supported | |
| Work Note / Analyst Note | EmailMessage on Case1:1 | Fully supported | |
| Knowledge Article | Knowledge__kav or custom Article__c1:1 | Fully supported | |
| Support Group / Assignment Group | Queue1:1 | Fully supported | |
| SLA Policy / Entitlement | Entitlement Process + Milestone1:1 | Fully supported | |
| Service Catalog | Custom Catalog_Item__c object1:1 | Fully supported |
Gotchas + challenges
Platform-specific issues from each side, plus the pair-specific challenges that don't show up on either platform's page on its own.
The Service Manager gotchas
Dense service history causes export pagination failures
Custom fields on Work Orders differ by FSM version
Serialized asset cross-references break after migration
Parts inventory snapshot staleness at cutover
Salesforce Sales Cloud gotchas
Workflow Rules and Process Builder are retired
Bulk API batch quota exhaustion during large imports
Storage overage billing is non-obvious
Account-Contact many-to-many relationship mapping
Territory and team member import ordering dependencies
Pair-specific challenges
Migration approach
Stand up Salesforce schema first
Before any data moves, your Salesforce admin (or our team) creates the custom fields, pick-list values, custom objects (for non-standard CIs and knowledge articles), Queues for each Service Manager support group, and Entitlement Processes needed for the migration. We deliver a schema setup plan based on your Service Manager record counts, CI class count, change-type configuration, and knowledge-article structure so the Salesforce side is ready before validation runs.
Resolve owners, groups, and CI IDs by mapping tables
Service Manager Assigned_To technicians and Support Groups are resolved by email match against Salesforce Users and by ID match against pre-created Queues. CI IDs are mapped to the target Asset Salesforce IDs generated during the CI migration wave. We build a master mapping table during scoping and validate every foreign key resolves before the full migration wave commits. Unmatched owners and unresolved CI references are flagged and reported before the run so your team can resolve them in advance.
Sequence the migration: CIs first, then Cases, then attachments and notes
Salesforce requires Assets to exist before Cases can reference them via AssetId, and Cases to exist before EmailMessages can attach via ParentId. We sequence the migration in dependency order: (1) CIs → Assets, (2) Problems → Cases with Problem_Reference__c, (3) Incidents and Change Requests → Cases with resolved AssetId and OwnerId, (4) Service Requests → Cases, (5) Work Notes and attachments linked to Cases, (6) Knowledge articles if using Salesforce Knowledge. Each wave completes full validation before the next begins.
Run a sample migration with field-level diff before full run
A representative slice migrates first — typically 200–500 records spanning incidents across priority levels, at least one change request, a CI with a parent-child relationship, and a knowledge article. We generate a field-level diff showing source value vs. destination value for every mapped field, plus a count reconciliation report. You verify Priority and Urgency merging, Asset hierarchy flattening, and Queue routing before the full run commits. Sample validation typically runs within 24 hours of schema setup.
Cut over with delta-pickup for in-flight records
The full migration runs against Salesforce. A delta-pickup window (typically 24–48 hours) captures any Service Manager records created or modified during the cutover so Salesforce reflects Service Manager's final state at go-live. Your team continues working in Service Manager during this window. Audit log captures every insert and update operation. One-click rollback is available if reconciliation fails — the rollback restores Salesforce to its pre-migration state and the migration can be re-run with corrected mapping.
Platform deep dives
The Service Manager
Source
Strengths
Weaknesses
Salesforce Sales Cloud
Destination
Strengths
Weaknesses
Complexity grading
Standard CRM migration. 1 of 8 objects need a mapping; the rest are 1:1.
Overall complexity
Standard migration
Derived from compatibility, mapping clarity, API constraints, and data volume across The Service Manager and Salesforce Sales Cloud.
Object compatibility
1 of 8 objects need a mapping; the rest are 1:1.
Field mapping clarity
Field mapping is derived from defaults — final spec confirmed during the sample migration.
Timeline complexity
8-object category — typical timelines run 2–7 days end-to-end.
API constraints
The Service Manager: Not publicly documented.
Data volume sensitivity
The Service Manager doesn't expose a bulk API — REST + parallelization used for high-volume runs.
Estimator
Rule-based pricing — no per-record fees, no manual quotes. Migrations over 2M records are scoped individually.
Step 1
Pick a category, then your source and destination platforms.
Category
FAQ
Answers to the questions buyers ask most during The Service Manager to Salesforce Sales Cloud migration scoping. Not seeing yours? Book a call.
Walk through your The Service Manager to Salesforce Sales Cloud migration with a real engineer — 30 minutes, free, written quote within 24 hours.
Book a free 30 minute consultationAdjacent paths
Other ways to leave The Service Manager
Other ways to arrive at Salesforce Sales Cloud
Ready when you are
Tell us record counts and timeline. We'll come back with a written quote inside 1 business day — no commitment, no sales pitch.
