How 1.4 million Zendesk tickets moved to Frappe Helpdesk

This article is part of our Frappeverse Mumbai 2026 coverage, including all nine keynotes and selected community stories.

Moving a support team away from Zendesk is already a serious implementation. Moving its history means carrying years of customer conversations, attachments, users and workflows into a system that agents can trust on day one.

At Frappeverse Mumbai 2026, Niraj Gautam, a senior software engineer at rtCamp, explained how his team moved one client from Zendesk to Frappe Helpdesk. The official talk title puts the migration at 1.4 million tickets. The scope slide rounded the working set to about 1.5 million tickets, alongside roughly 5 million replies and comments, 518 GB of attachments, 300,000 users and 200 customer-support agents.

The migration is useful for more than its size. The team separated extraction, files and verification instead of forcing everything through one script. It rebuilt the workflows agents depended on, customized the Helpdesk frontend without maintaining a full fork, and released two pieces of the migration infrastructure as open-source apps.

During the Q&A, another representative from the project team said the customer had been paying Zendesk $200,000 per year for 200 agents. Moving to a self-hosted open-source product removed that reported annual licensing expense, while leaving room for the support team to grow without another per-agent fee.

The migration was four jobs, not one

Zendesk data came from several APIs, with overlapping resources, rate limits and records that continued to change while the migration was being prepared. The team initially considered a custom extractor, then used Airbyte to pull Zendesk data into a temporary PostgreSQL database. Airbyte handled rate limits and incremental updates, giving the migration scripts one consistent source instead of a collection of live APIs.

Attachments took a separate path. Trying to move more than 500 GB of files while inserting ticket records would have made the migration slower and harder to recover. The client wanted the files in Azure Blob Storage, so the team moved them independently and connected them through Frappe Blob Storage.

The records themselves moved through Bench commands built with Frappe's ORM and Query Builder. Field and custom DocType mappings translated the Zendesk schema into Helpdesk. The team migrated the history year by year, checking data integrity after each phase before proceeding.

That staged approach was less dramatic than a single cutover, and much safer. Each verified batch gave the client evidence that the mapping worked before the next part of the archive moved.

Half the work began after the data arrived

Niraj described the migration as only half of the project. The other half was recreating the support workflow that agents already used every day.

The custom implementation added AI-assisted intent detection and response translation. A background job could classify a new ticket as a cancellation, refund or another intent, then expose that result inside the ticket. Because Helpdesk is open source, the client could connect the model it preferred instead of accepting one AI service tied to the support platform.

Macros combined prepared replies with actions. An agent could add an internal comment, change fields and prepare a customer response in one operation. Helpdesk showed the proposed changes as a draft before applying them, and one macro could be layered on another when a case needed more than one standard procedure.

Triggers handled event-driven business rules. Conditions could respond to a new ticket, a customer reply, a field change or another ticket event, then route the ticket, clear assignments, change fields or reply to the customer. Hourly automations covered time-based rules. The implementation also added agent time tracking and public ticket forms.

These were custom capabilities built for this client. Niraj said triggers and the advanced workflow work were being discussed with the Helpdesk team as possible upstream contributions. He did not present them as standard features already available to every Helpdesk installation.

They extended Helpdesk without forking it

Backend customization was the familiar part. The team placed its server logic in a custom Frappe app. The Vue frontend needed a different mechanism, so it created an override layer inside the custom application.

During a build, the layer first checks whether the custom app supplies an overridden frontend file. If it does, that file is used. If it does not, the build falls back to the original Helpdesk source. The same behavior works during development.

The result combines upstream Helpdesk with the client's frontend changes without copying the entire product into a permanent fork. In the Q&A, Niraj estimated that the implementation overrode about 20 to 30 frontend files. Those files still need review when Helpdesk changes, but the team can focus its upgrade work on a defined surface instead of reconciling a complete fork.

That is a sensible compromise for a client whose support operation cannot fit inside the standard product. It preserves a route to upstream upgrades while allowing the implementation to carry genuinely specific workflows.

Client work came back to the product

Some improvements were useful beyond this migration. Niraj said the project contributed dark mode, team mentions, read-replica use for GET APIs and a Redis search optimization back to Helpdesk.

Team mentions replaced a more cumbersome workaround. Agents could mention a Helpdesk team and notify its members without maintaining a separate user group only for mentions. Read replicas moved eligible GET traffic away from the writer database, while the search work removed Redis processing where the application did not need it.

The team also open-sourced Zendesk Migrator, which contains the scripts and schema mappings used to move data into Helpdesk. Frappe Blob Storage provides the attachment layer for Azure Blob Storage, including pre-signed URLs that keep file access inside the normal support workflow.

Neither app makes a migration of this size automatic. A team still has to understand its Zendesk schema, custom fields, workflows, retention requirements and cutover plan. They do, however, turn this project into a starting point for the next one.

The talk also surfaced a remaining product gap. An audience member asked how Helpdesk should share existing ERPNext masters when a company already runs its support process around ERPNext data. A Helpdesk representative said the integration work had started and would become stronger. That work will matter if Frappe wants Helpdesk to replace the older ERPNext Support module without asking customers to maintain the same business data twice.

For more detail, watch the Day 2 Track 1 livestream from the start of Niraj Gautam's session.