Should I migrate before or after my Zendesk renewal?

Time the cutover to land just before your Zendesk renewal so you do not pay for two systems at once and you do not auto-renew a year you will not use. Because the import runs in parallel with zero downtime, you can start the migration weeks before the renewal date, keep answering in Zendesk the whole time, and flip channels over only once the single-queue pilot has validated. Renewal-timed migrations are also the fastest in our data, since the deadline forces a clean sequencing decision.

How to Migrate from Zendesk to Richpanel: A Step-by-Step Playbook

Q: Will I lose my historical tickets, macros, and tags when leaving Zendesk?

No. Historical tickets, comments, attachments, contacts, organizations, tags, and users import via API and are preserved. Macros and canned responses map to saved replies and to the AI's knowledge. Across 69 buyer demos, zero deals were lost to migration friction once a one-click import was on the table, and brands have moved hundreds of thousands of historical conversations in hours. What does not copy across as data is your trigger and automation logic and your marketplace app integrations: those are reconfigured, not exported, which is the part this playbook spends the most time on.

Q: Can my team keep working in Zendesk during the migration?

Yes, and they should. The safe sequence is zero downtime: your team keeps answering tickets in Zendesk while the historical data imports in parallel and the AI is evaluated on your own past tickets. You then pilot the AI on a single queue (for example, where-is-my-order) in collaborative mode before any full cutover. A dedicated implementation manager runs the migration end to end and signs off before you go live. Channels are switched over only after the pilot validates, and Zendesk is kept read-only for a window so nothing is stranded.

Q: What does not transfer one-to-one from Zendesk?

Four things are reconfigured rather than copied. (1) Triggers and automations: the logic is re-expressed as routing rules and AI SOPs, not imported as code. (2) Marketplace apps and webhooks: each integration is reconnected to its source system. (3) Guide / Help Center theming and its SEO: the articles import as knowledge, but a themed public help center is a re-platform decision. (4) Zendesk-specific constructs such as Sunshine custom objects, side conversations, light agents, and deep historical reporting, which stay queryable in a read-only Zendesk export. Naming these upfront is what keeps a two-week migration from becoming a surprise.

Q: When should I stay on Zendesk instead of migrating?

Stay if Zendesk is your system of record for functions well beyond customer experience (IT service management, internal help desks, asset tracking) and CX is only one of many workflows running on it. Stay if you depend on a niche Zendesk Marketplace app with no equivalent elsewhere, or if you have already paid for and operationalized Zendesk QA (Klaus) and workforce management across a large agent pool. Migration makes sense when CX is the primary use case, your bill is climbing because AI and QA are stacked add-ons, and you want AI-native autonomous resolution proven on your own tickets before go-live.

Why this migration is happening

The trigger is rarely the software. It's the stacking bill.

Across 69 buyer demos in spring 2026, Zendesk was the second most-cited incumbent teams were leaving, after Gorgias. The recurring phrases were consistent: "add-on costs doubling," "no built-in AI," "legacy lock-in."

The cost story is specific, and it is the reason most teams start shopping. Zendesk's AI is not part of the platform. The Advanced AI add-on is listed at $50 per agent per month to unlock automated resolutions, which are then billed at roughly $1.50 to $2.00 per resolution. Quality assurance is a separate product too: Zendesk QA, the rebranded Klaus platform Zendesk acquired, runs about $35 per agent per month. Stack a per-agent Suite seat on top of an AI add-on on top of per-resolution fees on top of a QA seat, and you get the "my Zendesk bill doubled" conversation that opens most of these calls.

A second trigger is timing. Annual contracts auto-renew, and a renewal date is the forcing function that turns "we should look at this" into "we are moving." In our buyer data, contract-expiry deals close three to five times faster than the median, because the deadline forces a clean sequencing decision. One team cut over in nine days when its Zendesk contract expired in eight.

None of this is an argument that Zendesk is a bad platform. It is the broadest helpdesk on the market and a genuinely safe enterprise default. The argument is narrower: if customer experience is your primary use case and your bill is climbing because the AI and the QA are bolt-ons, the math stops working. The rest of this playbook assumes you have already made that call. If you have not, read the companion piece, Best Zendesk Alternatives for AI Customer Service, which compares the options honestly and includes a line for staying put.

The honest reframe

The risk was never the export. It's the reconfiguration.

Ask a team why they are afraid to leave Zendesk and they will describe a data nightmare: years of tickets, hundreds of macros, a tagging taxonomy nobody fully remembers, attachments, customer history. The instinct is that all of this is fragile and will be lost in transit.

It is not fragile, and it is not the hard part. Tickets, comments, attachments, contacts, organizations, tags, and users move through an API import that runs in the background while your team keeps working. Brands have moved hundreds of thousands of historical conversations in hours, not months. Across all 69 demos, zero deals were lost to migration friction once a one-click import was on the table. The export is solved.

The work that actually takes thirteen of your fourteen days is the part nobody warns you about: your triggers, your automations, and your marketplace integrations. Those are not data. They are logic and connections, and logic does not export. A Zendesk trigger that routes VIP tickets to a priority group, or an automation that sets an SLA breach reminder, or a Marketplace app that posts refunds into your accounting system: each of these has to be re-expressed in the new system, not copied. Get that inventory wrong and a "two-week migration" becomes a two-month one, not because the data was hard, but because a routing rule you forgot quietly broke on day three.

So the playbook is built around one principle: spend your effort on the logic, automate the data, and never take the old system offline until the new one has proven itself on a real queue.

The playbook

Seven phases, zero downtime.

Each phase has an owner and an exit condition. A dedicated implementation manager runs the sequence end to end and signs off before you go live. Your team keeps answering tickets in Zendesk until phase six.

Audit what you actually use, before touching any data.

Most teams discover they pay for far more configuration than they use. The audit is the single highest-leverage hour of the whole migration.

Inventory every live construct in your Zendesk: triggers, automations, macros, ticket forms, custom fields, organizations, groups, views, SLA policies, business hours, brands, light agents, and the full list of installed Marketplace apps and outbound webhooks. For each one, mark it keep, retire, or rebuild. The point is not to recreate Zendesk. It is to carry forward only the logic that still earns its place, and to surface the integrations that will need reconnecting in phase six.

Exit condition: a single sheet listing every automation and integration with a keep / retire / rebuild decision. If you cannot name what each trigger does, that is exactly the institutional knowledge a migration is meant to capture, not lose.

Map the data model, one-to-one.

Zendesk's objects have direct homes in Richpanel. Mapping them explicitly before import is what prevents a field landing in the wrong place at scale.

Organizations and users map to customers and companies. Tickets and comments map to conversations and messages. Custom fields and ticket forms map to Richpanel's custom fields and data model, field by field. Tags carry across verbatim. Macros and canned responses map two ways: to saved replies for your human agents, and into the AI's knowledge so it can use the same language. Assignment routing and escalation rules become Richpanel routing rules. The implementation manager builds this map with you and validates it against a sample before the full import runs.

Exit condition: a field-by-field mapping document, validated on a 50-ticket sample, with no orphaned custom fields.

Import the history in parallel. Nobody stops working.

The import runs in the background while your agents keep answering tickets in Zendesk. There is no freeze window and no downtime.

Historical tickets, comments, attachments, contacts, organizations, tags, and users move through the API on the mapping built in phase two. For scale: brands have imported hundreds of thousands of conversations in hours. Real examples from our onboardings include a brand that moved 482,000 conversations in three to four hours and a multi-brand operation that moved more than a million tickets. The volume is not the constraint. While this runs, your team is unaffected, because the new system is not yet serving customers.

Exit condition: ticket counts reconcile between Zendesk and Richpanel, attachments resolve, and a spot-check of recent and old conversations renders correctly.

Bootstrap the AI on your own knowledge.

The CX Manager AI reads your business and drafts your SOPs, brand voice, and tool wiring in about 20 minutes. On cutover day it is roughly 80% bootstrapped.

This is the step Zendesk does not have an equivalent for, and it is why the migration produces an autonomous agent rather than just a relocated inbox. The CX Manager AI ingests your Help Center and Guide articles, your imported historical tickets, your product pages, and public sources, then drafts the SOPs and brand voice your agent will use. You bring the business; it brings the AI engineering (context engineering, retrieval, permissions, escalation logic). Brand-voice edits are made in plain language without code.

Exit condition: drafted SOPs and brand voice reviewed by your CX lead, with the obvious gaps (returns policy, escalation triggers, refund limits) filled in.

Pilot one queue. Let the eval gate it.

Before the AI touches a real customer, it is scored against your own historical Zendesk tickets. Below the accuracy threshold, it does not go live. Then it runs one queue in collaborative mode while Zendesk still handles the rest.

The pre-launch evaluation pulls a stratified sample of your past resolved tickets (with PII stripped), runs the AI against the customer message, and scores its response against what your human agents actually wrote. The agent does not graduate to production traffic until it crosses a 95 to 99% accuracy bar on your data. Then you point it at a single, high-volume, low-risk intent, where-is-my-order is the usual choice, in collaborative mode so a human approves each reply. This is the safe sequence: a pilot on one queue before any full cutover, with the rest of your volume still flowing through Zendesk untouched.

Exit condition: the pilot queue runs for several days at or above your accuracy bar, your team trusts the drafts, and you are ready to expand intents and switch to autonomous mode.

Validate and cut over, timed to your renewal.

Channels switch to Richpanel only after the pilot validates. The implementation manager signs off. Zendesk is kept read-only so nothing is stranded.

Now the reconfiguration from phase one comes due. Re-express the triggers and automations you marked keep as Richpanel routing rules and AI SOPs. Reconnect the Marketplace apps and webhooks to their source systems. Then move the channels: email forwarding, the chat widget, social, and SMS point to Richpanel. Open tickets in flight are handled deliberately, the backlog is either drained in Zendesk or migrated as open conversations, never silently dropped. Time this flip to land just before your Zendesk renewal so you are not paying for two systems or auto-renewing a year you will not use.

Exit condition: all channels resolve into Richpanel, every kept automation has a working equivalent, integrations post correctly, and the implementation manager has signed off.

Decommission Zendesk on your terms.

Keep Zendesk read-only through one full billing and reporting cycle, then export and cancel at renewal.

Do not cancel the day you cut over. Keep the Zendesk instance read-only for a window so historical reporting, any in-flight disputes, and edge-case lookups stay reachable while your team builds confidence in the new system. Export a final archive of tickets and reporting for your records. Then cancel at the renewal date you planned the whole migration around. The ramp to 50% autonomous resolution continues from here over the first 30 days; cutover is the start of that curve, not the end.

Exit condition: final Zendesk export archived, cancellation confirmed at renewal, and the AI's resolution rate climbing on its 30-day ramp.

What the calendar actually looks like

About two weeks to cut over. Thirty days to 50%.

The phases overlap. The import and the AI bootstrap run while your team works. Here is the realistic calendar for a mid-market team: go-live on a pilot queue happens fast, full validated cutover lands inside two weeks, and autonomous resolution is a 30-day ramp.

When	Phase	Who is serving customers
Day 1	Audit + data-model map (01–02)	Your team, in Zendesk
Days 1–3	Parallel import + AI bootstrap (03–04)	Your team, in Zendesk
Days 3–7	Pre-launch eval + single-queue pilot (05)	Zendesk, plus AI drafting on one queue
Days 7–14	Reconfigure automations + integrations, validate, cut over (06)	Channels move to Richpanel as each validates
Day ~14	Full cutover, Zendesk read-only	Richpanel, all channels
Day 30	Autonomy ramp continues (07)	Richpanel, ~50% autonomous resolution

Two numbers anchor the schedule and they are not the same number. Live means the AI is resolving real tickets on a validated queue, which happens inside the first week. 50% autonomous resolution is an outcome that compounds as the CX Manager AI captures new patterns and your pre-launch eval coverage expands, which is a 30-day ramp. Conflating the two is how vendors promise "live in five minutes" and then disappoint. The honest version is a one-week go-live, a two-week full cutover, and a 30-day ramp to half your volume.

What the ramp looks like in production

A wellness brand ran 4,881 fully autonomous AI replies in 42 days at 4.43 / 5 CSAT, higher than its own human team's average.

That is the curve a migration is buying: not a relocated inbox, but an agent that resolves a growing share of volume without human review, on the same history you imported from your old helpdesk. Read the full case study →

The honest caveat

What does not transfer one-to-one, and how to handle it.

A migration guide that claims everything copies across perfectly is selling. Four classes of thing are reconfigured rather than imported, and naming them is what keeps the timeline honest.

Triggers and automations. The logic does not export as code. Each rule you marked keep in phase one is re-expressed as a Richpanel routing rule or an AI SOP. This is deliberate work, and it is why phase one matters: an un-inventoried automation is the most common cause of a post-cutover surprise.
Marketplace apps and webhooks. Zendesk has a large app marketplace. Each integration you use is reconnected to its source system in phase six, not migrated. Most common integrations (Shopify, Recharge, Loop, Klaviyo, Slack, the major carriers) have native equivalents; a niche app may not, which is exactly what the audit surfaces.
Guide / Help Center theming and SEO. Your Guide articles import as AI knowledge immediately. A public, themed, search-indexed help center is a separate re-platform decision with its own redirect and SEO plan. Treat it as a follow-on project, not a cutover blocker.
Zendesk-specific constructs and deep history. Sunshine custom objects, side conversations, light-agent structures, and granular historical reporting do not all have one-to-one homes. The mitigation is the read-only Zendesk window in phase seven: the deep history stays queryable while your new reporting baseline builds.

The honest claim is not "nothing changes." It is that the data you are afraid of losing is preserved, and the things that genuinely change are known in advance, owned by a named person, and validated before go-live.

When not to migrate

Three cases where you should stay on Zendesk.

Zendesk's maturity is real. We have lost deals to it for good reasons, including a six-figure account whose CTO simply wanted "a stable, proven platform like Zendesk." If your situation matches one of these, migrating is the wrong move.

Zendesk runs far more than CX.

If it is your system of record for IT service management, internal help desks, or asset tracking, and customer support is one of many workflows on it, the breadth you would give up outweighs the AI you would gain. Add Zendesk's Advanced AI instead.

You depend on a niche Marketplace app.

Zendesk's app ecosystem is vast. If a specific integration with no equivalent elsewhere is load-bearing for your operation, the reconnection cost may not be worth it. The phase-one audit tells you this before you commit.

You have already operationalized Zendesk QA.

If you have paid for and built workflows around Zendesk QA (Klaus) and workforce management across a large agent pool, you have already absorbed the add-on cost that triggers most migrations. The bill argument is weaker for you.

Migration makes sense when the opposite is true: CX is your primary use case, your bill is climbing because AI and QA are stacked add-ons rather than platform features, and you want autonomous resolution proven on your own tickets before go-live, on flat per-conversation economics (about $0.30 per conversation) rather than per-seat plus per-resolution fees. If that is you, the playbook above is the safe path. If it is not, staying is the right call, and we would rather tell you that now than have you cut over and regret it.

Before you flip the switch

The pre-cutover checklist.

Do not move a single channel to the new system until every line below is true. This is the list the implementation manager signs off against in phase six.

1. Ticket counts reconcile.

Imported ticket, contact, and organization counts match Zendesk within tolerance, and attachments resolve. Spot-check the oldest and newest conversations.

2. Every kept automation has an equivalent.

Each trigger and automation marked keep in the audit has a working Richpanel routing rule or SOP, tested with a sample ticket.

3. Integrations post correctly.

Every reconnected Marketplace app and webhook fires against its source system on a live test, not just a saved config.

4. The pre-launch eval cleared the bar.

The AI scored 95 to 99% against your own historical tickets, and you have reviewed the specific failures, not just the headline number.

5. The pilot queue earned trust.

One queue ran in collaborative mode for several days and your team is comfortable expanding intents and moving to autonomous mode.

6. The open-ticket backlog has a plan.

In-flight tickets are either drained in Zendesk or migrated as open conversations. Nothing is silently dropped at cutover.

7. Zendesk stays read-only.

The old instance remains reachable for historical lookups and reporting through at least one billing cycle before cancellation.

8. Cancellation is timed to renewal.

The cutover lands just before the Zendesk renewal date, so you never pay for two systems or auto-renew a year you will not use.

Frequently asked

Leaving Zendesk, in plain English.

How long does it take to migrate from Zendesk to Richpanel?

Plan for about two weeks end to end for a mid-market team. The historical import runs in the background in hours. The AI is built on your knowledge in roughly 20 minutes and is about 80% bootstrapped on cutover day. Go-live on a single pilot queue happens within about a week; full validated cutover across all channels lands inside two weeks. Reaching 50% autonomous resolution is a 30-day ramp, not a launch-day number. Contract-expiry deals move fastest: in our buyer data one team cut over in nine days when its Zendesk contract expired in eight.

Will I lose my historical tickets, macros, and tags?

No. Tickets, comments, attachments, contacts, organizations, tags, and users import via API and are preserved. Macros and canned responses map to saved replies and into the AI's knowledge. Across 69 buyer demos, zero deals were lost to migration friction once a one-click import was on the table, and brands have moved hundreds of thousands of conversations in hours. What does not copy as data is your trigger and automation logic and your marketplace integrations: those are reconfigured, not exported, which is the part this playbook spends the most time on.

Can my team keep working in Zendesk during the migration?

Yes, and they should. The sequence is zero downtime: your team keeps answering in Zendesk while the data imports in parallel and the AI is evaluated on your past tickets. You then pilot the AI on a single queue in collaborative mode before any full cutover. A dedicated implementation manager runs the migration end to end and signs off before you go live. Channels switch over only after the pilot validates, and Zendesk is kept read-only so nothing is stranded.

What does not transfer one-to-one from Zendesk?

Four things are reconfigured rather than copied: triggers and automations (the logic is re-expressed, not imported), Marketplace apps and webhooks (each reconnected to its source system), Guide / Help Center theming and SEO (a re-platform decision, though articles import as knowledge), and Zendesk-specific constructs such as Sunshine objects, side conversations, light agents, and deep historical reporting (which stay queryable in a read-only export). Naming these upfront is what keeps a two-week migration from becoming a surprise.

When should I stay on Zendesk instead of migrating?

Stay if Zendesk is your system of record well beyond CX (IT service management, internal help desks, asset tracking), if you depend on a niche Marketplace app with no equivalent, or if you have already operationalized Zendesk QA (Klaus) and workforce management across a large team. Migrate when CX is the primary use case, your bill is climbing because AI and QA are stacked add-ons, and you want autonomous resolution proven on your own tickets before go-live.

Should I migrate before or after my renewal?

Time the cutover to land just before your Zendesk renewal so you do not pay for two systems or auto-renew a year you will not use. Because the import runs in parallel with zero downtime, you can start weeks before the renewal date, keep answering in Zendesk the whole time, and flip channels only once the single-queue pilot has validated. Renewal-timed migrations are also the fastest, since the deadline forces a clean sequencing decision.

Keep reading

Decide first, then migrate.

This playbook assumes the decision is made. If you are still comparing, start with the honest comparison and the evaluation framework, then come back here to execute.

Best Zendesk Alternatives for AI Customer Service (2026): the criteria-first comparison across Richpanel, Intercom Fin, Decagon, Ada, and Zendesk, including a decision line for staying on Zendesk.
The Best AI Agents for Customer Support in 2026: the broader category comparison and the six tests that cut through any demo.
The AI Customer Service Vendor RFP Template: 40 questions and a scoring rubric for a formal evaluation.
Richpanel migration overview: how the import and implementation-manager-led cutover work across Zendesk, Gorgias, Freshdesk, Zoho, and Gmail.

Most teams budget two months to leave Zendesk. The data import takes hours. The other thirteen days are the real work.