Zendesk to Deskpro migration translates a group-centric model to a department-centric one. Use the built-in importer for simple datasets; API pipelines for custom fields, threads, or attachments.
Migrating from Zendesk to Deskpro requires translating a group-centric architecture into a department-centric data model, with no native one-click migration path available between the two platforms. Fundamental structural differences exist across ticket statuses, custom fields, agent roles, and automation rules, meaning data cannot be moved as a simple lift-and-shift operation. Zendesk's built-in importer in Deskpro handles basic object transfers for small datasets, but production-grade migrations require a custom API pipeline (Zendesk REST API v2 → Deskpro REST API v2) to preserve conversation threads, inline attachments, and custom field schemas. Additional custom work is required to rebuild automations, SLA policies, and CSAT configurations from scratch, as these cannot be exported in a Deskpro-compatible format.
Read this first
Pair-specific gotchas that catch teams out. Each one has cost somebody a weekend.
TL;DR — Zendesk to Deskpro Migration
A Zendesk to Deskpro migration translates Zendesk's group-centric architecture into Deskpro's department-centric model. Organizations, Users, Tickets, Comments, Tags, and Help Center Articles all have Deskpro equivalents — but structural differences in custom fields, ticket statuses, and automations mean this is not a lift-and-shift. Deskpro offers a built-in Zendesk importer that handles basic migrations, but it won't reliably transfer custom fields, full conversation threads with inline images, or attachments at scale. For production-grade migrations, you need a Zendesk REST API → Deskpro REST API pipeline. Realistic timeline: 1–2 weeks for under 20K tickets; 3–5 weeks for enterprise datasets with complex custom field schemas. The biggest risk is orphaned ticket threads — Zendesk's CSV exports flatten conversations, losing reply structure and inline attachments. Technical details in this guide were verified against Zendesk API v2 and Deskpro API v2 as of June 2025. Pricing, rate limits, and API behavior are subject to change.
Zendesk Custom Objects have no Deskpro equivalent
If you use Zendesk Custom Objects to model business entities (orders, subscriptions, assets), you must flatten them into custom fields on Tickets, People, or Organizations. Multi-level relational structures will require schema compromises. You lose the relational query capability and the ability to query across object relationships, but you preserve the data values. For complex object graphs, consider exporting the relational data to a separate database and linking to it via a custom field containing a lookup ID.
Zendesk Incremental Export rate limit
10 requests per minute on standard plans (30 with the High Volume API add-on, which requires 10+ agent seats). A 500K ticket dataset at ~1,000 tickets per page takes approximately 500 pages = 50 minutes minimum at the standard rate. Plan extraction timing accordingly and run during off-peak hours.
Zendesk data exports are not enabled by default
The account owner must contact Zendesk Customer Support to enable bulk data exports via Admin Center. The API is available on all plans, but the Admin Center export tool has plan-level restrictions:
Production tips
- Every API call should be wrapped in retry logic with exponential backoff (the deskpro_request function above demonstrates this pattern). - Use batch sizes of 100 records with checkpoint saves so you can resume from the last successful record after a failure. - Log failed records to a JSONL file (dead-letter queue) for manual review and retry after the main migration completes. - Make your script idempotent: before creating a record, check the ID mapping table to see if it was already migrated. This allows safe re-runs.
The runbook
Work top to bottom. Tick steps as you go — your progress is saved in this browser.
01 Discovery Establish why you are moving, what "done" means, and who signs off.
Objective A written scope with agreed success criteria, a named owner per workstream, and a budget approved by finance.
Keep these open
-
Pull the real numbers out of Zendesk
Export counts for tickets (open and closed separately), contacts, organisations, attachments, macros, triggers, automations, views and SLA policies. Note the oldest ticket date — history depth drives the whole timeline. Estimating from memory is the single most common cause of a blown migration window.
Data Profiler Get real record counts instead of estimating from memory -
Decide what history actually moves
Agree a cut-off with the support lead: all history, last 24 months, or open tickets plus a read-only archive. Every extra year of closed tickets adds API time and cost without adding much agent value. Get this in writing — it is the decision people relitigate mid-cutover.
A "move everything" default is what turns a two-week migration into a two-month one.
COI & ROI Calculator Build the 36-month business case you will need for sign-off -
Confirm Deskpro can hold your support model
Walk your current workflow through Deskpro: multi-brand, business hours, SLA targets, CSAT, side conversations, public vs internal notes, and any channel you depend on (voice, chat, WhatsApp, social). List anything with no native equivalent — those are project risks, not configuration details.
-
Build the business case
Model licence delta, migration effort, agent retraining, and the cost of staying put (Cost of Inaction). Executives approve a number, not a plan, and you will be asked for it again at the go/no-go.
Helpdesk Migration Planner Turn ticket volume into a dated Zendesk → Deskpro timeline -
Name owners and set the go/no-go date
One named owner each for data, configuration, integrations, and agent enablement, plus a decision-maker who can call a rollback. Put the go/no-go meeting in calendars now, 48 hours before the freeze.
Zendesk → Deskpro specifics
- Cost reduction
- A 20-agent team on Zendesk Suite Professional ($115/agent/month) pays $27,600/year before add-ons. The same team on Deskpro Professional ($59/agent/month) pays $14,160/year — a 49% reduction. Factor in Zendesk's Copilot ($50/agent/month), QA, and Workforce Management add-ons and the gap widens further.
- Pricing predictability
- Zendesk's per-resolution AI billing (Zendesk AI agents charge per automated resolution above a threshold) creates variable costs that are hard to forecast. Deskpro's flat per-agent pricing has no usage-based AI surcharges.
- Simpler administration
- Teams that don't need Zendesk's full omnichannel stack (messaging, voice, social) find Deskpro's focused feature set easier to manage and configure without dedicated Zendesk administrators.
- Contract flexibility
- Zendesk's customer agreement includes early-termination fees and annual upfront billing. Deskpro offers both monthly and annual billing without lock-in penalties on Cloud plans.
- Professional plan
- CSV and JSON export available once enabled
Don't move on until
- Record counts confirmed for tickets, contacts, organisations and macros
- Success criteria signed off by the support lead
- Freeze window provisionally booked with the business
02 Data Audit Find out what is actually in the data before you try to move it.
Objective A profiled, cleaned export with every quality defect either fixed at source or explicitly accepted.
Keep these open
-
Take a full Zendesk export and profile it
Export to CSV or JSON and profile every file: row counts, null rates per column, distinct values, and type consistency. Compare row counts against the API totals from Discovery — a gap here means your export is silently truncated, usually by pagination.
Data Profiler Profile the Zendesk export for nulls, outliers and type drift -
Validate file structure before anyone writes a transform
Check delimiters, quoting, encoding (expect UTF-8, watch for BOMs and Latin-1), duplicate headers, and embedded newlines in ticket bodies. Ticket descriptions with raw newlines and commas break naive CSV parsers and silently shift columns.
A single unescaped quote in one ticket body can shift every subsequent column without any error.
CSV Validator Catch broken headers and ragged rows in the raw export -
Inventory PII and set retention
Scan for emails, phone numbers, payment card fragments, national IDs and anything else regulated in ticket bodies and custom fields — support tickets are where customers paste things they should not. Decide what gets migrated, masked, or dropped, and record the legal basis.
Ticket bodies and attachments routinely contain card and ID data that never appears in a structured field.
PII & Compliance Scanner Find regulated fields before they land in a new system -
Quantify duplicates, orphans and dead references
Count duplicate contacts (same email, different casing), tickets whose requester no longer exists, organisations with no members, and attachments whose parent ticket is gone. Fix these in Zendesk where you can — migrating them just moves the mess.
Data Cleaner Strip empty rows, stray whitespace and dead columns -
Clean and normalise the export
Trim whitespace, drop empty rows and columns, normalise casing on emails and tags, and standardise every timestamp to UTC ISO 8601. Timezone drift is invisible at load time and shows up weeks later as SLA reports nobody can reconcile.
-
Produce a masked copy for sandbox work
Generate a realistic but fake version of the export for testing and for any vendor who needs sample data. Loading real customer PII into a sandbox is a breach in most jurisdictions, and sandboxes are rarely covered by your DPA.
PII Masker Generate a safe copy for sandbox and vendor testing
Zendesk → Deskpro specifics
- Organizations
- Count, custom fields, membership rules, shared organization settings
- Custom ticket fields
- List all from GET /api/v2/ticket_fields.json — record field key, type, picklist values, required/optional status, and any dependencies
- Custom user/org fields
- Same via GET /api/v2/user_fields.json and GET /api/v2/organization_fields.json
- Triggers and Automations
- Document logic — these must be rebuilt manually in Deskpro. Export definitions via GET /api/v2/triggers.json and GET /api/v2/automations.json for reference
- SLA Policies
- Document targets and conditions via GET /api/v2/slas/policies.json
Don't move on until
- Export parses cleanly with no ragged rows or encoding errors
- PII inventory complete and retention decisions recorded
- Duplicate and orphan records quantified and triaged
03 Field Mapping Turn two schemas into one signed-off mapping spec.
Objective A reviewed field-level mapping covering every object, with an explicit decision for every field that has no target.
Keep these open
-
Generate the first-pass Zendesk → Deskpro field map
Start from an automated match on both schemas, then review every row by hand. Automated matching gets the obvious 70% right and is confidently wrong on the rest — especially anything named "type", "status" or "custom_field_1".
Schema Mapper Opens pre-loaded with the Zendesk → Deskpro field pair -
Map status, priority and channel values, not just field names
Enumerate every value in each picklist on both sides and map them explicitly. Value-level mismatches are the defect class that survives all the way to production because the field itself mapped fine — a ticket that should be "Pending" arriving as "Open" reopens SLA clocks.
Statuses with no target equivalent (on-hold, pending-customer) need a policy decision, not a best guess.
-
Decide how custom fields land
Create the target custom fields first, matching type exactly (a dropdown mapped to free text can never be mapped back). Where Deskpro has no equivalent, decide between a new custom field, a tag, or a note appended to the ticket body — and record which.
-
Resolve identity and threading
Decide how source IDs are preserved — most platforms will not let you set the primary key, so keep the original ID in a custom field. Without it, reconciliation becomes fuzzy matching and every future support question about an old ticket is unanswerable.
Losing the original ticket ID makes reconciliation and rollback effectively impossible.
-
Plan attachments, inline images and threading order
Confirm size limits, allowed MIME types, and whether inline images survive as attachments or need rehosting. Decide the comment ordering and author attribution rules: comments loaded out of order, or all attributed to the API user, destroy the conversation history agents rely on.
-
Freeze and sign off the mapping spec
Version the spec, walk the support lead through it row by row, and get explicit sign-off. Any change after this point goes through change control — mid-flight mapping edits are how partial loads happen.
Zendesk → Deskpro specifics
- Custom Fields
- Extract field definitions from /api/v2/ticket_fields.json, /api/v2/user_fields.json, /api/v2/organization_fields.json. These define your target schema in Deskpro.
Don't move on until
- Every source field is mapped, deliberately dropped, or parked in a custom field
- Status, priority and channel value maps agreed with the support lead
- Mapping spec version-controlled and signed off
04 Test Migration Prove the pipeline on a small, representative slice.
Objective A pilot load into a Deskpro sandbox that reconciles cleanly and has been reviewed by real agents.
Keep these open
-
Stand up a Deskpro sandbox that matches production config
Create the custom fields, groups, brands, business hours and SLA policies first. A pilot into a default sandbox tests nothing, because the failures you care about are all configuration mismatches.
-
Pick a deliberately nasty pilot sample
Take 500-1000 records chosen for difficulty, not convenience: the longest ticket threads, tickets with the most attachments, non-Latin character sets, merged and split tickets, deleted requesters, and every status value. A clean random sample proves only that easy records are easy.
-
Run the load with masked data and instrument everything
Log every API request and response with its source record ID. When 40 records fail out of 10,000 you need to know exactly which ones and why, without re-running the whole batch.
PII Masker Never load real customer PII into a sandbox -
Measure real throughput against the rate limit
Record achieved records-per-hour under Deskpro's actual rate limits, including retries and backoff. Extrapolate to the full volume: if the maths says the full load exceeds your freeze window, you fix that now, not on cutover night.
Published rate limits are ceilings, not throughput. Assume real-world rates are meaningfully lower once retries and backoff are counted.
-
Reconcile the pilot and triage every failure
Diff source against target on record counts and field-level values. Every discrepancy gets a root cause and a fix — "probably fine" at pilot scale becomes thousands of broken records at full scale.
Migration Validation Tool Diff the pilot batch against source before scaling up -
Put real agents in front of the pilot data
Have two or three agents work sample tickets end to end in the sandbox. They find the things reconciliation cannot see: unreadable threading, missing context, macros that no longer make sense. Fix the mapping, then re-run.
Don't move on until
- Pilot batch reconciles to 100% on record counts
- Agents have reviewed sample tickets and confirmed they are workable
- Measured throughput extrapolates to a viable full-load window
05 Cutover Execute the switch inside a controlled, reversible window.
Objective All in-scope data live in Deskpro, agents working in the new system, and a rollback path that stayed available throughout.
Keep these open
-
Pre-load history before the freeze
Load closed tickets and contacts days or weeks ahead while Zendesk stays live. Only open tickets and the final delta need to move inside the freeze — this is the single biggest lever on window length.
Helpdesk Migration Planner Size the freeze window from Deskpro's real API limits -
Publish the runbook with times, owners and abort criteria
A timed sequence: freeze start, final export, delta load, channel switch, smoke test, go/no-go, agent switch. Name who does each step and the explicit condition that triggers a rollback. Decide the abort criteria before the night, when nobody wants to be the one to call it.
-
Freeze Zendesk and take the final delta
Stop new ticket creation, let agents finish in-flight replies, then export everything changed since the pre-load. Announce the freeze to the whole business, not just support — someone always tries to raise a ticket during it.
Tickets created during an unenforced freeze land in the old system and are the most common source of permanently lost data.
-
Load the delta and open tickets
Run the delta load, then reconcile counts before touching any channel. Do not repoint email until the delta has verified — an inbound ticket arriving mid-load is far harder to untangle than a few extra minutes of freeze.
Migration Validation Tool Confirm the final delta landed before you reopen -
Repoint channels and verify with live traffic
Switch email forwarding and MX or connector settings, update chat widgets and web forms, and re-authorise integrations. Then send real test tickets through every channel and confirm each lands, routes and triggers the right automation.
Email forwarding changes can take up to a full DNS TTL to propagate — check the TTL days in advance and lower it if needed.
Cron Expression Builder Schedule the delta syncs that run through the freeze -
Run the go/no-go and switch the agents
Walk the exit criteria with the decision-maker, call it explicitly, then move agents over with a named person on hand for the first few hours. Keep Zendesk read-only rather than cancelled — cancelling the old contract on day one removes your only fallback.
Zendesk → Deskpro specifics
- Data sovereignty and on-premise deployment
- Deskpro is one of the few modern helpdesks that offers a genuine self-hosted option. Regulated industries (healthcare under HIPAA, financial services under SOX/PCI-DSS, government under FedRAMP or national data residency laws) often need data on their own infrastructure to meet compliance requirements.
Don't move on until
- Full historical load complete and counts matched
- Inbound channels repointed and verified with live test tickets
- Rollback decision point passed explicitly, not by default
06 Validation Prove the migration is complete, then close it out.
Objective Documented evidence that data, workflow and reporting all survived, and a signed acceptance.
Keep these open
-
Run the full reconciliation
Compare source and target on every object: total counts, counts by status, counts by group, attachment counts, and field-level spot checks on a random sample. Produce one report you can hand to an auditor.
Migration Validation Tool Reconcile Zendesk and Deskpro record-for-record -
Verify field completeness, not just record counts
Re-profile the loaded data and compare null rates per field against the source profile. Matching record counts with a field that silently arrived empty is the failure mode counts alone will never catch.
Data Profiler Prove field completeness held up through the load -
Rebuild reporting and compare against baselines
Recreate your core dashboards — volume, first response time, resolution time, CSAT — and compare to pre-migration figures for the same period. Explain every variance; a changed SLA calculation is a real finding, not a rounding error.
SLA and first-response metrics are usually recalculated from the loaded timestamps, so they will differ if any timestamp mapping was approximate.
-
Test the workflow layer end to end
Fire every trigger, automation, SLA escalation, macro and notification with a live ticket. Workflow does not migrate — it gets rebuilt — so it is untested until someone has actually watched it run.
-
Confirm compliance and produce the audit trail
Re-scan the loaded data for regulated fields, confirm retention and deletion policies are configured in Deskpro, and file the evidence with your PII decisions from the audit phase.
PII & Compliance Scanner Produce the compliance evidence your auditor will ask for -
Sign off, then decommission on a schedule
Get written acceptance against the Discovery success criteria. Keep Zendesk read-only for an agreed period (30-90 days is typical), take a final archive export, and only then cancel. Diarise the decommission date so it does not quietly renew.
Don't move on until
- Full reconciliation report attached to the project record
- Reporting baselines match pre-migration figures within agreed tolerance
- Formal acceptance signed and archive retention scheduled
Field mapping reference
The field-by-field mapping for each object. Use this as the starting point for your mapping spec.
Concept Zendesk
| Zendesk field | Deskpro field | Notes |
|---|---|---|
| Customer grouping | Organizations | Near 1:1; Deskpro supports custom fields on Organizations |
| End users | Users (end-users) | Deskpro People can belong to multiple Organizations |
| Agent staff | Agents / Light Agents / Admins | Map by email; see agent role mapping below |
| Ticket routing | Groups | Zendesk Groups are agent pools; Deskpro Departments are structural containers with their own forms and email channels |
| Agent teams | No formal concept beyond Groups | Deskpro has a separate Teams layer for cross-department grouping |
| Ticket replies | Comments (public/private) | Private comments → Deskpro Agent Notes |
| Categorization | Tags | Functional equivalent; both support multiple values per ticket |
| Custom metadata | Ticket Fields / User Fields / Org Fields | Deskpro supports dependencies between fields |
| Automations | Triggers + Automations | Must be rebuilt manually — cannot be exported from Zendesk in a Deskpro-compatible format |
| Self-service | Help Center (Guide) | Different content structure; see KB migration section |
| Ticket status | Open / Pending / On-hold / Solved / Closed | Deskpro allows custom ticket statuses |
| Custom objects | Custom Objects (API) | Must be flattened into custom fields |
| SLA policies | SLA Policies | Different configuration model; rebuild required |
| Satisfaction | CSAT (Satisfaction Ratings) | See CSAT section below |
Role Equivalent
Standard Zendesk agent roles map to Deskpro permission groups with reasonable equivalence, but Zendesk Enterprise custom roles must be individually recreated as Deskpro permission groups before agents are imported.
| Zendesk field | Deskpro field | Notes |
|---|---|---|
| Full Agent | Agent (standard permission group) | Full ticket access |
| Light Agent | Agent (restricted permission group) | Create a permission group limiting write access |
| Admin | Agent + Admin access enabled | Enable admin toggle on agent profile |
| Custom Roles | Custom permission groups | Recreate each role as a Deskpro permission group |
Zendesk Deskpro
| Zendesk field | Deskpro field | Notes |
|---|---|---|
| id | id (new) | Store Zendesk ID in a custom field for cross-reference |
| name | name | Direct map |
| domain_names | email_domains | Array → comma-separated |
| tags | Labels | Create labels if they don't exist |
| primary_email | Deskpro uses email as unique key; duplicates rejected | |
| organization_id | organization | Resolve via ID mapping table |
| role (end-user) | User | End-users become People |
| role (agent/admin) | Agent | Create via agent endpoints |
| subject | subject | Direct map |
| status | status | See status mapping below |
| priority | priority | See priority mapping below |
| group_id | department | Map Zendesk Groups → Deskpro Departments |
| assignee_id | agent | Resolve via agent ID mapping |
| requester_id | person | Resolve via person ID mapping; null requesters will be rejected |
| tags | labels | Create labels if needed |
| created_at | date_created | ISO 8601; must be set explicitly or defaults to now |
| html_body | message | Prefer html_body over body for formatting preservation |
| public (true) | Message (reply) | Public comments → ticket replies |
| public (false) | Agent Note | Private comments → internal notes |
| attachments | Attachment | Download from Zendesk CDN, re-upload to Deskpro |
Status Status
| Zendesk field | Deskpro field | Notes |
|---|---|---|
| new | awaiting_agent | Both indicate agent action needed |
| open | awaiting_agent | |
| pending | awaiting_user | Waiting on customer reply |
| on-hold | awaiting_agent (or custom status) | Deskpro has no native on-hold; create a custom status named "On Hold" if your team uses this distinction |
| solved | resolved | |
| closed | archived | Closed tickets in Zendesk are immutable; archived in Deskpro is the closest equivalent |
Cus m Field Type Mapping
Custom fields on tickets, users, and organizations require manual schema recreation in Deskpro prior to migration, and Zendesk Custom Objects must be flattened into custom fields with permanent loss of relational structure.
| Zendesk field | Deskpro field | Notes |
|---|---|---|
| text | Text (single-line) | Deskpro single-line text has a character limit; long values → multi-line |
| textarea | Textarea (multi-line) | Direct map |
| checkbox | Toggle | Boolean mapping |
| integer | Number | Direct map |
| decimal | Number | Deskpro numbers support decimals |
| date | Date | ISO 8601 format |
| tagger (drop-down) | Choice | Zendesk generates tags from selections; Deskpro uses choice IDs. Remap every option ID. |
| multiselect | Multi-choice | Same tag-to-ID remapping required |
| regexp | Text | Deskpro doesn't support regex validation on custom fields; validate in your migration script |
| lookup (relationship) | Text or Choice | Zendesk lookup fields reference other objects; flatten to text values |
Platform Default Limit
| Zendesk field | Deskpro field | Notes |
|---|---|---|
| Zendesk (Team) | 200 req/min | Account-wide; all API consumers share this quota |
| Zendesk (Professional) | 400 req/min | |
| Zendesk (Enterprise) | 700 req/min | |
| Zendesk (High Volume add-on) | 2,500 req/min | Requires 10+ agent seats; separate purchase |
| Zendesk Incremental Export | 10 req/min | 30 req/min with High Volume add-on |
| Deskpro (Cloud) | Configurable (hourly/daily quotas) | Request a temporary increase via support@deskpro.com for migration windows |
| Deskpro (On-Premise) | No enforced limit | Constrained only by server resources |
Risk matrix
Per-object risk for this pair. Plan extra validation around anything marked high.
| Object | Risk | Notes |
|---|---|---|
| Tickets | medium | Core ticket properties migrate reliably via the API pipeline, but correct status mapping, timestamp preservation, and Department assignment require explicit transformation logic to avoid misclassified or orphaned records. |
| Ticket Comments & Messages | high | Zendesk CSV exports omit comments entirely and flatten conversation structure, making full threaded reply history with public/private distinction recoverable only through the REST API pipeline. |
| Attachments & Inline Images | high | Attachments and inline images are not reliably transferred by Deskpro's built-in importer at scale and require explicit binary transfer steps in a custom API pipeline, with high risk of data loss if not handled separately. |
| Users / People | low | Zendesk end-users map closely to Deskpro People and can be migrated with high fidelity via the API, though custom user fields require pre-mapped field definitions in Deskpro before import. |
| Organizations | low | Zendesk Organizations are near 1:1 equivalents of Deskpro Organizations and migrate reliably, with the primary consideration being that custom organization fields must be pre-created in Deskpro before records are imported. |
| Custom Fields | high | Custom fields on tickets, users, and organizations require manual schema recreation in Deskpro prior to migration, and Zendesk Custom Objects must be flattened into custom fields with permanent loss of relational structure. |
| Tags / Labels | low | Zendesk Tags are functionally equivalent to Deskpro Labels and migrate with low risk, as both systems support multiple values per ticket and the mapping is straightforward. |
| Agent Roles & Permissions | medium | Standard Zendesk agent roles map to Deskpro permission groups with reasonable equivalence, but Zendesk Enterprise custom roles must be individually recreated as Deskpro permission groups before agents are imported. |
| Help Center Articles / Knowledge Base | medium | Zendesk Guide and Deskpro Knowledge Base have different content structures, so article hierarchy, category mappings, and embedded media require manual review and restructuring rather than automated transfer. |
| CSAT / Satisfaction Ratings | high | Zendesk Satisfaction Ratings use a binary Good/Bad model with reason codes that do not map to Deskpro's star-rating Feedback system, resulting in lossy migration where satisfaction reason codes are permanently lost and historical data is best preserved as custom fields or exported to a BI tool. |
The hard parts
What makes this specific migration difficult, beyond the mechanics.
Group-to-Department Model Translation
Zendesk Groups function as agent pools for ticket routing, while Deskpro Departments are structural containers with their own forms and email channels, requiring a deliberate architectural remapping rather than a direct field substitution.
Custom Field Schema Complexity
Zendesk ticket, user, and organization custom fields must be individually mapped to Deskpro's equivalent field types, and Zendesk Custom Objects have no Deskpro equivalent and must be flattened into custom fields with loss of relational query capability.
Conversation Thread Preservation
Zendesk CSV exports flatten ticket conversations, stripping reply structure and inline attachments, so full threaded conversation history with attachments can only be reliably migrated via a direct API-to-API pipeline.
Automation and Trigger Rebuilding
Zendesk Triggers and Automations cannot be exported in a Deskpro-compatible format and must be fully rebuilt manually as Deskpro Triggers and Escalations.
Ticket Status Mapping Mismatch
Zendesk's five native statuses (Open, Pending, On-hold, Solved, Closed) do not map directly to Deskpro's status model (Awaiting Agent, Awaiting User, Resolved, Archived plus custom statuses), requiring explicit status translation logic in the migration pipeline.
API Rate Limit Management
An API-based migration pipeline must handle rate limits on both the Zendesk and Deskpro sides simultaneously, requiring idempotent retry logic and per-record error handling to avoid data loss on large or enterprise-scale datasets.
Tools used in this playbook
All free, all run entirely in your browser — nothing is uploaded.
FAQ
Does Deskpro have a built-in tool to migrate from Zendesk?
Yes. Deskpro includes a native Zendesk importer under Admin > Apps > Importer. You provide your Zendesk subdomain and an admin API token, and it pulls core data (tickets, users, organizations) directly. However, it has limited support for custom fields, full conversation threads, and attachments — so complex migrations still require the API pipeline approach.
How long does a Zendesk to Deskpro migration take?
For small datasets (under 20K tickets), expect 1–2 weeks including planning, test migration, and validation. Enterprise datasets with complex custom field schemas, attachments, and multi-brand configurations typically take 3–5 weeks. The Zendesk Incremental Export API rate limit (10 requests/minute) can extend extraction time for large datasets.
Can I migrate from Zendesk to Deskpro using CSV files?
Only for basic user and organization records. Zendesk CSV exports omit ticket comments and descriptions, and Deskpro's CSV importer only imports ticket properties and the first message — no threaded conversations or attachments. An API-based migration is required for full fidelity.
Can I migrate Zendesk Custom Objects to Deskpro?
Not directly. Deskpro has no custom object model. Zendesk Custom Objects must be flattened into custom fields on Tickets, People, or Organizations. You lose the relational query capability, but you preserve the data as field values.
Will my Zendesk triggers, macros, and automations migrate to Deskpro?
No. Triggers, Automations, and Macros cannot be exported from Zendesk in a machine-readable format that Deskpro understands. They must be manually documented and recreated as Deskpro Triggers, Escalations, and Macros/Snippets.