Zendesk Explore Dashboard Migration Checklist

Zendesk’s legacy dashboard builder becomes view-only on December 31, 2026. If your team still relies on legacy custom dashboards for backlog, first reply time, or resolution time reporting, you need a migration plan — not just a deadline reminder.

This guide walks through the migration step by step: what to audit, what to migrate, what to rebuild, and how to keep your support reporting running during the transition.

Why the migration matters

Legacy Explore dashboards will become view-only after December 31, 2026. That means:

You can still see old dashboards, but you cannot edit them.
Scheduled email deliveries tied to legacy dashboards may break.
Any dashboard sharing configurations need to be recreated on migrated versions.
Prebuilt legacy dashboards were already retired in February 2026.

If your team runs a weekly support ops review from Explore dashboards, migration is not optional — it is a prerequisite for keeping your reporting cadence alive.

Before you start: audit your dashboards

Most teams have more dashboards than they use. Before migrating everything, audit what you actually need.

Step 1: List all legacy dashboards

Open Explore, go to the Dashboard Library, and note every dashboard that shows a migration status (Migrate or Migrate (limited)). Record:

Dashboard name
Last updated date
Number of views (the Views column in the library)
Whether it has scheduled deliveries or sharing configured

Step 2: Decide what to keep

Zendesk’s own data shows most dashboards are never edited after 10 days. Apply a simple filter:

Active and used — Viewed in the last 90 days, updated in the last 6 months. Migrate these.
Referenced but stale — Not updated recently, but still viewed. Review whether they duplicate a newer dashboard.
Abandoned — No views, no updates. Archive or delete. Do not spend time migrating dashboards nobody uses.

Step 3: Document metric definitions

Before migrating, write down the metric definitions each dashboard uses:

First reply time — business hours or calendar hours?
Resolution time — first resolution or full resolution?
Backlog — which statuses count as open?
SLA compliance — which policies are included?

This prevents the migration from quietly changing how your team reads numbers. For definitions, see the glossary.

Migration step by step

Step 4: Migrate dashboards with no issues first

In the Dashboard Library, dashboards marked Migrate (no qualifier) can be moved with a few clicks:

Click Migrate next to the dashboard name.
Explore creates a copy in the new builder.
Open the new version and verify the layout and reports match what you expect.

The legacy version is not deleted automatically — keep it as a reference until you are confident in the new version.

Step 5: Handle “Migrate (limited)” dashboards

Dashboards marked Migrate (limited) have features that work differently or are not yet available in the new builder. Common issues:

Global or cascading filters — The new builder may not support the same filter behavior. You may need to restructure the dashboard or use dashboard restrictions instead.
Custom widget layouts — Some layout arrangements may shift during migration. Check visual alignment.
External data connections — If you have custom datasets or integrations, verify they connect properly.

For each limited dashboard, review the blocking issues Explore shows before migrating. Decide whether to migrate now and adjust, or wait for feature parity.

This is the step most teams forget. Migrated dashboards do not automatically carry over:

Sharing settings — Re-add viewers, editors, and groups.
Scheduled email deliveries — Recreate these on the new dashboard version. If your team receives a Monday morning email with the week’s support metrics, this needs to be re-configured.

Prebuilt dashboards had their sharing and schedules auto-migrated in February 2026. Custom dashboards require manual recreation.

Step 7: Verify and compare

For each migrated dashboard:

Open the legacy and new versions side by side.
Check that the same metrics appear with the same values for the same date range.
Confirm breakdowns (by group, tag, channel, priority) match.
Spot-check 2–3 drill-downs to ensure you can still reach ticket-level data.

If numbers differ, the most common causes are:

Different date range defaults in the new builder.
Filter settings that did not carry over.
Metric aggregation differences (mean vs median, calendar vs business hours).

Step 8: Switch your team to the new dashboards

Once verified:

Update bookmarks and links in Slack, email, or your ops review doc.
Send a brief note to the team: “We migrated to new Explore dashboards. Same metrics, same cadence, new links.”
Delete or archive the legacy versions to avoid confusion.

Common mistakes during migration

Migrating everything — You spend hours on dashboards nobody views. Audit first.
Forgetting scheduled deliveries — The Monday morning email stops arriving and nobody notices for two weeks. Recreate schedules immediately after migration.
Not verifying numbers — A subtle filter difference means your first reply time now includes weekends. Always compare old and new side by side.
Waiting until December — The deadline is December 31, but support teams go on holiday in December. Finish migration by November at the latest.
Losing metric consistency — If the new builder defaults differ from your legacy settings (e.g., calendar hours instead of business hours), your weekly review numbers will look wrong. Document definitions before and after.

What if Explore is too heavy after migration?

The migration is a natural moment to ask: is Explore the right tool for our reporting?

If your team spends more time building and maintaining dashboards than acting on the numbers, the issue is not the builder version — it is the approach. Many small teams find that a purpose-built Zendesk analytics dashboard gives them the core KPIs (backlog, first reply, resolution, reopen rate) without the maintenance overhead.

For a comparison of approaches, see the Zendesk Explore alternative page and the Zendesk reporting tool guide.

Migration timeline (recommended)

When	Action
Now – June 2026	Audit dashboards: list, categorize, document metric definitions
July – September 2026	Migrate active dashboards, verify numbers, recreate sharing and schedules
October 2026	Switch team to new dashboards, update links and bookmarks
November 2026	Final check: delete legacy versions, confirm all deliveries work
December 31, 2026	Deadline: legacy dashboards become view-only

FAQ

Will I lose data when I migrate? No. Migration creates a copy of your dashboard in the new builder. Your Zendesk data is not affected. The legacy version stays until you delete it.

What if a feature I need is not in the new builder yet? Zendesk has been adding features through 2025–2026 (including dashboard restrictions and improved filters). Check the Zendesk Explore release notes for the latest. If a critical feature is missing, plan to migrate the rest and handle that dashboard last.

How long does migration take for a typical team? For a team with 5–10 active dashboards, expect 2–4 hours of work: auditing, migrating, verifying, and recreating shares. The actual click-to-migrate step is fast; the verification and share recreation take the most time.

Can I use this as an opportunity to simplify our reporting? Yes — and you should. Most teams have more dashboards than they need. Use the audit step to consolidate into one support metrics dashboard with the core KPIs, rather than migrating a sprawl of reports.

See your Zendesk metrics without the migration hassle — start free