Helpdesk migration
Field-level mapping, validation, and rollback between Helpdesk 365 and Salesforce Service Cloud. We move data and schema; workflows are rebuilt natively in Salesforce Service Cloud.
Helpdesk 365
Source
Salesforce Service Cloud
Destination
Compatibility
7 of 12
objects map 1:1 between Helpdesk 365 and Salesforce Service Cloud.
Complexity
CModerate
Timeline
4-6 weeks
Overview
Moving from Helpdesk 365 to Salesforce Service Cloud is a structural migration that restructures a SharePoint-backed ticketing system into a CRM-native service platform. Helpdesk 365 stores tickets, contacts, and companies in SharePoint lists with attachments as SharePoint document library URLs; Salesforce Service Cloud uses the Case object as the primary ticket record, Account for organizations, Contact for customers, and Salesforce Knowledge for articles. We extract Helpdesk 365 data through its REST API using paginated reads, resolve Helpdesk 365 agent and team references against Salesforce Users and Queues, and map custom fields within the Standard plan five-field cap if applicable. Automation rules, SLA policies, and routing logic in Helpdesk 365 do not migrate as configuration; we deliver a written inventory of these for the customer's admin to rebuild in Salesforce Flow or Omni-Channel. Attachments migrate as ContentDocument records linked to the parent Case or Contact, with the original SharePoint URL preserved as a custom field for reference during a transition window.
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.
Source platform
Helpdesk 365 platform overview
Scorecard, SWOT, gotchas, and pricing for Helpdesk 365.
Destination platform
Salesforce Service Cloud platform overview
Scorecard, SWOT, gotchas, and pricing for Salesforce Service Cloud.
Data migration guide
The complete Salesforce Service Cloud migration guide
Data model, import mechanisms, field mapping strategy, pitfalls, and cutover — by the engineers running it.
Destination checklist
Salesforce Service Cloud migration checklist
Pre- and post-cutover tasks for moving onto Salesforce Service Cloud.
Why teams make this switch
Leaving
What's pushing teams away
Choosing
What's pulling them in
Object mapping
Each row shows how a Helpdesk 365 object lands in Salesforce Service Cloud, including any object-level transformations, lookup resolution, or schema-design dependencies.
Typical mapping — final map is confirmed during the sample migration step.
Helpdesk 365
Ticket
Salesforce Service Cloud
Case
1:1Helpdesk 365 Tickets map directly to Salesforce Case. The ticket subject maps to Case Subject, ticket body and thread history map to EmailMessage records linked to the Case, ticket status maps to Case Status, priority maps to Case Priority, and assignee maps to Case OwnerId resolved via the User mapping. We preserve the original Helpdesk 365 ticket ID in a custom field h365_ticket_id__c for cross-reference during the transition window.
Helpdesk 365
Ticket
Salesforce Service Cloud
EmailMessage
1:manyHelpdesk 365 ticket conversation threads (agent and customer replies) map to Salesforce EmailMessage records. Each thread entry becomes a separate EmailMessage with the sender, timestamp, and HTML body preserved. We set the EmailMessage.parentId to the migrated Case ID and set the FromAddress and ToAddress based on the Helpdesk 365 contact and agent email fields.
Helpdesk 365
Contact
Salesforce Service Cloud
Contact
1:1Helpdesk 365 Contacts map to Salesforce Contact. Email address is the dedupe key. We map first name, last name, phone, and any custom fields on Contact. The Contact is created before the Case import so that the ContactId lookup on Case is satisfied at the moment of insert.
Helpdesk 365
Company
Salesforce Service Cloud
Account
1:1Helpdesk 365 Companies map to Salesforce Account. Company name maps to Account Name, domain maps to Account Website. Account is created before Contact import so that the AccountId lookup is resolved on Contact. We use the Account as the parent for any Contact records that reference the Helpdesk 365 Company.
Helpdesk 365
Ticket
Salesforce Service Cloud
Account
1:1Helpdesk 365 Tickets reference a Company (organization) that maps to Salesforce Account. We resolve the Helpdesk 365 company_id on each ticket to the migrated Account ID and set Case.AccountId accordingly. Tickets without a linked company map to the Contact's Account or remain unlinked until a customer admin confirms the correct Account assignment.
Helpdesk 365
Agent
Salesforce Service Cloud
User
1:1Helpdesk 365 Agent profiles (name, email, role, team) map to Salesforce User records. We match by email against the destination org's User table. Agents without a matching Salesforce User go to a reconciliation queue for the customer's admin to provision before Case import. The Helpdesk 365 agent role maps to a Salesforce Profile and Role assignment.
Helpdesk 365
Team
Salesforce Service Cloud
Queue
lossyHelpdesk 365 Teams map to Salesforce Queues. Each team becomes a Queue of type Case, and team membership (the agents assigned to each team) maps to QueueMembership. We configure the Queue before migration so that Case.OwnerId can be set to the correct Queue ID during import.
Helpdesk 365
Custom Field (Ticket)
Salesforce Service Cloud
Custom Field (Case)
lossyHelpdesk 365 custom fields on Tickets map to Salesforce custom fields on Case. If the customer holds Helpdesk 365 Standard, we verify during scoping whether the source system carries more than five custom fields; if so, we present a field-reduction plan before migration. Salesforce Professional and above support unlimited custom fields per object. Field type mapping follows Salesforce conventions: text to Text, dropdown to Picklist, date to Date, and checkbox to Checkbox.
Helpdesk 365
Knowledge Base Article
Salesforce Service Cloud
KnowledgeArticleVersion
1:1Helpdesk 365 KB articles (title, HTML body, category, publish status) map to Salesforce Knowledge ArticleVersion records. We transform the HTML body to Salesforce's article content format, map the Helpdesk 365 category to Salesforce Data Category, and set the article type based on the customer's Service Cloud configuration. Published articles migrate as Published version; draft articles migrate as Draft.
Helpdesk 365
Tag
Salesforce Service Cloud
Topic
lossyHelpdesk 365 tags on Tickets map to Salesforce Topics. We extract tag values during ticket extraction and create Topic records with the tag name, then create TopicAssignment records linking the Case to each Topic. Alternatively, if the customer prefers a flat label approach, tags map to a multi-select picklist on Case.
Helpdesk 365
Attachment (SharePoint URL)
Salesforce Service Cloud
ContentDocument
lossyHelpdesk 365 attachments are URLs pointing to SharePoint document libraries, not files stored inside the helpdesk. We extract the attachment URL from each ticket record and store it in a custom field h365_attachment_url__c on the Case for reference. If the customer wants the actual files migrated, we download from SharePoint using the stored URL and Microsoft Graph API, then ingest as ContentVersion and link via ContentDocumentLink. This requires the customer's SharePoint credentials and is scoped separately during discovery.
Helpdesk 365
Custom Object
Salesforce Service Cloud
Custom Object
1:1Helpdesk 365 custom objects migrate to Salesforce custom objects of equivalent API name. We pre-create the destination schema including all custom fields, lookup relationships to standard objects (Account, Contact, Case), and validation rules before any data import. Custom object API names in Salesforce use the __c suffix per platform convention.
| Helpdesk 365 | Salesforce Service Cloud | Compatibility | |
|---|---|---|---|
| Ticket | Case1:1 | Fully supported | |
| Ticket | EmailMessage1:many | Fully supported | |
| Contact | Contact1:1 | Fully supported | |
| Company | Account1:1 | Fully supported | |
| Ticket | Account1:1 | Fully supported | |
| Agent | User1:1 | Fully supported | |
| Team | Queuelossy | Fully supported | |
| Custom Field (Ticket) | Custom Field (Case)lossy | Fully supported | |
| Knowledge Base Article | KnowledgeArticleVersion1:1 | Fully supported | |
| Tag | Topiclossy | Fully supported | |
| Attachment (SharePoint URL) | ContentDocumentlossy | Fully supported | |
| Custom Object | Custom 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.
Helpdesk 365 gotchas
Standard plan caps custom fields at five
API key tied to admin user account
No documented bulk export endpoint
Salesforce Service Cloud gotchas
Data Export 512MB file size cap breaks large org exports
API Daily Request Limits vary by license edition
No automatic data backup in base Salesforce
Picklist dependencies silently break records when unmapped
Workflow rules fire unexpectedly during data load
Pair-specific challenges
Migration approach
Discovery and credential validation
We audit the Helpdesk 365 portal across plan tier (Standard with five-field cap or Enterprise), active custom fields, ticket volume, attachment count, agent roster, team structure, and knowledge base article inventory. We confirm the API key is generated from a stable service account, document the SharePoint library URL structure for attachment handling, and assess whether the customer holds the Microsoft Graph permissions required for SharePoint file download if files-as-ContentDocuments are in scope. The discovery output is a written migration scope, field-mapping table, and SharePoint file migration decision.
Schema design and Salesforce configuration
We design the destination Salesforce Service Cloud schema in a Sandbox org. This includes provisioning custom fields on Case and Contact (mapped from Helpdesk 365 custom fields), creating Queues for each Helpdesk 365 team, assigning Salesforce Profiles and Roles to match agent role hierarchies, configuring Salesforce Knowledge article types and data categories for KB migration, and disabling validation rules or adding migration-context bypass logic on Case. Schema deploys via change set or metadata API into Sandbox first.
Sandbox migration and reconciliation
We run a full migration into a Salesforce Sandbox using a representative data sample (at minimum 10 percent of total volume). The customer's Service Cloud admin reconciles record counts, spot-checks migrated Cases against original Helpdesk 365 tickets, validates that thread history appears correctly in Case EmailMessages, and confirms that attachment URLs are preserved. We correct any field mapping errors in Sandbox before scheduling the production migration window.
Agent and team reconciliation
We extract all distinct Helpdesk 365 agents from ticket assignee fields and match by email against the destination Salesforce org's User table. Agents without a matching User go to a reconciliation queue. The customer's Salesforce admin provisions any missing Users and assigns them to the correct Queues before production migration begins. Case OwnerId references cannot be set during migration if the User or Queue does not exist in Salesforce.
Production migration in dependency order
We run production migration in record-dependency order: Salesforce Users (validated), Accounts (from Helpdesk 365 Companies), Contacts (with AccountId resolved), Queues (with QueueMembership from team assignments), Cases (with ContactId, AccountId, OwnerId, and custom fields resolved), EmailMessage thread records (linked to parent Case), Knowledge Articles (with data category mapping), Topics and TopicAssignments (linked to Cases), and Custom Objects (last, because they often have lookups to standard objects). Each phase emits a row-count reconciliation report before the next phase begins.
Cutover, delta sync, and automation rebuild handoff
We freeze Helpdesk 365 writes during the final cutover window, run a delta migration of any records created or modified since the initial export, then enable Salesforce Service Cloud as the system of record. We deliver a written inventory of Helpdesk 365 automation rules, SLA policies, and routing logic with recommended Salesforce Flow and Omni-Channel equivalents. We support a one-week hypercare window for reconciliation issues. We do not rebuild Helpdesk 365 automations as Salesforce Flow inside the migration scope; that is a separate engagement.
Platform deep dives
Helpdesk 365
Source
Strengths
Weaknesses
Salesforce Service Cloud
Destination
Strengths
Weaknesses
Complexity grading
Moderate Helpdesk migration. 1 of 7 objects need a manual workaround.
Overall complexity
Moderate migration
Derived from compatibility, mapping clarity, API constraints, and data volume across Helpdesk 365 and Salesforce Service Cloud.
Object compatibility
1 of 7 objects need a manual workaround.
Field mapping clarity
Field mapping is derived from defaults — final spec confirmed during the sample migration.
Timeline complexity
7-object category — typical timelines run 2–7 days end-to-end.
API constraints
Helpdesk 365: Not publicly documented; Microsoft Graph throttling applies as the backend transport.
Data volume sensitivity
Helpdesk 365 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 Helpdesk 365 to Salesforce Service Cloud migration scoping. Not seeing yours? Book a call.
Walk through your Helpdesk 365 to Salesforce Service 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 Helpdesk 365
Other ways to arrive at Salesforce Service Cloud
Same-Helpdesk migrations
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.