Phase 0

Decide & Plan

Decisions that must be made before any extraction work starts.

Document the in-scope Zoho Desk modules. List every standard module you will load (Tickets, Threads, Ticket Comments, Contacts, Accounts, Agents, Teams, Products, Tasks, Events, Calls, Time Entry, Contracts, Articles, Custom Modules). Anything not on this list is out of scope.
Risk if skipped: Late-discovered modules force schema changes mid-migration and trigger re-runs of upstream transform jobs.
Pick the Zoho Desk edition before any provisioning. Edition gates Sandbox availability (Enterprise), Blueprint state machines (Standard and above), per-Department Layouts (Professional and above), Multi-Department support, Zia AI (Enterprise), and Zoho Voice integration (Professional and Enterprise).
Risk if skipped: Choosing a lower edition than the data requires blocks Sandbox testing, per-Department customization, and Blueprint-driven state machines.
Define the historical-ticket scope window. Decide how many years of closed Tickets, Threads, Ticket Comments, Calls, and Knowledge Base Articles are in scope. Decide whether attachments are in scope or stay in the legacy archive.
Decide the historical-timestamp strategy for Tickets. Zoho Desk's Zwitch can preserve original Created Time and Closed Time on imported tickets; the standard UI Import cannot. Pick a path now: Zwitch with timestamp preservation, UI Import with Source Created Date custom field, or accept that Created Time equals migration date.
Risk if skipped: Without a written strategy, ticket-aging reports and SLA-historical analysis will reset on cutover day.
Document data-residency and compliance requirements. Zoho operates regional data centers (US, EU, IN, AU, JP, CN, CA, SA). Confirm which DC the org must live in, GDPR enablement for Contacts, SOC 2 + HIPAA scope (annual audit window Dec–Nov), and retention policies.
Risk if skipped: Provisioning in the wrong DC cannot be reversed by moving data later — it requires a fresh org and a second migration.
Decide the Department topology. Zoho Desk uses Departments as the primary organizing unit (replacing the Brand/Workspace model in other helpdesks). Decide whether to migrate to one Department or split by business line, product line, or region. Custom fields are Department-scoped.
Risk if skipped: Loading all tickets into one Department when the business needs multiple Departments later forces a second migration to re-distribute records.
Name a single accountable migration owner (DRI). One person signs off on Phase 0, Phase 4 sandbox results, and Phase 6 reconciliation. No committee.
Set the cutover date, time, and source-system freeze window. Pick a low-volume window. Confirm with support, customer success, and ops leads that no campaigns or product launches overlap.
Write the success criteria. Concrete pass/fail statements: total ticket count matches source within 0.1 percent, every open ticket is assigned to an agent, SLA clock on open tickets reflects the migrated due date, every active agent can log in and see their assigned tickets.
Risk if skipped: Without written criteria, the migration drags on indefinitely because nobody can declare it done.
List explicitly out-of-scope items. Examples: source-system custom dashboards (rebuild manually post-cutover), source-system trigger rules (rebuild as Zoho Workflow Rules and Macros), deleted tickets in the legacy recycle bin, CSAT historical scores (Zoho Desk Happiness Ratings cannot be backfilled).

Phase 1

Pre-Migration Prep

Everything that must be true before the first byte leaves the source.

1a. Source-system audit and cleansing

Export current record counts per source object as a baseline. Capture exact counts for Tickets, Threads, Comments, Contacts, Accounts, Agents, KB Articles, Tasks, Calls, Events. This is the reference number for Phase 6 reconciliation.
Risk if skipped: Without a baseline, you cannot prove what was lost in transit.
Run deduplication on source Contacts using email as the match key. Zoho Desk identifies Contact duplicates by email on import. Resolving duplicates upstream is faster than untangling them after load.
Risk if skipped: Duplicate Contacts split ticket history across two records and break Contact-level reporting.
Run deduplication on source Accounts using domain as the match key. Pick one canonical Account per company; merge child Contacts and Tickets onto it.
Standardize email casing and trim whitespace across all email fields. Convert to lowercase. Strip leading and trailing spaces. Email is the matching key for Contact-to-existing-record resolution in Zoho Desk.
Identify and fix records missing required Zoho Desk fields. Required on Ticket import: Subject, Department, Contact Name (mapped via email or agentExtId), Status. Required on Contact: email. Required on Agent: agentExtId, Last Name, Email.
Risk if skipped: Rows with empty required fields are dropped to the error log and do not appear in the destination.
Inventory source custom fields per ticket type. Export field name, type, picklist values, validation rules, and required flag. This becomes the source side of the Phase 3 mapping spreadsheet. Note that Zoho Desk custom fields are Department-scoped.
Document source ticket status values and lifecycle transitions. Capture every distinct status value the source uses, plus which transitions are allowed. This becomes the input for the destination Blueprint and Status picklist.
Risk if skipped: Missing source statuses cause ticket rows to be skipped with a picklist-validation error during import.
Document SLA policies, business hours, and holiday calendars on the source. Zoho Desk SLAs are per-Department. Capture per-policy response time, resolution time, escalation tiers, and operational hours so they can be rebuilt in Phase 7.
Inventory source Macros, Trigger Rules, and Automations. Capture the rule name, trigger conditions, and actions. These do not migrate and must be rebuilt as Zoho Desk Macros, Workflow Rules, Assignment Rules, or Blueprints.

1c. People prep

Announce the source-system freeze window to all agents and end users. Pin the announcement in chat and email it at T-7 days, T-1 day, and T-1 hour.
Schedule Zoho Desk training sessions segmented by role. Agents, supervisors, and admins each need a focused 30 to 60 minute session within 5 business days of cutover.
Designate first-responder support contacts for the 48 hours post-cutover. At least one Zoho Desk admin on call. Name them publicly.

Phase 2

Source Export

Get all data out of the source system in a form you can transform.

Phase 3

Transform & Map

The data-engineering core. Take raw exports and produce Zoho Desk-shaped files.

3a. Mapping spreadsheet

Build a master mapping spreadsheet covering every source field. Columns: Source Module, Source Field, Source Type, Destination Module, Destination Field, Destination Type, Destination Department, Transformation Rule, Required (Y/N), Upsert Key (Y/N), Notes.
Risk if skipped: Without a single mapping document, transform logic drifts between engineers and reconciliation finger-pointing becomes unavoidable.
Confirm field-type compatibility row by row. Zoho Desk does not let you change field type after creation. A source Text field cannot be loaded into a destination Integer field; either change the destination field type now or transform the source value.
Decide the dedup behavior per module: Skip, Overwrite, or Clone. Zoho Desk import offers all three. Skip leaves the destination record untouched, Overwrite replaces fields with import values, Clone creates a duplicate. Document the choice per module.
Risk if skipped: Choosing Clone by accident on a re-run creates duplicate Contacts, Accounts, and Tickets.
Decide what to do with source fields that have no destination equivalent. Three options per field: drop, create a custom field, or concatenate into the Description.
Resolve every picklist value mismatch. Source 'New' to Destination 'Open'. Build a value-translation lookup that maps every distinct source value to a valid destination value before export. Article Status only accepts [draft, publish, review].
Risk if skipped: Mismatched picklist values cause row-level skips at insert time, with the row reported in the import error log but not loaded.
Map Profiles and Roles between source and destination. Source 'Agent' to Destination 'Support Agent' Profile, for example. This drives the Owner assignment.

3b. Data transformation

Convert all dates and datetimes to ISO-8601. Zoho Desk import rejects ambiguous formats like DD/MM/YYYY. Use yyyy-MM-dd for Date and yyyy-MM-ddTHH:mm:ss+/-hh:mm for DateTime.
Risk if skipped: Date-format mismatches cause the entire CSV column to be rejected with no clear row-level diagnostic.
Re-encode every CSV as UTF-8. Zoho importer requires UTF-8. Files exported from older systems often land as Windows-1252 or UTF-16; verify with a hex check on the byte-order mark.
Risk if skipped: Non-UTF-8 files convert accented characters to mojibake or ASCII escape codes.
Truncate text fields that exceed Zoho Desk character limits. Plain Text small caps at 2,000 characters. Plain Text large caps at 32,000. Rich Text caps at 50,000. Single-line picklist caps at 120 characters. Decide whether to truncate or split oversize values.
Risk if skipped: Rows exceeding field width are rejected at import time.
Escape commas, quotes, and newlines in long-text fields. RFC 4180 quoting: wrap any field containing a comma or newline in double quotes and double any embedded double quotes.
Format Tags as a bracketed comma-separated array per Ticket row. Zoho Desk expects tags in the form [urgent,high-priority,refund] inside a single CSV cell.
Risk if skipped: Tags passed as plain comma-separated strings without brackets are rejected and the ticket row imports without tags.
Compress all CSV files for one module into a single ZIP per Zwitch / UI Import rules. Only ZIP-of-CSVs is accepted via the UI Import. ZIP file ceiling is 30 MB; per-CSV-file ceiling is 10,000 rows or 30 MB. Split larger datasets into multiple ZIPs and run sequential imports.
Risk if skipped: Oversize ZIPs are rejected by the UI Import with no row-level diagnostic.
Stage attachment archives by parent Ticket Source ID. Bulk attachment loads walk per-ticket; staging by parent ID lets the load run deterministically.

3c. Relationship and audit-trail decisions

Implement the historical-timestamp strategy chosen in Phase 0. Zwitch can preserve original Created Time and Closed Time. UI Import cannot — populate a Source Created Date custom field per module and use it for reporting.
Risk if skipped: Reporting on Created Time when UI Import was used will show every ticket dated to migration day, destroying time-series trend analysis.
Set Ticket Owner via agent email or agentExtId on every Ticket row. Per the Zoho Desk Import documentation: Ticket Owner must be specified using the agent's email address or Agent ID, not the agent's name. Agent name is rejected.
Risk if skipped: Loading Ticket Owner as the agent's display name leaves every ticket unassigned and forces a second pass.
Decide the attachment strategy. Option A: re-upload binaries into each ticket. Option B: store binaries in Zoho WorkDrive and link via a URL custom field. Option B preserves storage quota.
Risk if skipped: Re-uploading 100 GB of attachments into a Standard org saturates storage and blocks new records.
Resolve Ticket-to-Contact relationships via Contact email. Zoho Desk auto-links Tickets to existing Contacts on email match. Load Contacts first so the link resolves.
Risk if skipped: Loading Tickets before Contacts creates orphan Tickets with a placeholder Contact that must be merged later.
Resolve Ticket-to-Account relationships via the Contact's Account. Zoho Desk infers the Account from the Contact in most cases. Load Accounts first, then Contacts (with Account email-domain match), then Tickets.
Plan Parent-Child Ticket linking for related tickets. Zoho Desk supports a Parent-Child relationship via the official extension. Linking is not supported in the UI Import — plan to perform the link step programmatically after the main load.
Risk if skipped: Skipping the parent-child link step leaves duplicate-ticket clusters that the support team has been manually merging.

3d. Helpdesk-specific transforms

Reassemble Ticket Threads and Comments per parent Ticket. Threads carry the email/chat conversation; Ticket Comments carry agent notes. Both are child objects keyed off Ticket Source ID and must load after the parent Ticket. Preserve thread sequence and sender direction (inbound vs outbound).
Risk if skipped: Threads loaded out of sequence display in the wrong order in the agent UI; comments loaded as Threads break public/private visibility.
Build the Help Center hierarchy: Categories, then Sections, then Articles, then translations. Each layer references IDs from the previous layer. Articles must reference an existing Section. Translations must reference an existing Article and a supported locale.
Risk if skipped: Loading Articles before Sections leaves orphan Articles in an unsorted area that has to be re-filed manually.
Rebuild Macros, Workflow Rules, Assignment Rules, and Blueprints as Zoho-native objects. Source-system trigger rules and macros do not migrate. Use the Phase 2 screenshots as the spec. Macros run on demand; Workflow Rules fire on create/edit/time; Assignment Rules route Tickets; Blueprints enforce state transitions.
Risk if skipped: Skipping this transform leaves the helpdesk with no automation on cutover day and forces agents to do everything manually.
Plan Blueprint state placement for imported Tickets. If a Blueprint governs Tickets in production, every imported Ticket must land in the state matching its Status. Disable the Blueprint during import, then run a state-correction pass post-load to transition tickets into the correct state.
Risk if skipped: An active Blueprint rejects Status values that violate transition rules, causing partial imports.
Rebuild SLA policies per Department, with response and resolution targets plus escalation tiers. Zoho Desk SLAs are Department-scoped. Rebuild Business Hours and Holiday Lists first; SLAs reference them.
Risk if skipped: Loading open tickets before SLA policies are active means their SLA clock starts from migration day rather than original Created Time.
Recognize that CSAT / Happiness Ratings cannot be backfilled. Zoho Desk Happiness Ratings are captured via survey response and cannot be inserted historically. Decide whether to load source CSAT scores into a custom 'Migrated CSAT' field for historical reference or accept that CSAT history lives only in archived exports.
Risk if skipped: Customer-success reports that depend on Happiness Ratings will show zero for the pre-cutover window.
Plan the multi-channel inbox configuration: email, web forms, SalesIQ chat, Zoho Voice, social, and the ASAP widget. Each channel needs its own setup: email forwarding addresses or IMAP, embedded web form on the customer site, SalesIQ brand and tracking code, Zoho Voice number assignments, connected social profiles, and the ASAP widget snippet for in-app self-service.
Risk if skipped: Cutting over before channels are wired means inbound tickets via the old channels stop arriving the moment the source freeze starts.
Recompute SLA clocks for open Tickets at cutover. For each open Ticket, compute the elapsed time since source Created Time and seed the new SLA Due Date so the clock resumes correctly rather than restarting.
Risk if skipped: Restarting the SLA clock on cutover hides every breached ticket and makes the team look better than they are.
Map source Department / Brand / Workspace concept onto Zoho Desk Departments. Zoho Desk Departments replace what other helpdesks call Brands or Workspaces. Apply the topology from Phase 0 uniformly on every Ticket row before export.

Phase 4

Sandbox Test Migration

Catch every problem in Sandbox before it costs you in production.

Phase 5

Production Cutover

Tightly sequenced execution window. Densest cluster of risk.

Phase 6

Validate

Prove the migration was correct before letting agents back in.

6a. Reconciliation

Compare total Ticket count per Department: source vs Zoho Desk. Use Zoho Desk reports filtered per Department. Investigate any delta beyond the agreed tolerance.
Risk if skipped: Unexplained deltas typically trace to skipped picklist values, missing required fields, or unmapped Departments.
Compare open vs closed Ticket counts. Catches Status-mapping errors that flip Tickets between open and closed.
Compare Thread counts and Comment counts. Per-ticket thread count and comment count must match source counts within tolerance.
Risk if skipped: Missing Threads are the most common cause of post-cutover support escalations because agents lose conversation context.
Compare KB Article counts per Section and per Status. Catches articles that landed in the wrong Section or got rejected due to disallowed Status values.
Spot-check 25–50 randomly selected Tickets field-by-field. Pick Tickets across Departments, agents, channels, and statuses. Open each in the agent UI and compare to the source export.
Verify all Source ID values are populated. Run a query for null Source ID across modules. Any null breaks future incremental syncs and post-migration audits.
Risk if skipped: Null Source IDs force every subsequent upsert to treat the record as new, creating duplicates.

6b. Relationship validation

Verify Ticket-to-Contact links resolve. Pick 30 random Tickets and confirm the Contact name and email match source.
Verify Contact-to-Account links resolve. Pick 20 random Contacts and confirm the Account association.
Verify Thread sequence and direction on 20 random Tickets. Confirm threads display chronologically and inbound/outbound direction matches source.
Risk if skipped: Reversed direction makes agents reply to themselves, which has happened in real migrations.
Verify Parent-Child Ticket links via the Parent-Child extension UI. Pick 10 known parent-child pairs and confirm both directions resolve.
Verify Attachment files open and download correctly. Click 10 random attachments per module and confirm file integrity.

6c. Audit and compliance

Confirm the Source Created Date (or Zwitch-preserved Created Time) is populated everywhere. Run a query: count of records where the historical timestamp field is null should equal zero.
Run a GDPR compliance check on Contacts. Enable Compliance Settings on Zoho Desk if EU residents are in scope; verify the Data Privacy section appears on each Contact.
Export the Zoho Desk Audit Log for the cutover window. Navigate Setup > Privacy and Security > Audit Log and Export. Audit log export is limited to 30 days at a time and 50 exports per day.
Risk if skipped: Audit-log capture immediately post-cutover is the cheapest SOC 2 evidence; pulling it months later may not be possible.
Confirm data residency by reading the org's DC URL. Verify the org sits on the DC selected in Phase 0 (US, EU, IN, AU, JP, CN, CA, or SA).

6d. User-acceptance check

Have 3–5 agents validate their day-to-day workflows in production. Hands-on: open a Ticket, reply via email, post an internal comment, run a Macro, resolve and close. Document every snag.
Run a sample SLA report and compare to source. Confirm SLA-breach counts and average response/resolution times reconcile within tolerance.
Validate the ASAP customer self-service widget on a test site. Embed the widget snippet on a staging page and confirm KB articles render and ticket submission works.
Validate the Zoho Desk mobile app shows migrated data correctly. Mobile uses different rendering paths and can surface field-permission bugs the web app hides.
Validate every active channel: email forwarding, web form, SalesIQ chat, Zoho Voice, social, ASAP. Send a test message through each. Confirm a Ticket is created with the correct Channel value and lands in the right Department.
Risk if skipped: An unconfigured channel means inbound customer messages vanish silently.
Document every UAT issue with severity and owner.

6e. Sign-off

Get written sign-off from the migration sponsor. Email or ticket with the success-criteria document attached and each criterion marked pass.
Risk if skipped: Proceeding without sign-off leaves the project in a perpetual 'almost done' state.

Phase 7

Post-Migration Cleanup

Wrap up so the team can move on.

Watch list

Risks to track throughout

These risks live across multiple phases — keep an eye on them from kickoff through cutover.

Created Time can only be preserved via Zwitch, not via UI Import

Zoho Desk's standard UI Import stamps Created Time at the moment of insert and does not let the import override it. Only the Zwitch migration path preserves original Created Time and Closed Time. Decide the load path in Phase 0, plan the Source Created Date custom field in Phase 1 if UI Import is chosen, and flag the implications for ticket-aging and SLA-historical reporting before the analytics team builds dashboards on the wrong timestamp field.
Validation Rules fire on untouched fields during update

Zoho Desk Validation Rules trigger for every field during an update, including fields that the import did not modify. A rule that requires Resolution when Status is Closed will reject every Closed ticket on import even if the rule has nothing to do with the imported columns. Disable Validation Rules in Phase 1, keep them disabled through Phase 5, and run a re-validation pass in Phase 6 before reactivating.
ZIP and row ceilings on the UI Import path

The Zoho Desk UI Import accepts a single ZIP of CSVs, capped at 30 MB total and 10,000 rows per CSV. A 200,000-ticket migration requires at least 20 ZIPs run sequentially. Plan the batching in Phase 3, time the Sandbox runs in Phase 4, and confirm the cutover window in Phase 5 accommodates the serial submission rather than assuming a single bulk job.
Multi-channel inbox cutover happens outside the data load

Migrating Tickets does not migrate the email, web form, SalesIQ chat, Zoho Voice, social, or ASAP widget channels themselves — each must be configured independently in Zoho Desk and the source channel must be deactivated at the cutover moment. Track this from Phase 1 (channel setup) through Phase 5 (DNS/mailbox cutover) through Phase 6 (channel-by-channel UAT). A missed channel means inbound customer messages vanish silently.

Zendesk→Zoho Desk Intercom→Zoho Desk Freshdesk→Zoho Desk Gorgias→Zoho Desk

See Zoho Desk migration overview All Helpdesk migrations Estimate your migration

POPULAR PLATFORMS

POPULAR MIGRATIONS

POPULAR PLATFORMS

POPULAR MIGRATIONS

POPULAR PLATFORMS

POPULAR MIGRATIONS

POPULAR PLATFORMS

POPULAR MIGRATIONS

POPULAR PLATFORMS

POPULAR MIGRATIONS

Migration Checklist: Moving to Zoho Desk

Decide & Plan

Pre-Migration Prep

1a. Source-system audit and cleansing

1b. Destination-system setup

1c. People prep

Source Export

Transform & Map

3a. Mapping spreadsheet

3b. Data transformation

3c. Relationship and audit-trail decisions

3d. Helpdesk-specific transforms

Sandbox Test Migration

Production Cutover

Validate

6a. Reconciliation

6b. Relationship validation

6c. Audit and compliance

6d. User-acceptance check

6e. Sign-off

Post-Migration Cleanup

Risks to track throughout

The complete Zoho Desk migration guide

Migration Checklist: Moving to Zoho Desk

Decide & Plan

Pre-Migration Prep

1a. Source-system audit and cleansing

1b. Destination-system setup

1c. People prep

Source Export

Transform & Map

3a. Mapping spreadsheet

3b. Data transformation

3c. Relationship and audit-trail decisions

3d. Helpdesk-specific transforms

Sandbox Test Migration

Production Cutover

Validate

6a. Reconciliation

6b. Relationship validation

6c. Audit and compliance

6d. User-acceptance check

6e. Sign-off

Post-Migration Cleanup

Risks to track throughout

Common migrations to Zoho Desk

The complete Zoho Desk migration guide