Zendesk Chat End of Life: The 2028 Migration Guide

Zendesk Chat is removed for messaging-eligible customers on January 31, 2028. Zendesk announced the removal on August 4, 2026, which gives roughly eighteen months between the announcement and the date the channel stops being a channel. The forced destination is Zendesk messaging.

That eighteen months sounds generous. It is not, and the reason is specific: this is not a version upgrade where the same objects land on a newer runtime. Live chat and messaging are different data models. Chat is session-based and synchronous. Messaging is continuous and ticket-backed. Some of what you run today has no equivalent on the other side, and Zendesk's own documentation says so plainly.

This guide covers the verified timeline, exactly who is in scope and who is not, why Zendesk is doing this, what actually breaks on removal day, and how to sequence the work. Two companion posts go deeper on the specific gaps in Zendesk's migration tooling and on the migrate-or-switch decision.

The January 31, 2028 Hard Deadline

Here is the published timeline:

Date	Event
2020	Last year Chat received feature enhancements, per Zendesk's own statement
August 4, 2026	Zendesk announces removal of Chat for messaging-eligible customers
August 2026 – January 2028	Transition window; settings migration wizard available, with more settings added over time
January 31, 2028	Zendesk Chat removed for messaging-eligible customers
July 28, 2028	Chat dashboard access ends
Not announced	Separate removal for legacy Chat-only plans — confirmed by Zendesk, no dates published

Two things in that table deserve more attention than they usually get.

The first is the gap between January 31, 2028 and July 28, 2028. Roughly six months separate the removal of Chat from the end of Chat dashboard access. Zendesk states customers "retain full access to the Chat dashboard until July 28, 2028." What Zendesk does not spell out is precisely which dashboard functions remain useful once the channel behind them has been removed. Reading that as a guaranteed six-month data-export window is an assumption, not a documented commitment. Plan your exports around the January date and treat anything after it as a bonus.

The second is the last row. The separate removal wave for legacy Chat-only plans is confirmed but undated. If that is you, the worst thing you can do is borrow the January 31, 2028 deadline and assume it is yours.

For the primary sources, see Zendesk's removal announcement and the longer About the removal of Zendesk Chat and migration to messaging article.

Eighteen months is the runway, not the project length. The project length is however long it takes you to find every integration nobody documented.

Am I Actually Affected? Scope and Eligibility

The announcement applies to messaging-eligible customers, and Zendesk defines that term precisely. Your account qualifies if it has a Zendesk Suite or Support Suite plan, or if it includes both Zendesk Chat and Zendesk Support. Zendesk states the requirement directly: "Your account must have a Zendesk Suite or Support Suite plan, or include both Zendesk Chat and Zendesk Support."

There is a second condition that is easy to skim past. Zendesk states: "Your account must be using Agent Workspace." Agent Workspace is a prerequisite, not a nice-to-have.

Agent Workspace Is a Project, Not a Toggle

If your account is still running the legacy agent interface, you have a dependency sitting in front of the migration you are actually planning. Agent Workspace changes how agents handle tickets — the unified interface, the conversation panel, how channels appear side by side. Switching it on changes the daily experience of every person on your support team simultaneously.

Teams routinely underestimate this because it presents as an account setting. In practice it needs its own communication plan, its own training, its own week or two of degraded handle times while people relearn muscle memory, and its own rollback conversation. Scheduling it in the same sprint as the channel migration means two disruptions landing on the same agents at the same time, and no clean way to tell which one caused the complaints.

Do Agent Workspace first, separately, and let it settle.

If You Are on a Legacy Chat-Only Plan

Accounts on Chat Team, Chat Professional, or Chat Enterprise — the standalone Chat plans that do not include Zendesk Support — are not covered by this announcement. They are not currently eligible for the migration to messaging.

Zendesk has confirmed that a separate removal announcement is coming for these customers. It has not published a date, a scope, or a migration path.

The practical advice for legacy Chat-only customers is uncomfortable but honest. You have less information than Suite customers and, in all likelihood, less time once your announcement lands. The direction of travel is unambiguous — Zendesk has said Chat is a legacy product it is no longer developing. Waiting for a date before starting the inventory work is a choice to compress your own timeline later.

Why Zendesk Is Retiring Chat

Zendesk's stated reasoning is unusually direct, and worth reading as written rather than through a vendor-relations filter. Zendesk says Chat "is a legacy product that hasn't received feature enhancements since 2020 and does not support modern AI features," and that the company is "accelerating its focus on AI-powered service and the Zendesk Resolution Platform."

Three things follow from that.

Chat has been frozen for six years. By the removal date in January 2028, Chat will have gone roughly eight years without feature work. If you have filed a Chat feature request since 2020 and wondered why it never moved, that is the answer. This was not a sudden decision — the decision was made years ago and is only now being formalised with a date.

The AI story is the whole story. Zendesk's product strategy is consolidating around the Resolution Platform. AI agents, automated resolution, and the surrounding tooling are built to operate on messaging's data model, where a conversation is a persistent, ticket-backed object with continuous history. A session-based chat that ends when the browser tab closes is a poor substrate for that. Chat is not being removed because it is old; it is being removed because it is architecturally incompatible with where the product is going.

This is a pattern, not an isolated event. Zendesk has been retiring and consolidating legacy surfaces steadily — see our coverage of the Bot Builder and Essential AI end of life. If you are running any Zendesk surface that has been quiet for a few years, the Chat announcement is a reasonable prompt to check its status too.

Read the 2020 date as the real announcement. August 2026 was just when they put a number on it.

What Zendesk Chat Actually Is — and Why Messaging Is Not the Same Product

This is the section most migration plans skip, and skipping it is why those plans slip.

Zendesk's own comparison of Chat and messaging is clear about the distinction. Live chat, it says, "offers real-time, session based and synchronous support for customers to receive 1:1 support from an agent on your website." Messaging, by contrast: "Messaging conversations can occur in real time and across channels when necessary but can be picked back up without losing context or history."

Read those two sentences next to each other and the migration problem becomes obvious.

Session-Based Versus Continuous

A Chat session is bounded. It starts when a visitor engages, it runs while both parties are present, and it ends. The artefact it leaves behind is a transcript — a record of a conversation that happened, attached to a visitor who may or may not be a known end user. The visitor concept itself is central to Chat: anonymous browsers, tracked across a site, engaged proactively based on behaviour.

A messaging conversation is unbounded. It is backed by a ticket. It persists across sessions, devices, and channels. The customer closes the tab, comes back three days later, and picks up where they left off with history intact. The central object is not a visitor and a session — it is an end user and a persistent conversation.

Why This Makes Parity Impossible in Principle

Here is the consequence that matters for your plan: some Chat concepts cannot be migrated to messaging because they do not exist in messaging's model, not because Zendesk has not got round to building the migration.

An anonymous visitor tracked across page views is a first-class Chat concept. Messaging is built around identified end users and persistent tickets. Proactive engagement based on real-time browsing behaviour assumes an always-on session and a live presence signal. A session-bounded transcript and a ticket-backed conversation thread are structurally different records with different lifecycles, different permissions, and different reporting semantics.

This is the difference between "not yet supported" and "not the same kind of thing." Zendesk says more settings will be added to the migration wizard over the transition period, and that is true and useful — but no amount of wizard development turns a session into a ticket retroactively. Some of your Chat configuration will be rebuilt by hand because there is nothing to map it onto.

If you take one thing from this guide into your planning meeting, take that. Budget for rebuild, not just transfer.

What Breaks on Removal Day

Concretely, here is what changes for a messaging-eligible customer on January 31, 2028.

The Customer-Facing Channel

The Chat widget stops being the thing serving your conversations. If you have not stood up and configured Web Widget for messaging by then, you do not have a live chat channel on your site. This is the part everyone plans for.

The Chat APIs

Zendesk states: "Chat APIs, Real-time APIs, and Incremental APIs are not supported in messaging."

This is the sentence that turns an admin project into an engineering project. Note the wording carefully — it does not say these are not yet migrated. It says they are not supported. Anything you built on them needs a different approach entirely, not a port.

In practice this catches:

• Custom chat widgets built against the Chat API rather than Zendesk's standard widget
• Real-time agent dashboards and wallboards pulling live queue and availability data
• Data warehouse pipelines using the Incremental API to sync chat records on a schedule
• Workforce management and scheduling tools consuming real-time chat state
• Internal tooling that nobody remembers commissioning, still running on a service account

That last one is not a joke. The Incremental API in particular tends to sit behind a nightly job that has run without incident for years, owned by someone who left. Grep your codebase, then check your outbound firewall logs, then ask your data team what feeds their support tables.

Mobile SDKs

Chat mobile SDK integrations appear on Zendesk's list of things that cannot be migrated automatically and must be configured manually. If you ship an iOS or Android app with in-app chat, this is an app release — which means it is also an app review cycle, a staged rollout, and a long tail of users on old versions who will not update. Work backwards from January 31, 2028 with your actual release cadence and you will find the real deadline is meaningfully earlier than the vendor's.

Third-Party Bots and Skills-Based Routing

Both are on the unmigrated list. On routing, Zendesk's wording is specific: messaging tickets "continue to route using your current chat routing rules after migration, but skills-based routing is not part of the standard messaging routing configuration."

If your routing depends on agent skills — language, product line, tier, certification — that logic needs rethinking rather than transferring.

Reporting

Reporting appears under the settings that cannot be migrated automatically. Zendesk's guidance is that "the Messaging dashboard in Explore can be customized to meet your reporting needs" — which is a statement about where to build the replacement, not a statement that your existing reports come across.

The operational consequence is a reporting discontinuity across the cutover. Chat metrics and messaging metrics are not measuring the same objects, so your historical trend lines will have a seam in them. Build the replacement dashboards while Chat is still live, run both in parallel, and document the differences before someone asks why first response time changed by forty percent overnight.

Our companion post, what the migration wizard doesn't move, itemises the coverage gaps in forensic detail and is explicit about which items Zendesk's public documentation simply does not address.

The Migration Wizard: What It Covers, at Summary Level

Zendesk provides a settings migration wizard that reviews your Chat configuration and recreates supported settings in Admin Center.

According to Zendesk's self-migration guide, the wizard automatically migrates triggers, operating hours, pre-chat and offline forms, satisfaction ratings, banned visitors, and goals and conversion tracking. On triggers specifically, Zendesk notes that "each Chat trigger is converted into one or more triggers that is compatible with messaging" and that "the new messaging trigger keeps the activation status of the original Chat trigger." Operating hours become schedules in Admin Center.

The same guide lists what the wizard does not handle: mobile SDKs, the Chat APIs, third-party bots, skills-based routing, and reporting.

Now hold two official Zendesk statements next to each other.

The announcement says: "The settings migration wizard ports your existing Chat features and settings over automatically."

The About page says: "Some Zendesk Chat settings aren't migrated automatically and must be reviewed and recreated manually."

Both are published by Zendesk. Both are current. The first is the headline; the second is the footnote. If your project plan was built off the first sentence, it is missing a workstream.

The Hidden Costs of an Eighteen-Month Runway

Long runways create their own failure mode. Here is where the budget actually goes.

Discovery Is the Expensive Part

The migration work you can see — triggers, forms, hours — is the cheap part, and it is largely wizard-assisted. The expensive part is finding the things nobody wrote down: the API integration behind a partner portal, the mobile SDK embed in a secondary app, the routing rule that exists because of a support model from three reorganisations ago.

Budget discovery as its own phase with its own owner. Teams that fold discovery into "the migration" end up discovering things during cutover.

The Wizard Is a Moving Target

Zendesk says it will be "adding more settings to the wizard" over the transition period. That is genuinely good news, and it is also a planning hazard. An assessment you run in late 2026 will not describe the wizard's behaviour in mid-2027. If you assess early — which you should — diarise a re-assessment closer to your actual cutover, and do not let a stale gap list drive a stale plan.

Agent Retraining

Messaging is a different workflow. Conversations persist, tickets sit in queues differently, and the reflexes agents built around session-bounded chats do not transfer cleanly. Expect a temporary hit to handle time and satisfaction after cutover, and staff for it rather than being surprised by it.

Reporting Continuity

Covered above, but worth pricing separately. Rebuilding dashboards is real analyst time, and running Chat and messaging reporting in parallel long enough to explain the seam is more analyst time again. We have written about this class of cost more broadly in the hidden costs of switching from Zendesk, and most of it applies to migrating within Zendesk too.

The Deadline Cluster

January 31, 2028 is not your only date. Zendesk has several overlapping changes in flight, and other vendors have their own. If you are tracking more than one, our software end-of-life calendar keeps the dates in one place.

Underestimating a migration usually means underestimating discovery, not underestimating the build.

Your Options at a Glance

You have three realistic paths. Each gets a full treatment in the migrate or switch decision guide; here is the shape of each.

Option 1: Migrate in Place to Zendesk Messaging

Best for: Teams whose Chat configuration is close to stock, who are already invested in the rest of the Zendesk Suite, and who value continuity over everything else.

This is the lowest-risk path. Ticket history stays where it is, the rest of the Suite is untouched, agents keep one tool, and the wizard does real work for you. The cost is that you inherit whatever messaging does not do that Chat did, and you accept the manual rebuild for everything on the unmigrated list.

Option 2: Move the Conversational Layer, Keep Zendesk Support

Best for: Teams where live chat is a major channel with sophisticated requirements — proactive engagement, deep routing logic, custom widget behaviour — and where messaging's model is a poor fit.

You keep Zendesk Support as the ticketing system of record and run the conversational layer on a dedicated vendor. The cost is a new integration boundary to own and two vendors instead of one.

Option 3: Leave the Suite

Best for: Teams who were already reconsidering Zendesk, and for whom the forced rebuild removes the main reason to stay.

The argument is simple. The switching cost that keeps most teams on an incumbent is the cost of rebuilding configuration. This migration makes you pay a large chunk of that cost regardless of where you land. If you were going to leave within two years anyway, doing it once is cheaper than doing it twice.

Be honest about the counterweight: leaving means moving ticket history, not just chat configuration, and that is a materially bigger job.

The Migration Checklist

Work through these in order. The sequencing matters more than the individual items.

1. Confirm your removal wave. Suite or Chat+Support means January 31, 2028. Legacy Chat-only means your date is unannounced. These are different projects.
2. Verify Agent Workspace, and if it is not enabled, schedule it as a separate project that completes before the channel migration starts.
3. Inventory everything. Every trigger and its activation state, operating hours, departments, shortcuts, routing rules, banned visitors, pre-chat and offline forms, widget customisation, tags, proactive campaigns, agent capacity settings.
4. Hunt down API and SDK usage across your codebase, your data pipelines, your mobile apps, and your third-party vendors. Chat APIs, Real-time APIs, and Incremental APIs are not supported in messaging, so every hit is rework rather than reconfiguration.
5. Run the wizard in a sandbox and diff its output against your inventory line by line. Record what it moved, what it did not, and what it moved differently than you expected.
6. Verify the unknowns against your own account. Public documentation does not address several common Chat objects. Your account is the source of truth for those, not a blog post — including ours.
7. Rebuild reporting in Explore while Chat is still running, and run both in parallel long enough to explain the seam.
8. Export historical transcripts and reporting data early, to storage you control, and verify the exports are complete and readable rather than assuming.
9. Make the platform decision explicitly before you start rebuilding, not after.
10. Rehearse the cutover on a low-volume segment or a single region first.
11. Set an internal deadline of October 2027, not January 2028. Holiday freezes, app release cycles and year-end change windows eat the last quarter.

One standing caveat applies to every item above: verify the wizard's coverage against your own account, not against any published list — including this one. Zendesk has said it is still adding settings to the migration wizard during the transition period, so any gap list is a snapshot with a shelf life. Re-run your assessment close to your actual cutover date.

When to Bring In Help

Be honest about which situation you are in, because the answer is genuinely different.

If your Chat setup is close to stock — a standard widget, a handful of triggers, operating hours, a pre-chat form, no API integrations, no mobile SDK — this is a DIY job. Run the wizard, work the manual list, rebuild your Explore dashboards, retrain the team. A capable Zendesk admin can own it end to end. You do not need a vendor for this, and anyone telling you otherwise is selling.

It stops being a DIY job at a few specific thresholds: custom integrations built on the Chat, Real-time or Incremental APIs; mobile SDK embeds shipping in a production app; skills-based routing carrying real operational load; multi-brand or multi-region configurations that have diverged over years; or a regulatory retention obligation covering historical transcripts.

The distinction that keeps projects honest is between who owns the runtime after migration and who preserves the data underneath it. The runtime — widget configuration, triggers, routing, agent workflow — is Zendesk administration, and your team or a Zendesk implementation partner is usually the right owner. The data layer is a different discipline: historical transcripts, conversation and ticket relationships, attachment handling, identity continuity between anonymous visitors and known end users, and the sequencing that lets you cut over without a gap in the record.

ClonePartner works on the data layer. Across 1,500+ migrations and 500+ integrations, the pattern we see most often is teams who scoped the configuration rebuild accurately and scoped the historical data at zero — then found out in month eight that the transcripts they assumed would follow them did not, and that the retention obligation was real.

We are typically brought in when historical conversations must stay searchable after cutover, when the migration crosses platforms rather than staying inside Zendesk, when identity has to be reconciled across systems, or when the business cannot tolerate a reporting gap across the cutover.