---
title: "Zendesk Chat to Messaging: What the Wizard Doesn't Move"
slug: zendesk-chat-to-messaging-what-the-migration-wizard-doesnt-move
date: 2026-09-24
author: Abdul Aleem
categories: [Zendesk, Help Desk]
excerpt: "Zendesk says its wizard ports Chat settings automatically, and also that some must be recreated manually. Here's what each claim covers — and what neither does."
tldr: "Zendesk's wizard migrates six Chat setting types and explicitly skips five. A third group — transcripts, departments, widget config — is documented nowhere. Verify those against your own account."
canonical: https://clonepartner.com/blog/zendesk-chat-to-messaging-what-the-migration-wizard-doesnt-move
---

# Zendesk Chat to Messaging: What the Wizard Doesn't Move


Zendesk removes Chat for messaging-eligible customers on **January 31, 2028**. Between now and then, the settings migration wizard is the tool Zendesk gives you to move your configuration to messaging.

[Zendesk's announcement](https://support.zendesk.com/hc/en-us/articles/10934638765466-Announcing-the-removal-of-Zendesk-Chat-for-messaging-eligible-customers) describes it this way: "The settings migration wizard ports your existing Chat features and settings over automatically."

[A different Zendesk page](https://support.zendesk.com/hc/en-us/articles/10837219795226-About-the-removal-of-Zendesk-Chat-and-migration-to-messaging), about the same migration, says: "Some Zendesk Chat settings aren't migrated automatically and must be reviewed and recreated manually."

Both sentences are published by Zendesk. Both are current. Neither is wrong. The distance between them is your project plan, and this post exists to measure it precisely — including being explicit about the places where Zendesk has published nothing at all, which turn out to be the places that hurt.

## Three Buckets, Not Two

Most migration planning treats this as a binary: things the tool moves, things it does not. That framing is wrong here, and the wrongness is expensive.

There are three categories:

1. **Confirmed migrated.** Zendesk's self-migration guide names these explicitly.
2. **Confirmed not migrated.** Zendesk's self-migration guide names these too, under an unambiguous heading.
3. **Undocumented.** Common Chat objects that Zendesk's public migration documentation does not address in either direction.

The third bucket is the one that sinks projects, because human nature files unknowns under "probably fine." It is also the bucket where you will find historical transcripts.

| **Date** | **Event** |
| --- | --- |
| August 4, 2026 | Removal of Chat announced for messaging-eligible customers |
| August 2026 – January 2028 | Transition window; Zendesk states it will add more settings to the wizard over time |
| **January 31, 2028** | **Zendesk Chat removed — the wizard's coverage stops mattering, because Chat is gone** |
| July 28, 2028 | Chat dashboard access ends |

> [!CAUTION]
> **Hard cutoff:** Zendesk Chat is removed on **January 31, 2028** for messaging-eligible customers. Anything the wizard did not move, and that you did not rebuild by hand, is simply not there on February 1.

**Build your gap list with three columns. The two-column version is how teams discover a gap during cutover instead of during planning.**

## Bucket One: What Zendesk Confirms the Wizard Migrates

Zendesk's [self-migration guide](https://support.zendesk.com/hc/en-us/articles/9435865466906) is the only public page that itemises wizard coverage. It names six things as automatically migrated.

| **Chat setting** | **What Zendesk states happens** |
| --- | --- |
| **Triggers** | "Each Chat trigger is converted into one or more triggers that is compatible with messaging." The new trigger "keeps the activation status of the original Chat trigger." |
| **Operating hours** | "Zendesk converts your operating hours to schedules in Admin Center." |
| **Pre-chat and offline forms** | Listed as automatically migrated |
| **Satisfaction ratings (CSAT)** | Listed as automatically migrated |
| **Banned visitors** | Listed as automatically migrated |
| **Goals and conversion tracking** | Listed as automatically migrated |

Two details in that table are worth slowing down for.

### Triggers Are a One-to-Many Conversion

"Converted into one or more triggers" is not the same as "copied." A single Chat trigger can become several messaging triggers, because the conditions available in messaging do not map one-to-one onto Chat's conditions. Your trigger count will not match on the other side, and that is expected behaviour rather than a fault.

The practical consequence is that a count-based check — forty triggers before, forty after — is not a valid verification. You have to verify behaviour, not cardinality. Take your ten highest-traffic triggers, work out what each one is supposed to do, and test that outcome in messaging directly.

The activation-status detail is genuinely helpful, though, and it is the kind of thing that is easy to get wrong in a migration. Zendesk preserves whether a trigger was on or off. If you have deactivated triggers sitting in your account — old campaigns, seasonal logic, things someone switched off rather than deleted — they come across still switched off. That is the correct behaviour, and it also means your migration inherits your clutter. Cleaning up before you migrate is cheaper than cleaning up twice.

### Operating Hours Become a Different Object

Operating hours in Chat become schedules in Admin Center. This is a genuine object conversion, not a rename. Schedules in Admin Center are a shared, account-level concept used by business hours, SLAs and other automations. Chat operating hours were narrower.

If you already have schedules defined in Admin Center for other purposes, check what the migration produced rather than assuming it merged sensibly with what was there. Duplicated or near-duplicate schedules are easy to create and annoying to untangle later.

## Bucket Two: What Zendesk Confirms It Does Not Migrate

The same self-migration guide carries a heading that removes all ambiguity: "The following settings can't be migrated automatically and need to be configured manually in Admin Center if applicable."

Five items sit under it.

| **Item** | **Zendesk's stated position** | **What this actually means for you** |
| --- | --- | --- |
| **Mobile SDKs** | Listed as requiring manual configuration | An app release cycle, not an admin task |
| **Chat APIs** | "Chat APIs, Real-time APIs, and Incremental APIs are not supported in messaging." | Permanent removal, not a migration gap — rebuild, do not port |
| **Third-party bots** | Listed as requiring manual configuration | Re-integrate against messaging's model |
| **Skills-based routing** | "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." | Basic routing survives; skills logic does not come with it |
| **Reporting** | "The Messaging dashboard in Explore can be customized to meet your reporting needs." | Build replacements by hand; reports do not carry across |

### The APIs Are the Expensive One

Read the API wording again, because the phrasing carries more weight than the list position suggests. Zendesk does not say the Chat APIs are not yet migrated. It says they are **not supported in messaging**.

That is a different class of statement. Everything else on this list is work you do once in Admin Center. The APIs are a permanent architectural removal: whatever you built against them has no destination, and no future version of the wizard will change that. This is the item that converts a support-admin project into an engineering project with its own sprint planning.

What typically turns up when teams actually search:

- Custom-built chat widgets written against the Chat API instead of Zendesk's standard widget
- Real-time wallboards and supervisor dashboards showing live queue depth and agent availability
- Nightly warehouse sync jobs using the Incremental API to pull chat records into BI
- Workforce management tools consuming live chat state for adherence and forecasting
- One internal tool, undocumented, running on a service account belonging to someone who left

Search the codebase first, then your scheduled jobs, then your outbound traffic logs, then ask the data team what populates their support tables. The order matters because each step catches things the previous one missed.

### Skills-Based Routing: Read the Sentence Carefully

Zendesk's wording here rewards close reading. Routing does not vanish — messaging tickets "continue to route using your current chat routing rules after migration." What does not come along is the skills layer, which "is not part of the standard messaging routing configuration."

So if your routing is department-and-availability based, you are in better shape than the bare word "unmigrated" suggests. If your routing depends on agent skills — language, product line, support tier, certification — that logic needs redesigning against messaging's routing model rather than transferring.

We cover the general shape of rebuilding this class of logic in [how to migrate automations, macros and workflows](https://clonepartner.com/blog/blog/how-to-migrate-automations-macros-workflows).

### Reporting Is Listed as Unmigrated for a Reason

Note what Zendesk's reporting line actually is: a pointer to where you build the replacement. "The Messaging dashboard in Explore can be customized to meet your reporting needs" tells you the destination exists. It does not tell you your Chat reports arrive in it.

This produces a reporting discontinuity across the cutover that is worth naming explicitly with your stakeholders in advance. Chat metrics and messaging metrics are not counting the same objects — a session versus a ticket-backed conversation — so trend lines have a seam at the cutover date. Build the Explore dashboards while Chat is still running, run both in parallel, and write down where the definitions diverge. Doing this after someone notices a forty-percent swing in first response time is a much worse conversation.

## The Article That Looks Like the Answer and Is Not

There is a Zendesk support article that comes up constantly in this research and that many migration plans have quietly mistaken for a coverage list. It is titled [How migrating to messaging impacts Chat settings and capabilities](https://support.zendesk.com/hc/en-us/articles/4408834919834), and it is genuinely useful — but not for the question you are asking.

What it provides is a concept mapping. Where a Chat feature used to live, and what the equivalent is called in messaging:

| **Chat concept** | **Messaging equivalent** |
| --- | --- |
| Departments | Groups |
| Shortcuts | Macros |
| Banned visitors | Suspended users |
| Operating hours | Business hours |
| Routing skills | Skills-based routing |

That is a *where does this feature live now* map. It is not a claim that the wizard moves your data or your configuration into those destinations. The article contains no automatic-migration claims at all; it directs administrators to reconfigure things in their new locations.

The distinction is subtle enough that it is worth stating bluntly: **knowing that Departments correspond to Groups tells you nothing about whether your departments arrive in Groups.**

### The Routing Skills Case Proves the Point

Look at the last row of that table next to the self-migration guide's unmigrated list, and the two Zendesk pages appear to contradict each other. The mapping article says routing skills correspond to skills-based routing. The self-migration guide says skills-based routing "is not part of the standard messaging routing configuration."

Both statements are true, and reconciling them is exactly the skill this migration requires. Skills-based routing **exists** in messaging as a capability — that is what the mapping article tells you. Your Chat skills routing configuration is **not carried across** by the wizard, and it is not part of the standard messaging routing setup — that is what the self-migration guide tells you.

Feature existence and data migration are separate questions. Any time you find a mapping table during this project, ask which of the two it is answering.

## Bucket Three: The Honest Unknown List

Here is the part of this post that other coverage tends to fill in with confident guesses.

For the following common Chat objects, **no public Zendesk source states whether the settings migration wizard moves them.** Not that they do not migrate — that the published documentation does not say, in either direction.

| **Chat object** | **Documentation status** | **What to do** |
| --- | --- | --- |
| **Departments** | Not addressed by the wizard documentation. The mapping article notes Departments correspond to Groups, which is a feature-location statement only. | Test in sandbox |
| **Shortcuts** | Not addressed. Mapping article notes Shortcuts correspond to Macros. | Test in sandbox |
| **Widget appearance and customisation** | Not addressed | Test in sandbox; expect rebuild |
| **Proactive chat** | Not addressed | Test in sandbox |
| **Visitor tracking** | Not addressed | Test in sandbox |
| **Chat tags** | Not addressed | Test in sandbox |
| **Agent capacity settings** | Not addressed | Test in sandbox |
| **Historical chat transcripts** | Not addressed | Verify with Zendesk in writing |
| **Historical reporting data** | Not addressed | Verify with Zendesk in writing |

We are not going to invent a table that the sources do not support. An honest gap list with stated unknowns is more useful to you than a fabricated complete one, because you can act on an unknown — you cannot act on a confident answer that turns out to be wrong in month nine.

> [!WARNING]
> **Do not treat this table, or any published gap list, as a substitute for testing your own account.** Zendesk has stated it will be "adding more settings to the wizard" over the transition period, which means coverage is a moving target throughout 2027. Create a known test object for each undocumented item in a sandbox, run the migration, and look for it on the other side. An hour of empirical testing beats any third-party list — this one included.

### How to Test an Undocumented Item

The method is unglamorous and it works.

For each item in the unknown bucket, create something distinctive and findable in your Chat configuration — a department called `MIGRATION-TEST-DEPT`, a shortcut with an unmistakable body, a tag nobody else uses. Run the settings migration wizard in a sandbox. Then go looking for each marker on the messaging side, in the destination the mapping article points to.

Record three outcomes per item: did it arrive, did it arrive intact, and did it arrive in a usable state. Those are different questions. A department that arrives as a group with no members is technically migrated and operationally useless.

## Why Parity Is Impossible in Principle, Not Just Unimplemented

It would be easy to read everything above as a story about an incomplete tool that will eventually be finished. That reading is comforting and partly wrong.

Zendesk's own [comparison of Chat and messaging](https://support.zendesk.com/hc/en-us/articles/5126341788442-What-is-the-difference-between-Chat-and-messaging) explains why. Live chat "offers real-time, session based and synchronous support for customers to receive 1:1 support from an agent on your website." Messaging conversations, by contrast, "can occur in real time and across channels when necessary but can be picked back up without losing context or history."

These are different data models, and the difference is structural.

Chat's world is built on **sessions and visitors**. A session has a start, an end, and a transcript. A visitor may be anonymous, tracked across page views by behaviour rather than identity. The session is the unit of work and it is disposable by design.

Messaging's world is built on **end users and tickets**. A conversation is a persistent object backed by a ticket. It survives the browser closing, the device changing, and three days passing. The unit of work is durable by design and it is attached to an identified person.

### What Follows From That

Some Chat concepts have nowhere to land, regardless of how much wizard development happens:

**Anonymous visitors.** An untracked browser session is a first-class Chat object. Messaging is built around identified end users. There is no faithful destination for a visitor who never identified themselves, which has direct consequences for any proactive or behavioural targeting built on visitor state.

**Proactive engagement on live browsing behaviour.** This assumes an always-on presence signal and a live session to interrupt. Messaging's asynchronous model does not have the same notion of a visitor who is *currently here and idle on the pricing page*.

**Session-bounded transcripts.** A transcript is a record of a bounded interaction. A messaging conversation is an open thread on a ticket. Converting one into the other is not a format change — it is a claim about what kind of record it is, with different lifecycle, different permissions, and different reporting semantics on each side.

This is the difference between "not yet supported" and "not the same kind of thing." No amount of engineering makes a session retroactively into a ticket. Plan for rebuild on these objects, not transfer, and stop waiting for a wizard update that is not coming for them.

## Historical Transcripts and Reporting Continuity

This deserves its own section because it is the single most common thing teams assume and the single most common thing nobody verified.

Zendesk's public migration documentation does not address the fate of historical Chat transcripts. It also does not address historical reporting data. That silence is the honest answer available from public sources today.

What we can say concretely:

Chat dashboard access is retained until July 28, 2028, roughly six months after the January 31, 2028 removal. Zendesk describes this as retaining "full access to the Chat dashboard." What Zendesk does not publish is which dashboard functions remain useful once the underlying channel is gone, or whether that window constitutes a supported export path.

Designing a retention strategy around an undefined window is how compliance findings happen.

> [!NOTE]
> **Compliance and retention:** If you operate under a records-retention obligation covering customer conversations — financial services, healthcare, insurance, or any contractual commitment with a defined retention schedule — do not rely on public documentation, community posts, or this article for the disposition of historical Chat transcripts. Open a ticket with Zendesk, ask specifically what happens to historical transcripts and historical reporting data after January 31, 2028, and retain the written answer. Export your transcripts early to storage you control and verify the export is complete and readable, rather than assuming the July 28, 2028 dashboard window is a compliant archive. Your compliance team needs a document, not a recollection.

On reporting continuity, the practical guidance is simpler. Reporting is confirmed unmigrated. Build the Explore Messaging dashboards before cutover, run them alongside Chat reporting for long enough to establish the relationship between the two sets of numbers, and document the definitional differences in writing. Our guides on [exporting tickets from Zendesk](https://clonepartner.com/blog/blog/how-to-export-tickets-from-zendesk) and on [zero-downtime help desk migration](https://clonepartner.com/blog/blog/zero-downtime-help-desk-data-migration) cover the mechanics of getting data out cleanly and sequencing a cutover without a hole in the record.

## Building Your Own Gap List

Pulling the method together into something you can run.

1. **Snapshot your current Chat configuration in full.** Every trigger and its activation state, operating hours, departments, shortcuts, routing rules and skills, banned visitors, pre-chat and offline forms, widget customisation, tags, proactive campaigns, agent capacity.
2. **Sort every item into three buckets** using the tables above: confirmed migrated, confirmed not migrated, undocumented.
3. **Search exhaustively for Chat API, Real-time API and Incremental API usage.** Codebase, scheduled jobs, warehouse pipelines, mobile apps, third-party vendors, outbound traffic logs.
4. **Plant test markers** for every item in the undocumented bucket.
5. **Run the wizard in a sandbox** — never production first — and diff the result against the snapshot.
6. **Verify behaviour, not counts**, especially for triggers, where one-to-many conversion makes count comparison meaningless.
7. **Get transcript and retention answers in writing** from Zendesk if you have any obligation covering conversation records.
8. **Rebuild Explore reporting** while Chat is still live and run both in parallel.
9. **Re-run the whole assessment** within a few weeks of your real cutover date, because the wizard's coverage is explicitly still changing.

The [full Chat end-of-life guide](https://clonepartner.com/blog/blog/zendesk-chat-end-of-life-the-2028-migration-guide) covers the timeline, eligibility and operational context around this work, and the [migrate-or-switch decision guide](https://clonepartner.com/blog/blog/zendesk-chat-retires-2028-migrate-to-messaging-or-switch-platforms) covers what to do if the gap list convinces you to reconsider the platform entirely.

## When to Bring In Help

If your gap list comes back short — stock widget, a dozen triggers, operating hours, a pre-chat form, no API integrations, no mobile SDK, no skills routing — you do not need help. Run the wizard, rebuild the handful of manual items, stand up the Explore dashboards, and move on. A competent Zendesk admin owns this comfortably inside a normal quarter.

The threshold is crossed by specific things, not by company size: integrations built on the Chat, Real-time or Incremental APIs; a mobile SDK shipping in a production app; skills-based routing carrying real operational load; multi-brand or multi-region configuration that has diverged over years; or a retention obligation attached to historical transcripts.

Keep two questions separate, because bundling them is what makes these projects slip. **Who owns the runtime after migration** — widget configuration, triggers, routing, agent workflow — is Zendesk administration, and your own team or a Zendesk implementation partner is usually the right answer. **Who preserves the data underneath it** is a different discipline: historical transcripts, the relationships between conversations and tickets and end users, attachment handling, identity continuity between anonymous visitors and known customers, and cutover sequencing that leaves no hole in the record.

ClonePartner works on that second question. Across 1,500+ migrations and 500+ integrations, the failure pattern we see repeatedly is a team that scoped the configuration rebuild accurately and scoped historical data at zero — because the documentation was silent and silence read as "fine."

We are usually brought in when historical conversations must remain searchable after cutover, when identity has to be reconciled across systems, when the migration crosses platforms rather than staying inside Zendesk, or when a reporting gap across the cutover is not something the business can absorb.

> Worried about what the Zendesk Chat migration wizard leaves behind before January 31, 2028? We scope the data layer specifically — historical transcripts, identity continuity, and the objects nobody documented. Book a 30-minute call and we'll work through your gap list together.
>
> [Talk to us](https://cal.com/clonepartner/meet?duration=30&utm_source=blog&utm_medium=button&utm_campaign=demo_bookings&utm_content=cta_click&utm_term=demo_button_click)

## Frequently asked questions

### Does the Zendesk settings migration wizard move everything?

No. Zendesk's announcement says the wizard "ports your existing Chat features and settings over automatically," but a second Zendesk page says "some Zendesk Chat settings aren't migrated automatically and must be reviewed and recreated manually." The self-migration guide lists mobile SDKs, Chat APIs, third-party bots, skills-based routing and reporting as unmigrated.

### Which Chat settings does the wizard migrate automatically?

Zendesk's self-migration guide lists six — triggers, operating hours, pre-chat and offline forms, satisfaction ratings, banned visitors, and goals and conversion tracking. Each Chat trigger converts into one or more messaging-compatible triggers and keeps its activation status. Operating hours become schedules in Admin Center.

### Do chat transcripts migrate to messaging?

Zendesk's public migration documentation does not state what happens to historical Chat transcripts. That is a gap in the published record, not a confirmed answer in either direction. Verify the disposition of your own transcripts against your account and get it in writing before the January 31, 2028 removal, especially under a retention obligation.

### Does skills-based routing survive the migration to messaging?

Not through the wizard. Zendesk states that 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." Skills exist as a concept in messaging, but your Chat skills routing configuration is not carried across for you.

### Will the Chat API keep working after migration?

No, and this one is permanent rather than a migration gap. Zendesk states plainly that "Chat APIs, Real-time APIs, and Incremental APIs are not supported in messaging." Anything built on them — custom widgets, live wallboards, warehouse sync jobs — needs a different architecture, not a port.