Helpdesk migration
Field-level mapping, validation, and rollback between TOPdesk and Zendesk. We move data and schema; workflows are rebuilt natively in Zendesk.
TOPdesk
Source
Zendesk
Destination
Compatibility
10 of 12
objects map 1:1 between TOPdesk and Zendesk.
Complexity
BStandard
Timeline
2-3 weeks
Overview
Moving from TOPdesk to Zendesk requires mapping a structured ITSM data model (Calls, Changes, Assets, People, and Operators) onto Zendesk's cloud-native ticket and user architecture. The two platforms diverge most critically on asset management: TOPdesk's Asset Management module stores hardware, software, licences, and network components with a full parent-child hierarchy, while Zendesk requires either the Zendesk Suite Enterprise asset add-on or a custom object built during schema preparation. We pre-create the custom asset object and recursively traverse the TOPdesk asset hierarchy to preserve dependencies in the destination. Change records require a custom field to retain TOPdesk's Simple Change, Extensive Change, and Request for Change classification, because Zendesk uses a single ticket model. We do not migrate TOPdesk Workflows, Sequences, or Activity Templates as code; we deliver a written inventory for the customer's admin to rebuild in Zendesk.
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 TOPdesk object lands in Zendesk, including any object-level transformations, lookup resolution, or schema-design dependencies.
Typical mapping — final map is confirmed during the sample migration step.
TOPdesk
Calls
Zendesk
Ticket
1:1TOPdesk Calls (both incidents and service requests) map directly to Zendesk Tickets. The Call status field maps to Zendesk Ticket Status (New, Open, Pending, On-hold, Solved, Closed). Priority, category, and branch assignment from TOPdesk map to custom ticket fields in Zendesk. Custom fields of type text, number, dropdown, date, and checkbox map to Zendesk custom fields of the corresponding type. Call notes and activity history migrate as ticket comments, with internal notes preserved as private Zendesk comments.
TOPdesk
People
Zendesk
User
1:1TOPdesk People records (requesters who submit calls) map to Zendesk Users with the End-user role. The person_id maps to the Zendesk user id, email to the primary email field, and the branch or department field maps to a custom user field (e.g., topdesk_branch__c). If a TOPdesk person also appears as an operator, we create one Zendesk user record and set the Agent role.
TOPdesk
Operator
Zendesk
User (Agent role)
1:1TOPdesk Operators (the agents who handle calls) map to Zendesk Users with the Agent role. Operator authorization templates and branch assignments map to custom user fields. The operator branch and department structure from TOPdesk is preserved as a custom field and optionally as Zendesk Group membership if the group names align with TOPdesk branches. We resolve operators by email match and hold unresolved operators in a reconciliation queue for the customer's admin to provision before record import.
TOPdesk
Change
Zendesk
Ticket (custom change_type field)
1:1TOPdesk Changes (Simple Change, Extensive Change, Request for Change) map to Zendesk Tickets with a custom field (change_type__c) storing the TOPdesk change classification. Authorization activities from TOPdesk become internal comments on the Zendesk ticket, preserving the activity log. The original TOPdesk change template type (status=1 or status=2) is stored in a separate custom field (change_template_type__c) for audit traceability. Changes that reference TOPdesk People as submitters and Operators as assignees require those user records to exist in Zendesk first.
TOPdesk
Assets (Hardware, Software, Licence, Network Component)
Zendesk
Custom object (e.g., IT_Asset__c)
1:1TOPdesk's Asset Management module stores hardware, software, licences, and network components with a full parent-child hierarchy. Zendesk does not have a native asset object at Suite Growth and below; at Suite Enterprise it requires the paid Asset Management add-on. We create a custom Zendesk object (IT_Asset__c) during schema preparation with fields for asset type, serial number, status, location, and a parent_asset__c lookup for hierarchy. The TOPdesk asset hierarchy is built recursively since the TOPdesk API does not return the full tree in a single call; we fetch child links iteratively and set parent_asset__c references during migration.
TOPdesk
Configuration Items
Zendesk
Custom object (e.g., Configuration_Item__c)
1:1TOPdesk Configuration Management items store IT infrastructure components (servers, databases, services) and link to assets and calls. The TOPdesk configuration endpoint maps to a custom Zendesk object (Configuration_Item__c) with fields for name, type, status, and links to the IT_Asset__c custom object. Custom fields from the TOPdesk CI schema migrate to equivalent custom fields on the Zendesk custom object.
TOPdesk
Known Error
Zendesk
Help Center Article
1:1TOPdesk Known Error Cards store a problem cause and a possible solution. The Known Error description and workaround text migrate to a Zendesk Help Center Article, published in a dedicated Known Errors section. The TOPdesk-linked problem and the error cause are stored as article metadata in custom fields (known_error_cause__c, known_error_workaround__c). We link related articles to relevant tickets using Zendesk article linking.
TOPdesk
Reservation
Zendesk
Ticket (with reservation-specific custom fields)
1:1TOPdesk Reservations track bookings of equipment, rooms, or other lendable assets. In Zendesk, reservations become Tickets with custom fields capturing the reservation item, date range, and booking status. The reserved asset is linked via the IT_Asset__c custom object lookup. Reservation status (reserved, in use, returned) maps to Zendesk Ticket Status values.
TOPdesk
Attachment
Zendesk
Attachment
1:1Attachments linked to Calls, Changes, and Assets in TOPdesk migrate as Zendesk Attachments linked to the corresponding Ticket or custom object record. We extract attachment metadata (filename, size, content type) and the binary via the TOPdesk API, then attach to the destination record using the Zendesk Attachments API. Inline images within call or change descriptions are extracted separately and re-attached.
TOPdesk
Freely Definable Object (Free1Object–Free5Object)
Zendesk
Custom object per type
1:1TOPdesk allows up to five freely definable object types that organizations use for custom entities such as buildings, contracts, or service-level agreements. Each freely definable object type maps to its own Zendesk custom object (e.g., Contract__c, Building__c) with custom fields matching the TOPdesk free object schema. We pre-create the custom object schema during the Zendesk schema preparation phase before any data migration begins. Links between free objects and standard objects (Calls, Changes, People) are preserved as Zendesk custom lookups.
TOPdesk
Branch and Operator Group
Zendesk
Group + custom user field
lossyTOPdesk branches and operator groups organize operators and people by department, location, or team. We map each TOPdesk branch to a Zendesk Group and assign agents and users to the appropriate group. If the branch name does not map directly to a Zendesk Group structure, we use a custom user field (topdesk_branch__c) on the User record instead. Group membership is set during the People and Operator import phase.
TOPdesk
Custom Fields
Zendesk
Custom Fields
lossyTOPdesk supports custom fields of type text, date, checkbox, number, currency, and dropdown on Calls, Changes, Assets, People, and Operators. We map each custom field type to the equivalent Zendesk custom field type. Dropdown fields in TOPdesk that store multiple selections generate tags in Zendesk for reporting purposes; single-select dropdowns map to Zendesk dropdown fields. Currency fields from TOPdesk use the organization's base currency and map to Zendesk numeric custom fields.
| TOPdesk | Zendesk | Compatibility | |
|---|---|---|---|
| Calls | Ticket1:1 | Fully supported | |
| People | User1:1 | Fully supported | |
| Operator | User (Agent role)1:1 | Fully supported | |
| Change | Ticket (custom change_type field)1:1 | Fully supported | |
| Assets (Hardware, Software, Licence, Network Component) | Custom object (e.g., IT_Asset__c)1:1 | Fully supported | |
| Configuration Items | Custom object (e.g., Configuration_Item__c)1:1 | Mapping required | |
| Known Error | Help Center Article1:1 | Fully supported | |
| Reservation | Ticket (with reservation-specific custom fields)1:1 | Fully supported | |
| Attachment | Attachment1:1 | Fully supported | |
| Freely Definable Object (Free1Object–Free5Object) | Custom object per type1:1 | Fully supported | |
| Branch and Operator Group | Group + custom user fieldlossy | Fully supported | |
| Custom Fields | Custom Fieldslossy | 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.
TOPdesk gotchas
Application-password-only API auth blocks scripted migrations
Large ticket exports can timeout on Virtual Appliance
Asset hierarchy links require recursive traversal
Module-gated objects silently return empty results in API
Change activity templates tied to specific statuses
Zendesk gotchas
Data export requires API scripting on non-Enterprise plans
Automations cap at 500 active rules and 1,000 tickets per hour
Help Center has no native export feature
Custom Objects and full data export are Enterprise-only
Pair-specific challenges
Migration approach
Discovery and module scoping
We audit the source TOPdesk instance across licensed modules (Call Management, Asset Management, Problem Management, Operations Management, Knowledge Management), data volumes (calls, changes, assets, people, operators), the schema of any freely definable objects, and the asset hierarchy depth. We confirm whether the TOPdesk instance is SaaS or on-premise Virtual Appliance, because SaaS uses API-based extraction while on-premise requires the application-password-based API with careful chunking to avoid timeout. We also confirm the target Zendesk edition and whether the customer will use Zendesk's native Asset Management add-on or a custom object.
Zendesk schema preparation
We configure the Zendesk destination before any data is extracted. This includes creating custom fields on the Ticket object (change_type__c, change_template_type__c, topdesk_call_id__c), creating a custom IT_Asset__c object with the asset hierarchy fields, creating custom objects for each TOPdesk freely definable object type, creating custom user fields for branch and operator details, and configuring Group names to match TOPdesk branches. We also disable validation rules and required field constraints that could cause record rejection during import, and we create the migration user with the appropriate Zendesk API permissions.
Sandbox migration and reconciliation
We run a full migration into a Zendesk sandbox or staging environment using production-like data volume. The customer's TOPdesk administrator reconciles record counts (Calls in, Tickets in; Assets in, IT_Asset__c records in; People in, Users in), spot-checks 25-50 records against the TOPdesk source, and reviews the custom field mapping and asset hierarchy structure. Any schema corrections or field mapping adjustments happen here before production migration begins.
People and Operator import with role assignment
We import People and Operators in the same migration phase, resolving each to a Zendesk User with the appropriate role (End-user for people, Agent for operators). Operator branch and authorization template data maps to custom user fields and optionally to Zendesk Group membership. We match by email address and hold unresolved users in a reconciliation queue for the customer's admin to provision before the next phase. This phase must complete before any ticket import because ticket assignment lookups require Zendesk user IDs.
Ticket and change import in dependency order
We import Calls and Changes in record-dependency order. Each Call is created as a Zendesk Ticket with the subject, description, status, priority, category, and custom fields mapped from the TOPdesk schema. Changes receive the change_type__c and change_template_type__c custom fields set from the TOPdesk status and phase values. Operator assignments resolve to the Zendesk user IDs from Phase 4. Attachment binaries are attached to the ticket during import using the Zendesk Attachments API. We validate the import count against the source record count after the phase completes.
Asset hierarchy and custom object import
We import the TOPdesk asset hierarchy recursively into the IT_Asset__c custom object. The TOPdesk asset API does not return the full tree in a single call, so we fetch child links iteratively and set parent_asset__c lookups after the initial asset batch is loaded. Configuration Items, Known Errors (as Help Center articles), Reservations, and freely definable objects import in sequence. Each custom object is pre-created in Zendesk during Phase 2, so the schema is ready when the data arrives.
Cutover, validation, and automation handoff
We freeze TOPdesk writes during cutover, run a final delta migration of any records modified during the migration window, then enable Zendesk as the system of record. We deliver the Workflow and Sequence inventory document to the customer's admin team with a written trigger and automation recommendation per item. We support a one-week hypercare window where we resolve any reconciliation issues raised by the support team. We do not rebuild TOPdesk workflows, activity templates, or sequences as Zendesk triggers or automations inside the migration scope; that is a separate engagement.
Platform deep dives
TOPdesk
Source
Strengths
Weaknesses
Zendesk
Destination
Strengths
Weaknesses
Complexity grading
Standard Helpdesk migration. All 7 core objects map 1:1 between TOPdesk and Zendesk.
Overall complexity
Standard migration
Derived from compatibility, mapping clarity, API constraints, and data volume across TOPdesk and Zendesk.
Object compatibility
All 7 core objects map 1:1 between TOPdesk and Zendesk.
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
TOPdesk: Not publicly documented — varies by tenant tier and TOPdesk version.
Data volume sensitivity
TOPdesk 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 TOPdesk to Zendesk migration scoping. Not seeing yours? Book a call.
Walk through your TOPdesk to Zendesk migration with a real engineer — 30 minutes, free, written quote within 24 hours.
Book a free 30 minute consultationAdjacent paths
Other ways to leave TOPdesk
Other ways to arrive at Zendesk
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.