Zendesk Chat Retires 2028: Migrate or Switch Platforms?

Zendesk removes Chat for messaging-eligible customers on January 31, 2028, announced August 4, 2026. The destination Zendesk provides is messaging, and for a lot of teams migrating in place is the obvious and correct answer.

But there is a structural fact about this particular retirement that deserves to be said out loud before anyone defaults to the obvious answer. You are going to rebuild your triggers, your routing, your widget configuration and your reporting regardless of where you end up. Zendesk's own documentation confirms that several categories of Chat configuration cannot be migrated automatically, and that some Chat concepts have no equivalent in messaging's data model at all.

The cost of rebuilding configuration is precisely the switching cost that keeps teams on an incumbent platform. This migration makes you pay a large share of it no matter what you choose. That does not mean you should leave — it means the comparison is more even than it was in July 2026, and making the choice by default rather than by decision is now a more expensive mistake.

This post stays scoped to the conversational layer and the retirement decision itself. It is not a general Zendesk alternatives roundup and it does not rank vendors; if you need suite-level vendor selection, our Zendesk alternatives guide covers that ground properly.

The Deadline That Forces the Decision

Date	Event
August 4, 2026	Zendesk announces Chat removal for messaging-eligible customers
Mid-2027	Realistic internal decision deadline — before configuration rebuild begins
October 2027	Recommended internal cutover target, ahead of year-end change freezes
January 31, 2028	Zendesk Chat removed
July 28, 2028	Chat dashboard access ends

Note the two rows that Zendesk did not publish. The decision deadline and the internal cutover target are yours to set, and they are both meaningfully earlier than the vendor's date.

The decision deadline matters more than teams expect. Once you begin reconstructing triggers and routing on messaging, you have spent the budget, the engineering attention and the organisational patience that would have funded a platform move. You do not get that twice in the same year. Rebuilding is the point of no return, not a reversible first step.

For the underlying facts, see Zendesk's removal announcement and the About the removal article. Eligibility is worth confirming first: the announcement covers accounts on Zendesk Suite or Support Suite, or holding both Chat and Support, with Agent Workspace as a prerequisite. Legacy Chat-only plans are outside this announcement and their removal has been confirmed but not dated. Our full end-of-life guide covers scope and timeline in detail.

Why the Switching Cost Argument Is Real

Vendor lock-in is mostly not contractual. It is the accumulated weight of configuration that works, that nobody fully documented, and that would take six months to reconstruct somewhere else.

That weight is what makes migrations get deferred year after year. The platform is imperfect, everyone knows it, and the rebuild cost exceeds the annual irritation. So you stay.

This retirement changes the arithmetic in one specific way: it moves a large block of that rebuild cost from the "only if we switch" column into the "happening anyway" column.

What You Rebuild No Matter What

Work through Zendesk's self-migration guide and the picture is concrete. Confirmed as not automatically migrated: mobile SDKs, third-party bots, skills-based routing, and reporting. On the APIs, Zendesk states flatly that "Chat APIs, Real-time APIs, and Incremental APIs are not supported in messaging" — a permanent removal rather than a migration gap.

On top of that, a set of common Chat objects — departments, shortcuts, widget appearance, proactive chat, visitor tracking, tags, agent capacity, historical transcripts — are not addressed by Zendesk's public migration documentation in either direction. Our companion post on what the migration wizard doesn't move works through each category and is explicit about which are confirmed and which are genuinely unknown.

So the honest baseline for migrating in place includes: rebuilding reporting in Explore, redesigning skills-based routing, re-integrating bots, re-doing mobile SDK work as an app release, replacing anything built on the Chat APIs with a different architecture, retraining agents on a different conversational model, and manually reconstructing an unknown quantity of configuration that the wizard does not cover.

That is not a small list, and it is the cheapest path's list.

What That Does to the Comparison

Here is the reframe. Suppose migrating in place is 100 units of work. Before August 2026, moving the chat layer to another vendor might have been 180 units — the same rebuild plus integration plus a new tool to learn — and that 80-unit delta is what kept you put.

The delta has not vanished, but it has shrunk, because a large part of what used to sit only in the switching column now sits in both. The question is no longer "is switching worth 180 units when staying is free." Staying is not free any more.

If you have been deferring a platform decision because of rebuild cost, this is the year that argument stops working.

Be careful not to overcorrect, though. The delta shrinks most for the conversational layer and barely at all for ticket history. That asymmetry is the entire reason the middle path exists.

Why Some of This Is Rebuild Rather Than Transfer

It is tempting to read the unmigrated list as an incomplete tool that Zendesk will eventually finish. That reading is partly wrong, and the distinction changes how you weight the paths.

Zendesk's own comparison of Chat and messaging describes live chat as offering "real-time, session based and synchronous support," while messaging conversations "can be picked back up without losing context or history." Those are different data models, not different implementations of the same one.

Chat is built on sessions and visitors: a bounded interaction, often with an anonymous browser tracked by behaviour, leaving a transcript behind. Messaging is built on end users and tickets: a durable conversation attached to an identified person, surviving closed tabs and changed devices.

The consequence for your decision is that certain capabilities have nowhere to land in messaging regardless of future wizard development. Proactive engagement triggered by live browsing behaviour assumes a presence signal and an interruptible session. Anonymous visitor state assumes an unidentified actor as a first-class object. These are not features awaiting a migration path; they are concepts messaging does not model.

If those capabilities are decorative in your setup, Path 1 is comfortable. If they are load-bearing — particularly in conversion-driven or pre-sales chat — then migrating in place is a functional downgrade you are choosing, and Path 2 exists precisely for that case. Work out which category you are in before you score the matrix, because it moves more rows than anything else.

The Three Paths

Path 1: Migrate in Place to Zendesk Messaging

Best fit: Teams whose Chat configuration is close to stock, who use the wider Zendesk Suite meaningfully, and who value continuity over optimisation. Also the right answer for anyone whose support organisation has limited capacity for change this year — there is no shame in choosing the path that finishes.

What moves: Zendesk's wizard handles triggers (converted into one or more messaging-compatible triggers, with activation status preserved), operating hours converted to schedules, pre-chat and offline forms, satisfaction ratings, banned visitors, and goals and conversion tracking. Ticket history stays exactly where it is, untouched. Agents keep one tool and one login.

What you rebuild: Everything on the unmigrated list — reporting in Explore, skills-based routing, third-party bots, mobile SDK integration — plus whatever the wizard turns out not to cover in your specific account, plus any Chat API integration, which needs a new architecture rather than a port.

Failure modes: The dominant one is assuming the wizard covers more than it does and discovering the gap at cutover. The second is treating messaging as live chat with a new name; it is a different data model, and agent workflow changes with it. The third is reporting discontinuity nobody warned leadership about, which surfaces as an accusation rather than a question.

The honest downside: You inherit whatever messaging does not do that Chat did, with no leverage to change it. If proactive engagement on live browsing behaviour is central to how you sell, messaging's asynchronous model is a real functional loss, not a transition inconvenience.

Path 2: Move the Conversational Layer, Keep Zendesk Support

Best fit: Teams where live chat is a major, sophisticated channel — proactive engagement, deep routing logic, heavily customised widget behaviour, conversion-driven use cases — and where messaging's model is a genuinely poor fit for those requirements. Also a good fit where the rest of the Suite is working fine and the only real complaint is the conversational surface.

What moves: The chat layer moves to a dedicated vendor. Zendesk Support stays as the ticketing system of record, so your ticket history, SLAs, macros, and agent workflow for non-chat channels are undisturbed. Conversations from the new layer integrate back into Support as tickets.

What you rebuild: The conversational configuration, on the new vendor's model rather than on messaging's. Roughly the same category of work as Path 1, aimed at a different destination — which is exactly the point of the switching-cost argument.

Failure modes: You now own an integration boundary. When chat conversations do not land in Support correctly, or land with the wrong requester identity, or duplicate, that is your problem and it sits between two vendors who will each point at the other. Budget for owning it properly rather than assuming the connector is finished software. The second failure mode is reporting fragmentation: chat metrics in one system, ticket metrics in another, and no single place that answers "how long did this customer wait."

The honest downside: Two vendors, two contracts, two support relationships, and one integration that is yours forever.

Path 3: Leave the Suite

Best fit: Teams who were already reconsidering Zendesk for reasons that predate this announcement, and for whom the forced rebuild removes the main practical obstacle to acting. Also teams where Chat is the primary support channel rather than one of several, which makes the Suite's other components less load-bearing than they look on the invoice.

What moves: Everything, and that is the crux. Ticket history, end users and organisations, macros, views, triggers and automations, SLAs, help centre content, attachments, and the conversational layer.

What you rebuild: All of it, on a new platform.

Failure modes: The one that matters is underestimating the historical data move. Chat configuration is a few hundred objects; ticket history is often millions of records with attachments, threaded comments, custom fields, and identity relationships that have to survive intact and searchable. Teams that scope Path 3 by thinking about the chat layer — which is what this retirement puts in front of them — arrive at a number that is wrong by an order of magnitude.

The honest downside: This is a materially bigger project than Paths 1 and 2, and the switching-cost argument does not fully apply to it. The rebuild you are being forced into covers the conversational layer. It does not cover moving years of ticket history. Anyone telling you the Chat retirement makes a full platform migration cheap is selling you something.

The Decision Matrix

Factor	Path 1: Zendesk messaging	Path 2: Dedicated chat + Zendesk Support	Path 3: Leave the Suite
Rebuild effort (chat layer)	High	High	High
Additional effort beyond baseline	None	Integration build and ownership	Full historical data migration
Ticket history risk	None — stays in place	None — stays in place	Significant — must be migrated
Vendors to manage	One	Two	One
Agent disruption	Moderate — new conversational model	Moderate to high — two surfaces	High — everything changes
Wizard assistance available	Yes, partial	No	No
Fit if proactive chat is core	Poor	Strong	Depends on vendor
Fit if skills routing is core	Requires redesign	Depends on vendor	Depends on vendor
Fit if Chat API integrations exist	Rebuild required	Rebuild required	Rebuild required
Reversibility	High	Moderate	Low
Typical timeline	Shortest	Medium	Longest

The row that decides most cases is ticket history risk. If your ticket history is large, old, regulated, or heavily referenced, Paths 1 and 2 are structurally safer than Path 3 by a wide margin, and no amount of dissatisfaction with Zendesk changes that arithmetic.

The row that decides the rest is fit if proactive chat is core. Proactive engagement on live browsing behaviour is the single requirement most likely to make messaging the wrong destination, because it depends on a session and presence model that messaging does not have.

What Actually Has to Move

Worth being concrete about the data in each path, because "migration" covers very different quantities of work.

Path 1 Data Scope

Chat configuration only. Triggers, hours, forms, banned visitors, CSAT, goals — the wizard's territory — plus the manual rebuild list. Ticket history does not move because it is already in Zendesk Support. Historical chat transcripts are the open question, and Zendesk's public documentation does not state what happens to them.

Path 2 Data Scope

Chat configuration, rebuilt on the new vendor. Ticket history stays in Zendesk. The new work is identity mapping: making sure a person who chats on the new layer resolves to the same end user in Zendesk Support rather than creating a duplicate. This sounds minor and is not — duplicate requester records degrade reporting, break SLA attribution, and produce the experience of a customer having to re-explain themselves, which is the exact problem messaging was supposed to solve.

Path 3 Data Scope

Everything. Tickets and their full comment threads, end users and organisations, attachments, custom fields, tags, macros, views, triggers, automations, SLA policies, help centre articles and their structure, and the conversational layer. Identity and relationship integrity across all of it. Our help desk data migration playbook covers how this work is actually sequenced, and the hidden costs of switching from Zendesk covers what tends to be left out of the estimate.

How to Decide

A sequence of questions, in the order that actually narrows the field.

1. Are you in scope, and for which wave? Suite, Support Suite, or Chat plus Support means January 31, 2028. Legacy Chat-only plans are outside this announcement with no published date. Answer this before anything else, because the two populations need different plans.

2. Is ticket history large, old, or regulated? If yes, Path 3 needs an extremely good reason. Weight the matrix accordingly and be honest that dissatisfaction is not, by itself, that reason.

3. Does messaging meet your hard requirements? Stand it up in a sandbox and run your genuinely difficult cases through it — skills routing, proactive engagement, custom widget behaviour, peak queue handling. Do not assume parity and do not assume failure. If messaging covers your requirements, Path 1 is almost certainly right.

4. Is the gap specifically in the conversational layer? If messaging fails your requirements but the rest of the Suite is serving you well, that is the exact shape Path 2 was built for. Resist the instinct to escalate a chat-layer problem into a whole-platform decision.

5. Were you already planning to leave within two years? If genuinely yes — with a business case that existed before August 2026 — then doing the rebuild once rather than twice is a real saving, and Path 3 deserves serious evaluation now rather than later.

6. What is your organisational capacity for change this year? This is the question that gets skipped and then quietly decides the outcome anyway. A team already absorbing a CRM migration, a reorganisation, or an Agent Workspace rollout should weight Path 1 heavily. The best path you cannot execute is worse than the adequate path you can.

The Checklist

1. Confirm your removal wave and whether Agent Workspace is already enabled, since it is a stated prerequisite and a project in its own right.
2. Inventory your full Chat configuration — triggers and activation states, routing and skills, departments, shortcuts, widget customisation, proactive campaigns, tags, forms, agent capacity.
3. Find every Chat API, Real-time API and Incremental API integration, plus mobile SDK embeds. These are rebuilds in every path.
4. Establish your sunk-cost baseline — the work you do regardless — so you are comparing marginal costs rather than total costs.
5. Test messaging against your hard requirements in a sandbox before assuming it does or does not fit.
6. Price the historical data move for Path 3 properly, including attachments and identity reconciliation, before it enters the comparison.
7. Score the matrix with explicit weights agreed by the people who will live with the outcome.
8. Set a decision deadline of mid-2027, and treat the start of configuration rebuild as the point of no return.
9. Export historical transcripts early to storage you control, in every path.
10. Pilot on one segment — a region, a brand, a low-volume product line — before full cutover.
11. Target October 2027 for cutover, not January 2028, so holiday freezes and year-end change windows do not compress your contingency to zero.

When to Bring In Help

If you are choosing Path 1 with a close-to-stock Chat configuration, you do not need outside help and you should not buy any. Run the wizard, work the manual list, rebuild your Explore dashboards, train the team. A capable Zendesk admin owns this end to end inside a quarter.

Help becomes worth considering at specific thresholds rather than at a company size: integrations built on the Chat, Real-time or Incremental APIs; a mobile SDK shipping in production; skills-based routing carrying real operational load; multi-brand or multi-region configuration that has diverged over years; a retention obligation attached to historical transcripts; or any serious evaluation of Path 3, where the historical data move dominates every other cost.

Keep two questions apart, because merging them is the most reliable way to blow the timeline. Who owns the runtime after migration — widget configuration, triggers, routing, agent workflow, vendor selection — is platform administration work. Your own team, or a Zendesk implementation partner, or the new vendor's professional services, is usually the right owner, and for Paths 1 and 2 that is most of the project.

Who preserves the data underneath it is a different discipline: ticket and conversation history, attachment handling, the relationships between users, organisations and tickets, identity continuity between anonymous chat visitors and known customers, and cutover sequencing that leaves no gap in the record.

ClonePartner works on that second question. Across 1,500+ migrations and 500+ integrations, the pattern we see most is teams who scoped the configuration rebuild carefully and scoped the historical data at zero — then discovered late that the transcripts they assumed would follow them did not, or that Path 3's data move was four times the estimate because nobody counted attachments and duplicate identities.

We are typically brought in when a team is seriously evaluating Path 3 and needs a real number rather than a guess, when historical conversations must stay searchable after cutover, when identity has to be reconciled across two systems in Path 2, or when a reporting gap across the cutover is not something the business can absorb.