Helpdesk migration
Field-level mapping, validation, and rollback between Desky and HubSpot Service Hub. We move data and schema; workflows are rebuilt natively in HubSpot Service Hub.
Desky
Source
HubSpot Service Hub
Destination
Compatibility
9 of 12
objects map 1:1 between Desky and HubSpot Service Hub.
Complexity
BStandard
Timeline
2-4 weeks
Overview
Desky lacks a documented public API, so we export via its admin-level CSV path and import into HubSpot Service Hub's REST endpoints. We migrate Tickets, Agents, Customers, and Companies with their associations intact, then handle Knowledge Base Articles through HubSpot's dedicated KB Importer with HTML formatting verified post-transfer. Attachment files stored as URLs in Desky are downloaded in a pre-migration pass and re-uploaded to HubSpot as ContentDocument records linked to the parent Ticket, Contact, or Article. Custom ticket fields from Desky map to HubSpot custom properties with type translation. Workflows, automations, routing rules, SLA policies, and Reports do not migrate; we deliver a written inventory of every automation requiring rebuild in HubSpot so the customer's admin can reconstruct them post-migration.
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
Desky platform overview
Scorecard, SWOT, gotchas, and pricing for Desky.
Destination platform
HubSpot Service Hub platform overview
Scorecard, SWOT, gotchas, and pricing for HubSpot Service Hub.
Data migration guide
The complete HubSpot Service Hub migration guide
Data model, import mechanisms, field mapping strategy, pitfalls, and cutover — by the engineers running it.
Destination checklist
HubSpot Service Hub migration checklist
Pre- and post-cutover tasks for moving onto HubSpot Service Hub.
Why teams make this switch
Leaving
What's pushing teams away
Choosing
What's pulling them in
Object mapping
Each row shows how a Desky object lands in HubSpot Service Hub, including any object-level transformations, lookup resolution, or schema-design dependencies.
Typical mapping — final map is confirmed during the sample migration step.
Desky
Ticket
HubSpot Service Hub
Ticket
1:1Desky Tickets map to HubSpot Tickets with subject, description, status, priority, source, and created/updated timestamps migrated 1:1. Desky's conversation thread (agent and customer replies) migrates as Ticket conversations in HubSpot. Custom ticket fields are detected during source scan and mapped to HubSpot custom properties by type (string, number, date, select). We batch-validate conversation body lengths against HubSpot's 10,000-character long-text field limit and flag any records exceeding it for truncation review before import.
Desky
Agent
HubSpot Service Hub
User
1:1Desky Agent accounts migrate to HubSpot Users with display name, email, role, and active/inactive status preserved. We resolve Agents by email match against the HubSpot destination portal; any Desky Agent without a matching HubSpot User is placed in a reconciliation queue so the customer's admin provisions the seat before record import proceeds. Agent seat count is verified against the destination HubSpot plan's user limit during scoping.
Desky
Customer
HubSpot Service Hub
Contact
1:1Desky Customer records map to HubSpot Contacts with first name, last name, email, phone, and company association preserved. The Company lookup is resolved at migration time using the Desky customer-company link to establish the Contact-Company association in HubSpot. Custom contact properties are detected during source scan and mapped to HubSpot custom properties.
Desky
Company
HubSpot Service Hub
Company
1:1Desky Company records migrate to HubSpot Companies with name, domain, description, and any associated custom properties. The Company record is inserted before Contact import so that the Contact-Company lookup relationship is satisfied at the moment of Contact insert. All Customer associations linked to the Company in Desky are re-established as Contact-Company links in HubSpot during the Contact migration phase.
Desky
Knowledge Base Article
HubSpot Service Hub
Knowledge Base Article
1:1Desky KB Articles migrate to HubSpot Knowledge Base with title, body content, publication status, category/folder, and tags preserved. HTML formatting present in Desky article bodies carries over, but inline images embedded in HTML require manual re-embedding post-migration since HubSpot's KB migration path does not support inline image transfer. We recommend using HubSpot's pre-built Knowledge Base Importer for article counts above 200 articles. Article body HTML is verified in a post-import QA pass, and any broken image references are flagged in the handoff report.
Desky
Tag
HubSpot Service Hub
Tag
1:1Tags attached to Tickets and Articles in Desky migrate as HubSpot Tags and are re-applied to the corresponding migrated Tickets and Articles. Tags are stored as string values during migration and re-associated to the target objects after the parent record inserts complete.
Desky
Custom Ticket Field
HubSpot Service Hub
Custom Property (on Ticket)
lossyDesky custom ticket fields are detected during source schema scan. We create matching HubSpot custom properties before ticket migration begins. String, boolean, number, and date field types map directly. Select (single-choice) and multi-select types require HubSpot admin review of picklist values during scoping; we configure picklists in HubSpot based on the Desky field options before import and flag any Desky fields with unmapped option values for resolution.
Desky
Attachment
HubSpot Service Hub
ContentDocument (via File Upload)
1:1Desky stores ticket and article attachments as file references in its CSV export, with URLs pointing to hosted files rather than binary blobs. We download all referenced attachment files in a pre-migration pass, preserving original filenames and MIME types. Files are uploaded to HubSpot as ContentDocument records and linked via ContentDocumentLink to the parent Ticket, Contact, or Article. Tickets with more than 10 attachments are flagged during scoping so the customer can decide whether to proceed with automated re-attachment or handle those records manually.
Desky
Ticket Conversation
HubSpot Service Hub
Ticket Conversation
1:1Desky ticket conversation threads (customer replies, agent responses, internal notes) migrate as HubSpot Ticket conversations. Public replies become public ticket responses; internal notes flagged as private in Desky are migrated as internal ticket notes. Author attribution resolves by matching the Desky agent or customer email to the migrated HubSpot User or Contact.
Desky
Ticket Priority
HubSpot Service Hub
Ticket Priority
lossyDesky priority values (Low, Medium, High, Urgent) map to HubSpot ticket priority by name match. We configure HubSpot ticket priorities during the schema setup phase if the destination portal does not already have matching priority labels.
Desky
Ticket Status
HubSpot Service Hub
Ticket Pipeline Stage
lossyDesky ticket status values map to HubSpot ticket pipeline stages. We create a HubSpot Ticket Pipeline during schema setup that mirrors the Desky workflow (Open, Pending, Resolved, Closed) and assign status values to the corresponding pipeline stages. The customer can adjust stage names during scoping to align with HubSpot best practices.
Desky
Multi-Channel Source
HubSpot Service Hub
Ticket Source
1:1Desky multi-channel ticket sources (email, chat, web form, API) migrate as HubSpot ticket source values. Source values are preserved as string labels; any Desky source type that has no matching HubSpot source value is created as a custom ticket source property during schema setup.
| Desky | HubSpot Service Hub | Compatibility | |
|---|---|---|---|
| Ticket | Ticket1:1 | Fully supported | |
| Agent | User1:1 | Fully supported | |
| Customer | Contact1:1 | Fully supported | |
| Company | Company1:1 | Fully supported | |
| Knowledge Base Article | Knowledge Base Article1:1 | Fully supported | |
| Tag | Tag1:1 | Fully supported | |
| Custom Ticket Field | Custom Property (on Ticket)lossy | Fully supported | |
| Attachment | ContentDocument (via File Upload)1:1 | Fully supported | |
| Ticket Conversation | Ticket Conversation1:1 | Fully supported | |
| Ticket Priority | Ticket Prioritylossy | Fully supported | |
| Ticket Status | Ticket Pipeline Stagelossy | Fully supported | |
| Multi-Channel Source | Ticket Source1: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.
Desky gotchas
No publicly documented API complicates programmatic migration
Furniture product and software product share the same brand name
Attachment handling requires manual re-attachment
HubSpot Service Hub gotchas
Rate limits throttle large migration API calls
Side conversations and Zendesk macros have no HubSpot equivalent
HubSpot stores ticket history as fragmented engagement objects
Custom Objects require Enterprise tier in HubSpot
Ticket pipeline stage probability values do not export cleanly
Pair-specific challenges
Migration approach
Discovery and scoping
We audit the source Desky portal: agent count, ticket volume, custom ticket field definitions, KB article count with HTML complexity assessment, attachment URL inventory with per-ticket attachment counts, and any existing tag taxonomy. We confirm with the customer that they are migrating from the desky.support software product (not the furniture company of the same name) and establish a migration cutover date. The discovery output is a written migration scope including record counts per object, a list of KB articles containing inline images, a list of tickets exceeding 10 attachments, and a custom field mapping table with field types and picklist values.
Source data extraction and validation
We export Desky data using the admin-level CSV export. Ticket exports include header records and separate conversation thread records; we merge these into a unified ticket structure during the transform phase. Agent, Customer, and Company exports are validated for field-length compliance, encoding consistency, and email format correctness. KB article HTML is scanned for inline image tags (img src) and flagged for the post-migration re-embedding inventory. Attachment URL lists are validated for HTTP accessibility, and files are downloaded to local storage with filename and MIME type preserved.
HubSpot schema setup
We create the HubSpot Ticket Pipeline with stages mirroring the Desky workflow (for example: Open, Pending, Resolved, Closed). Custom ticket properties are created in HubSpot to match Desky custom fields by name and type. Picklist values for select and multi-select custom fields are configured in HubSpot from the Desky field options. The Knowledge Base folder and category structure is created in HubSpot to match the Desky article hierarchy. User seats are verified against the destination plan limit, and any missing HubSpot User accounts required for agent mapping are placed in a reconciliation queue for the customer's admin to provision.
Demo migration and reconciliation
We run a full migration into a HubSpot Sandbox or the production portal with a subset of records (typically 10-20% of total volume) to validate mapping correctness, reconcile record counts, and verify that conversation threads, custom fields, and attachments appear correctly. The customer reviews the demo results and signs off on mapping and data quality before the full migration begins. Any field mapping corrections, picklist value additions, or stage-name adjustments happen at this stage.
Full production migration
We execute the full production migration in dependency order: HubSpot Users (validated against the queue from step 3), Companies, Contacts (with CompanyId resolved), Tickets (with conversation threads merged, owner resolved by email match, and custom fields populated), Knowledge Base Articles (via HubSpot KB Importer or REST API depending on volume), Tags (re-applied to migrated Tickets and Articles), and Custom Ticket Fields (if not created during schema setup). Each object phase emits a row-count reconciliation report comparing source and destination record counts before the next phase begins.
Attachment re-upload pass
After primary data migration completes, we run the attachment re-upload pass. Downloaded files are uploaded to HubSpot as ContentDocument records, and ContentDocumentLink records are created linking each file to the parent Ticket, Contact, or Article. Tickets flagged with more than 10 attachments are excluded from the automated pass and reported separately for manual handling by the customer. Post-upload verification compares file count and MIME types against the original attachment inventory.
Cutover and automation handoff
We pause new ticket creation and activity in Desky, run a final delta migration of any records created or updated during the migration window, then hand over HubSpot Service Hub as the system of record. We deliver a written inventory of every Desky workflow, routing rule, automation trigger, SLA policy, and Report that does not migrate as part of the data scope, with each item described and a recommended HubSpot Service Hub equivalent noted. The customer's admin team rebuilds these items post-migration; this is a separate scope of work or an internal admin task. We provide a two-week hypercare window for reconciliation issues raised during initial live usage.
Platform deep dives
Desky
Source
Strengths
Weaknesses
HubSpot Service Hub
Destination
Strengths
Weaknesses
Complexity grading
Standard Helpdesk migration. 2 of 7 objects need a mapping; the rest are 1:1.
Overall complexity
Standard migration
Derived from compatibility, mapping clarity, API constraints, and data volume across Desky and HubSpot Service Hub.
Object compatibility
2 of 7 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
7-object category — typical timelines run 2–7 days end-to-end.
API constraints
Desky: Not publicly documented.
Data volume sensitivity
Desky 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 Desky to HubSpot Service Hub migration scoping. Not seeing yours? Book a call.
Walk through your Desky to HubSpot Service Hub migration with a real engineer — 30 minutes, free, written quote within 24 hours.
Book a free 30 minute consultationAdjacent paths
Other ways to leave Desky
Other ways to arrive at HubSpot Service Hub
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.