Helpdesk migration
Field-level mapping, validation, and rollback between Deskpro and Salesforce Service Cloud. We move data and schema; workflows are rebuilt natively in Salesforce Service Cloud.
Deskpro
Source
Salesforce Service Cloud
Destination
Compatibility
7 of 11
objects map 1:1 between Deskpro and Salesforce Service Cloud.
Complexity
CModerate
Timeline
3-5 weeks
Overview
Moving from Deskpro to Salesforce Service Cloud is a migration from a purpose-built helpdesk to an enterprise CRM platform with integrated service capabilities. Deskpro separates individual customers (Peoples) from company records (Organizations) as distinct objects, and that hierarchy must map to Salesforce's Contact-Account model with explicit parent-child relationships. Tickets in Deskpro map to Cases in Salesforce, but the Case layout does not preserve threaded email conversations in the same way; long email chains may require restructuring as individual Case Comments. We discover custom ticket field schemas via Deskpro's reports API before mapping, preserve tag assignments on every imported ticket, and resolve the department-agent affiliation to Salesforce's Queue and User model. Knowledge Base articles migrate to Salesforce Knowledge with folder structure collapsed into a single-tier category hierarchy. Workflows, triggers, and SLA rules do not migrate as code; we deliver a written specification for the customer's admin to rebuild in Salesforce Flow. Deskpro's Professional or Enterprise tier includes a native Salesforce sync feature, but a full historical migration still requires the same bulk-export and transform approach we use for anyDeskpro cloud instance.
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
Deskpro platform overview
Scorecard, SWOT, gotchas, and pricing for Deskpro.
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 Deskpro 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.
Deskpro
Ticket
Salesforce Service Cloud
Case
1:1Deskpro Tickets map to Salesforce Cases as the primary support record. Deskpro ticket priority (urgent/high/normal/low) maps to Salesforce Case Priority. The ticket status pipeline (new/open/pending/resolved/closed) maps to Case Status values that we configure as a Status picklist in the destination org. Threaded email conversations in Deskpro do not concatenate into a single Case field in Salesforce; we split each message into an individual CaseComment record to preserve the full conversation history. Tag assignments on tickets migrate as a custom multi-select picklist field ticket_tags__c on the Case object.
Deskpro
Agent
Salesforce Service Cloud
User
1:1Deskpro agents map to Salesforce User records. We match agents by email address as the dedupe key against the destination org's User table. Agent department assignments in Deskpro map to a custom Department field on the Salesforce User or to a Queue membership, depending on how the customer's routing is structured. Agents without a matching Salesforce User are held in a reconciliation queue for the customer's admin to provision before the production migration phase begins.
Deskpro
Peoples
Salesforce Service Cloud
Contact
1:1Deskpro Peoples (individual end-users or customers) map to Salesforce Contact records. The email address on the Deskpro People record becomes the Contact Email and the dedupe key. We resolve the parent Organization relationship at migration time so that the Contact.AccountId field is populated from the matched Account record. Language and timezone preferences on Deskpro Peoples migrate to custom fields on Contact for agent routing logic in Salesforce.
Deskpro
Organizations
Salesforce Service Cloud
Account
1:1Deskpro Organizations map to Salesforce Account records. Organization name becomes Account Name, and the primary domain maps to the Account Website field. Accounts are migrated before Peoples so that the Contact.AccountId lookup is satisfied at insert time. If the Deskpro Organization has multiple associated Peoples, all Contacts receive the same AccountId parent reference, preserving the account grouping that Deskpro's Organization model provides.
Deskpro
Knowledge Base Folder
Salesforce Service Cloud
DataCategoryGroup (or Category)
lossyDeskpro Folders (the container level above Articles) map to Salesforce Knowledge Categories. If Deskpro uses a two-tier hierarchy (Category above Folder), we collapse it into a single Salesforce Knowledge category structure since Lightning Knowledge does not support an intermediate folder layer. We capture the full Folder-Section hierarchy as a JSON map in the migration deliverable so the customer's admin can rebuild the intended information architecture in Salesforce Knowledge data categories.
Deskpro
Knowledge Base Article
Salesforce Service Cloud
KnowledgeArticleVersion
1:1Deskpro Articles map to Salesforce KnowledgeArticleVersion records. Article publish status (published/draft/archived) maps to Salesforce publishstatus. Author attribution migrates to a custom field on the article. If Deskpro articles have multilingual variants, each language version migrates as a separate Salesforce KnowledgeArticleVersion record with the matching language locale code. Article attachments migrate as ContentDocument records linked via ContentDocumentLink.
Deskpro
Department
Salesforce Service Cloud
Queue or Profile-based routing
lossyDeskpro departments organize agents and tickets for team-based routing. We document the department structure and map it to Salesforce Queues (if the customer uses Omni-Channel) or Profile-based record assignment. Department-level SLA rules in Deskpro do not migrate as code; they are included in the written automation inventory delivered to the customer's admin for rebuild in Salesforce Flow or Entitlement Processes.
Deskpro
Tag
Salesforce Service Cloud
Multi-Select Picklist on Case
lossyDeskpro tags applied to tickets migrate as a custom multi-select picklist field on the Case object (ticket_tags__c). We extract the full tag vocabulary from Deskpro during scoping, pre-create the picklist values in Salesforce before migration, and assign the matching values to each Case during the import phase. If the tag count exceeds Salesforce's 500-picklist-value limit, we discuss alternative strategies such as Tags-as-Custom-Objects with the customer during scoping.
Deskpro
Custom Ticket Fields
Salesforce Service Cloud
Custom Case Fields
1:1Deskpro custom fields on tickets require schema discovery before mapping. We access the Deskpro reports API with a custom field prefix to capture field IDs, data types, and label names. Boolean, date, numeric, and picklist custom fields map to equivalent Salesforce Case custom fields. Free-text custom fields map to Salesforce Long Text Area fields. We flag any Deskpro custom fields that have no logical Salesforce equivalent (such as highly Deskpro-specific UI state fields) as candidates for exclusion or custom field mapping documentation.
Deskpro
Attachment
Salesforce Service Cloud
ContentDocument / Files
1:1File attachments on Deskpro tickets are downloaded to a staging bucket during export and re-uploaded to Salesforce as ContentDocument records linked to the parent Case via ContentDocumentLink. We preserve the original filename, MIME type, and file size. Very large attachments (over 25 MB per Salesforce limit) are flagged and either split or excluded with a written inventory for manual handoff. Inline images embedded in article body content are re-hosted to Salesforce's file storage with URL references updated in the migrated article body.
Deskpro
Workflow / Trigger
Salesforce Service Cloud
Flow (rebuild required)
lossyDeskpro automations including triggers, workflows, and SLA rules are not transferable between platforms due to differing automation engines. We document every active Deskpro workflow and trigger as a CSV specification with trigger conditions, actions, and delays. The customer uses this document to rebuild equivalent automation in Salesforce Flow. SLA rules in Deskpro map to Salesforce Entitlement Processes and Milestones if the destination org has Service Cloud with Salesforce Field Service or an equivalent entitlement add-on.
| Deskpro | Salesforce Service Cloud | Compatibility | |
|---|---|---|---|
| Ticket | Case1:1 | Fully supported | |
| Agent | User1:1 | Fully supported | |
| Peoples | Contact1:1 | Mapping required | |
| Organizations | Account1:1 | Fully supported | |
| Knowledge Base Folder | DataCategoryGroup (or Category)lossy | Fully supported | |
| Knowledge Base Article | KnowledgeArticleVersion1:1 | Fully supported | |
| Department | Queue or Profile-based routinglossy | Fully supported | |
| Tag | Multi-Select Picklist on Caselossy | Fully supported | |
| Custom Ticket Fields | Custom Case Fields1:1 | Mapping required | |
| Attachment | ContentDocument / Files1:1 | Fully supported | |
| Workflow / Trigger | Flow (rebuild required)lossy | 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.
Deskpro gotchas
Stat Builder ticket export hard-caps at 2500 records per query
On-premise to cloud migration can fail due to incompatible features
Custom fields on tickets require schema discovery before mapping
Rate limiting on Help Center API endpoints can throttle bulk reads
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 licensing review
We audit the Deskpro instance across tier (Team/Professional/Enterprise), ticket volume, People and Organization counts, Knowledge Base article count, active workflows and triggers, and custom field definitions. We pair this with a Salesforce edition analysis: which Service Cloud tier and add-ons does the customer need for their routing model, Knowledge base, and SLA requirements. We also confirm whether the destination org is an existing Salesforce production org (requiring namespace and field collision review) or a fresh Service Cloud deployment. The discovery output is a written migration scope document and a Salesforce edition recommendation with pricing context.
Custom field schema discovery and mapping design
We query Deskpro's reports API with a custom field prefix to capture all custom field IDs, data types, and label names on tickets and articles. We design the Salesforce Case custom field schema to match, including picklist value sets, data types, and any validation rule equivalents. This step is required before any data export begins; without schema discovery, custom field values migrate as plain text into standard fields, causing permanent data type loss. We deliver the complete field map and flag any Deskpro custom fields with no logical Salesforce equivalent.
Sandbox migration and reconciliation
We run a full migration into a Salesforce Sandbox (Full Copy or Partial Copy) using production-like data volume. The customer's support operations lead reconciles record counts (Cases in, Contacts in, Accounts in, Articles in), spot-checks 25-50 random records against the Deskpro source for accuracy, and reviews tag vocabulary and custom field values. If the customer is on an on-premise Deskpro instance, we verify the encryption key and incompatible feature audit have been completed before the sandbox run. The customer signs off the sandbox results before production migration begins.
Agent-to-User reconciliation and Salesforce permission setup
We extract every distinct Deskpro agent email address referenced on ticket records and match against the Salesforce destination org's User table. Agents without a matching Salesforce User are added to a reconciliation queue, and the customer's Salesforce admin provisions any missing Users. We also coordinate the Enable Audit Fields permission, Modify All Data permission set assignment, and Knowledge enablement (if migrating articles) with the customer's admin before the production migration date.
Production migration in dependency order
We run production migration in record-dependency order: Accounts (from Deskpro Organizations), Contacts (with AccountId resolved from the matched Account), Cases (with ContactId and OwnerId resolved), Knowledge Articles (Articles migrated last if they reference Contacts or Cases via Deskpro portal links), and Activity history if Deskpro tickets have embedded engagement records. Each phase emits a row-count reconciliation report before the next phase begins. Deskpro Stat Builder chunking (2,500-record batches) runs on a scheduled job with automatic backoff on rate-limit responses.
Cutover, validation, and workflow rebuild handoff
We freeze Deskpro writes during the cutover window, run a final delta migration of any records created or modified during the migration window, then enable Salesforce Service Cloud as the system of record. We deliver the Workflow and Trigger inventory CSV to the customer's admin team for rebuild in Salesforce Flow. We support a one-week hypercare window where we resolve any record mapping issues raised by the support team. We do not rebuild Deskpro workflows as Salesforce Flow inside the migration scope; that is a separate engagement or an internal Salesforce admin task.
Platform deep dives
Deskpro
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 Deskpro 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
Deskpro: Configurable per action in Admin > Data > Security; not publicly documented in requests-per-minute terms.
Data volume sensitivity
Deskpro 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 Deskpro to Salesforce Service Cloud migration scoping. Not seeing yours? Book a call.
Walk through your Deskpro 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 Deskpro
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.