Helpdesk migration

Migrate from eTicket to Zoho Desk

Field-level mapping, validation, and rollback between eTicket and Zoho Desk. We move data and schema; workflows are rebuilt natively in Zoho Desk.

eTicket logo

eTicket

Source

Zoho Desk

Destination

Zoho Desk logo

Compatibility

83%

10 of 12

objects map 1:1 between eTicket and Zoho Desk.

Complexity

CModerate

Timeline

2-4 weeks

Rollback included Accuracy guarantee Field-level validation

Overview

What this migration involves

Moving from eTicket to Zoho Desk is a structural migration for support teams that have outgrown a lightweight single-instance ticketing tool. eTicket organizes support around a flat Ticket and Conversation model; Zoho Desk introduces multi-channel routing (email, chat, social, phone), department-scoped custom fields, role-based agent profiles, and SLA policies available from the Professional tier. We migrate Agents, Accounts/Contacts, Tickets with full conversation threads, and Attachments through Zoho Desk's API with email-based agent resolution. We flag eTicket custom ticket fields that must be recreated per-department in Zoho Desk, and we preserve original ticket IDs in a custom field since Zoho Desk assigns its own numbering. Workflows, SLAs, macros, and team structures do not migrate as code; we deliver a written inventory of these for your admin to rebuild in Blueprint and the SLA console after cutover.

Field-level fidelity

Every standard and custom field arrives verified.

Schema-aware mapping

AI proposes the map; you confirm before any record moves.

Relationships preserved

Parent–child, lookups, and ownership stay linked.

Full activity history

Calls, emails, meetings — with original timestamps.

Attachments & notes

Documents, uploads, and inline notes move with the record.

Why teams make this switch

Two sides of the same decision

Leaving

eTicket logo

eTicket

What's pushing teams away

  • The project is effectively dormant — the latest documented release (1.7.3) is from October 2008, with no modern development cadence, leaving customers exposed to unpatched dependency and security issues.
  • No public API and no modern integration story — teams that want to connect helpdesk data to CRM, BI, or modern automation tools have no native path.
  • PHP and MySQL stack assumptions are dated; deploying on modern hosting often requires patching PHP compatibility issues that the upstream project does not address.
  • Limited reporting and analytics — eTicket is a basic queue-and-conversation tool, with no SLA timers, no advanced workflow, and no dashboard depth that modern helpdesks ship by default.
  • Migration paths to modern helpdesks (Zendesk, Freshdesk, Help Scout) are entirely manual — there is no published export tool or supported migration partner, so teams must scrape the MySQL database directly.

Choosing

Zoho Desk logo

Zoho Desk

What's pulling them in

  • Deep Zoho ecosystem integration lets support data tie directly to CRM contacts, invoice records in Zoho Books, and custom apps built in Zoho Creator, providing a unified customer view without third-party middleware.
  • Pricing undercuts comparable platforms significantly: Enterprise at roughly $40 per agent per month versus Zendesk at comparable tiers, making it attractive for cost-sensitive teams scaling past 10 agents.
  • Blueprints and multi-level escalations allow teams to codify support workflows and enforce SLA routing automatically, reducing manual triage for mid-size support operations.
  • Multi-channel ticket ingestion unifies email, social media, live chat, and phone into a single queue view, giving agents one inbox without context-switching across channels.
  • The free tier up to 3 agents lets small teams validate the platform before committing, reducing financial risk for startups and micro-businesses evaluating help desk software.

Object mapping

How eTicket objects map to Zoho Desk

Each row shows how a eTicket object lands in Zoho Desk, including any object-level transformations, lookup resolution, or schema-design dependencies.

Typical mapping — final map is confirmed during the sample migration step.

eTicket

Ticket

maps to

Zoho Desk

Ticket

1:1
Fully supported

eTicket Tickets map directly to Zoho Desk Tickets. The original eTicket ticket ID is preserved in a custom field original_ticket_id__c on the Zoho Desk Ticket because Zoho Desk assigns its own sequential ticket number at import time. Ticket status, priority, and category map from eTicket field values to Zoho Desk Status and Priority picklists. Any eTicket custom ticket fields require pre-creation in Zoho Desk under the relevant department before migration begins because Zoho Desk custom fields are scoped per department.

eTicket

Conversation / Thread

maps to

Zoho Desk

Thread

1:1
Fully supported

eTicket conversation entries map to Zoho Desk Ticket Threads. Thread ordering is preserved by setting the Zoho Desk thread timestamp to the original eTicket message timestamp. Agent replies and customer messages are distinguished using eTicket's sender type field mapped to the Zoho Desk thread type (threadType: reply or comment). Internal notes in eTicket map to Zoho Desk private comments if the destination account has internal note visibility enabled.

eTicket

Attachment

maps to

Zoho Desk

Attachment

1:1
Fully supported

eTicket file attachments on tickets migrate to Zoho Desk Ticket Attachments. We download attachments from eTicket, verify MIME type and file size, then upload to Zoho Desk via the Desk API against the migrated ticket. Files exceeding Zoho Desk's attachment size limit are flagged for manual handoff or alternative storage. Note that Zoho Desk's native Zwitch import tool excludes KB article attachments; we handle ticket attachments as part of the standard migration scope.

eTicket

Customer / Contact

maps to

Zoho Desk

Contact

1:1
Fully supported

eTicket Customer records map to Zoho Desk Contacts. Email address serves as the dedupe key during import. If an eTicket Customer record lacks an email address, we generate a placeholder identifier and flag the record for admin review post-migration. Contact phone, company name, and address fields map to the corresponding Zoho Desk Contact fields. Any contact custom fields require pre-creation in Zoho Desk under the Contacts module before migration.

eTicket

Agent

maps to

Zoho Desk

Agent

1:1
Fully supported

eTicket Agents map to Zoho Desk Agents. Agent resolution uses email as the matching key: we match eTicket agent emails against Zoho Desk user accounts by email. If a matching Zoho Desk agent profile does not exist at migration time, we create the agent via the Desk API and send the invitation email. Agent roles (Admin, Agent) map to Zoho Desk Support Administrator and Agent profiles. Light Agent creation requires Professional or Enterprise tier.

eTicket

Team

maps to

Zoho Desk

Team

lossy
Fully supported

eTicket Teams map to Zoho Desk Teams. Zoho Desk requires teams to be created manually or via API before agent assignment. We create Zoho Desk Teams during migration setup using the Desk API, then map eTicket team membership to Zoho Desk team membership during the agent migration phase. The Zoho Desk Team Assignment setting must be enabled under Setup > Users and Control > Team Assignment for team routing to function post-migration.

eTicket

Organization / Company

maps to

Zoho Desk

Account

1:1
Fully supported

If eTicket stores Organization or Company records linked to Customers, these map to Zoho Desk Accounts. Account name becomes the Account Name field, and the domain or website maps to the Website field. Account-to-Contact linkage is resolved during the Contact migration phase using the AccountExtId reference.

eTicket

Tag

maps to

Zoho Desk

Tag

1:1
Fully supported

eTicket Tags on tickets map to Zoho Desk Tags. Tags migrate as a string array attached to the migrated ticket. Zoho Desk allows filtering by tag in ticket views and reports. If a tag references a content category or topic, we preserve it as a tag rather than converting it to a Zoho Desk Topic, which is used for Knowledge Base article organization.

eTicket

KB Article

maps to

Zoho Desk

Knowledge Base Article

1:1
Fully supported

eTicket KB Articles map to Zoho Desk Knowledge Base Articles. Articles migrate with title, body content, and category. Note that attachment migration for KB articles is excluded per Zoho Desk's native limitations on KB article file attachments; article attachments are inventoried in the handoff document for manual re-upload by the admin. Article-to-article internal links do not update automatically and are included in the link audit handoff.

eTicket

Custom Ticket Field

maps to

Zoho Desk

Custom Field (Department-scoped)

lossy
Fully supported

eTicket custom ticket fields require pre-creation in Zoho Desk under the relevant department before migration. We audit all eTicket custom fields during discovery, generate a Zoho Desk custom field creation checklist by department, and flag any field types that do not have a direct Zoho Desk equivalent (e.g., multi-select picklist, date range). Zoho Desk supports custom fields of type string, decimal, integer, currency, checkbox, date, datetime, and picklist per module per department.

eTicket

Product

maps to

Zoho Desk

Product

1:1
Fully supported

If eTicket tracks Products linked to tickets, these map to Zoho Desk Products. Product name, SKU, and description migrate. Products are imported before ticket migration so that the product reference on tickets resolves at import time.

eTicket

Task

maps to

Zoho Desk

Task

1:1
Fully supported

eTicket tasks linked to tickets map to Zoho Desk Tasks. Task title, description, due date, and assignee migrate. Task status maps from eTicket status values to Zoho Desk Task status values. Standalone tasks not linked to a ticket migrate as Zoho Desk Tasks under the linked Contact or Account.

Gotchas + challenges

What specifically takes care here

Platform-specific issues from each side, plus the pair-specific challenges that don't show up on either platform's page on its own.

eTicket logo

eTicket gotchas

High

Project is effectively dormant — latest release dates to 2008

High

No public API or vendor-supported export tooling

Medium

Attachments live on disk and can be orphaned

Medium

No SLA, automation, or modern routing engine

Zoho Desk logo

Zoho Desk gotchas

High

Agent email identity determines comment ownership after migration

High

Blueprints and SLA policies do not export via API

Medium

File upload capped at 10GB per migration batch

Medium

Tier-gated export and migration capabilities

Low

Inbound migration is two-phase with a hard Phase 2 cutoff

Pair-specific challenges

  • Original ticket IDs are not preserved in Zoho Desk

    Zoho Desk assigns its own sequential ticket number at import time regardless of the source ticket ID. If your team references eTicket ticket numbers in external documents, email threads, or SLAs, those references will break post-migration. We store the original eTicket ticket ID in a custom field original_ticket_id__c on every migrated Zoho Desk Ticket so that your team can search by the original ID and cross-reference historical records. Your admin must recreate this custom field per department in Zoho Desk before migration begins.

  • eTicket custom fields must be recreated per department in Zoho Desk

    Zoho Desk custom fields are scoped to a specific department, unlike eTicket's globally scoped custom fields. If eTicket has custom fields shared across all ticket categories, those fields must be created separately in each Zoho Desk department that will receive tickets. We audit all eTicket custom fields during discovery, document the required Zoho Desk field definitions (API name, data type, required/optional, picklist values), and provide a pre-migration checklist for your admin to create them before data import begins.

  • Conversation threading requires timestamp ordering during import

    eTicket conversation entries must be imported into Zoho Desk Threads in strict chronological order to preserve the support agent and customer dialogue sequence. If entries are inserted out of order, the thread renders with messages appearing in the wrong sequence. We sequence the conversation export from eTicket by message timestamp, resolve the agent Contact record reference for each thread entry, and insert threads into Zoho Desk in a single ordered batch per ticket to avoid interleaving from concurrent import operations.

  • KB article attachments do not migrate through Zoho Desk

    Zoho Desk's native Zwitch import and Desk API exclude file attachments from Knowledge Base article migration. If your eTicket KB articles contain screenshots, PDFs, or linked files, those files must be re-uploaded manually after migration. We inventory every eTicket KB article attachment during discovery, generate a list of file names, URLs (if accessible), and article associations, and provide this to your admin as a manual re-upload checklist.

  • Agent email match is required before migration; deactivated agents cannot transfer tickets

    Zoho Desk matches incoming agent records by email address. An agent with a given email that already exists in Zoho Desk is linked to the existing profile. Agents in eTicket who have been deactivated or whose email addresses are not valid Zoho Desk login credentials cannot have their tickets migrated directly to them. We run agent reconciliation before the ticket migration phase, identify any unmatched or deactivated agents, and map their open tickets to an active Zoho Desk agent designated by your admin.

Migration approach

Six steps for a successful eTicket to Zoho Desk data migration

  1. Discovery and eTicket data audit

    We audit the eTicket instance across all modules: ticket count, conversation volume, attachment file sizes and counts, agent count, customer/contact count, team structure, custom fields, KB articles, and any product or task records. We extract a representative data sample to validate field types, required-field coverage, and timestamp formats. The output is a written migration scope document with object-level record counts, a Zoho Desk department layout plan, and a list of eTicket custom fields that require pre-creation in Zoho Desk.

  2. Zoho Desk schema preparation

    We guide your admin through Zoho Desk setup: creating departments, provisioning agent profiles (Agent, Light Agent, Support Administrator), creating teams, and recreating eTicket custom fields per department. We also configure ticket status and priority picklist values to match eTicket's taxonomy, and we create the original_ticket_id__c custom field on the Ticket module for ID preservation. All schema work happens in the production Zoho Desk account or a sandbox, depending on your preference, before any data extraction from eTicket begins.

  3. Agent and User provisioning

    We extract every distinct agent email from eTicket and match against Zoho Desk User records. Agents without a matching Zoho Desk profile are created via the Desk API and sent invitation emails. We document the mapping of each eTicket agent to their Zoho Desk counterpart, including any role elevation (e.g., eTicket admin to Zoho Desk Support Administrator). Deactivated or unresolvable agents are flagged and assigned to a designated fallback Zoho Desk agent.

  4. Contact and Account migration

    We extract eTicket Customers and any Organization records, deduplicate by email, and import into Zoho Desk Contacts and Accounts in dependency order: Accounts first (so AccountExtId is available), then Contacts (resolving AccountId lookup). Custom contact fields require pre-creation per department. Any eTicket Customers without email addresses are flagged with a placeholder identifier for admin review post-migration.

  5. Ticket and conversation migration with threading preserved

    We extract eTicket tickets in chronological order, resolve the assignee agent ID against the Zoho Desk agent mapping, resolve the contact ID against the migrated Contacts, and insert tickets via the Zoho Desk API. Conversation threads are inserted immediately after each ticket, preserving message order by timestamp. Attachments are downloaded from eTicket and uploaded to Zoho Desk against the migrated ticket. We chunk large ticket batches to avoid API timeout and validate record counts at each batch boundary. The original eTicket ticket ID is written to original_ticket_id__c on every migrated ticket.

  6. KB article, tag, and product migration

    KB articles are migrated to Zoho Desk Knowledge Base articles with title, body content, and category. Attachment inventory is compiled for manual re-upload. Tags are migrated as ticket tags. Products are migrated if present in the scope. These modules are independent of ticket dependency chains and run in parallel with the contact/account phase where possible.

  7. Cutover, validation, and automation rebuild handoff

    We freeze eTicket write access during the cutover window, run a final delta migration of any tickets created or modified during the migration, then enable Zoho Desk as the system of record. We validate record counts across all modules, spot-check 25-50 tickets for thread completeness and attachment presence, and deliver the Workflow and Automation Inventory document listing every eTicket automation requiring rebuild in Zoho Desk Blueprint and SLA console. We provide a one-week hypercare window for reconciliation issues. We do not rebuild eTicket workflows, macros, or SLAs as code; that work is handled by your admin using the provided inventory.

Platform deep dives

Context on both ends of the pair

eTicket logo

eTicket

Source

Strengths

  • Free and open-source self-hosted PHP/MySQL helpdesk.
  • Email-to-ticket (pop3/pipe) and web-form ticket creation in the core distribution.
  • Skinnable to match the host website's branding.
  • Multi-lingual UI and CAPTCHA / spam filtering included.
  • Full database ownership for teams that need on-premise data control.

Weaknesses

  • Project is effectively dormant; last release in October 2008.
  • No public API or supported migration tooling — exports go through direct MySQL queries.
  • No SLA engine, no automation rules, no modern reporting.
  • PHP / MySQL stack compatibility issues on modern hosting are not addressed upstream.
  • Limited third-party community or commercial support for new deployments.
Zoho Desk logo

Zoho Desk

Destination

Strengths

  • Generous free tier for teams of up to 3 agents with no time limit, reducing financial risk for small support operations.
  • Per-agent flat pricing across tiers is significantly lower than Zendesk, Freshdesk, or Intercom at equivalent feature levels.
  • Tight integration with Zoho CRM, Zoho Books, and Zoho Creator provides a unified data ecosystem without third-party middleware.
  • Multi-channel ticket aggregation consolidates email, social, chat, and phone into a single queue view.
  • Assisted migration service handles the two-phase transfer process with Zoho's own migration team for inbound moves.

Weaknesses

  • The UI is frequently described as dated, clunky, and inconsistent across modules compared to modern SaaS competitors.
  • Advanced automation features including Blueprints, multi-brand, and live chat are tier-gated, limiting the free and Express plans to basic ticketing.
  • Non-Zoho integrations require custom Deluge scripting or external middleware, reducing flexibility for heterogeneous tech stacks.
  • Steep learning curve and complex customization options mean slower onboarding for new agents and ongoing training investment.
  • Export and migration capabilities are gated by plan tier, with data backup only available on higher plans.

Complexity grading

How hard is this migration?

Moderate Helpdesk migration. 6 of 7 objects need a mapping; the rest are 1:1.

C

Overall complexity

Moderate migration

Derived from compatibility, mapping clarity, API constraints, and data volume across eTicket and Zoho Desk.

  • Object compatibility

    D

    6 of 7 objects need a mapping; the rest are 1:1.

  • Field mapping clarity

    C

    Field mapping is derived from defaults — final spec confirmed during the sample migration.

  • Timeline complexity

    B

    7-object category — typical timelines run 2–7 days end-to-end.

  • API constraints

    B

    eTicket: Not applicable — no API surface exists..

  • Data volume sensitivity

    B

    eTicket doesn't expose a bulk API — REST + parallelization used for high-volume runs.

Estimator

Estimate your eTicket to Zoho Desk migration cost

Rule-based pricing — no per-record fees, no manual quotes. Migrations over 2M records are scoped individually.

Step 1

What are you migrating?

Pick a category, then your source and destination platforms.

Category

FAQ

Frequently asked questions about eTicket to Zoho Desk data migrations

Answers to the questions buyers ask most during eTicket to Zoho Desk migration scoping. Not seeing yours? Book a call.

Can't find your answer?

Walk through your eTicket to Zoho Desk migration with a real engineer — 30 minutes, free, written quote within 24 hours.

Book a free 30 minute consultation

Most eTicket to Zoho Desk migrations land between two and four weeks for accounts under 10,000 tickets with clean agent and contact data. Migrations exceeding 50,000 tickets, large attachment sets, multi-department structures, or eTicket KB article libraries move to five to nine weeks because of attachment chunking, thread ordering validation, and custom field recreation scope. A representative sample migration in the first week establishes the actual throughput rate and refines the timeline estimate.

Adjacent paths

Related migrations to explore

Ready when you are

Move from eTicket.
Land in Zoho Desk, intact.

Tell us record counts and timeline. We'll come back with a written quote inside 1 business day — no commitment, no sales pitch.

Accuracy guarantee Rollback included Quote in 1 business day