The Metric Continuity Map for switching help desk software

Old and new help desk dashboards rarely measure the same clock.

Your support metrics will move after a help desk switch, so define what each KPI measures and report on it before you diagnose a single post-cutover change.

Capture scope is where the trouble often starts. In a 2024 r/Zendesk thread, the owner of a small business with 2 full-time agents described handling about 400 tickets a month in the help desk and about 300 phone calls a month outside it. One commenter answered that the reporting "can't be working well if you aren't able to analyze your ticket history properly." Move that team to a platform that logs calls, and ticket volume jumps overnight. Demand did not change. The definition of a ticket did.

I call that definitional drift: a change in a reported metric caused by how the number is computed rather than by what customers experienced. After cutover, first-response time and CSAT are the usual victims, because the new platform defines business hours, reopens and survey triggers its own way. Recording six metric definitions on both platforms before go-live is what separates that drift from real performance change.

Timing matters more than most migration plans admit. Practitioners leaving legacy ticketing systems describe expecting old ticket history to vanish within a couple of months of go-live when nobody plans to carry it over. Once that history is gone, so is any chance of recomputing last quarter's baseline under the new rules.

What will matter most for help desk switches in the next 12 to 24 months?

Re-baselining will matter most: expect teams to treat ticket volume, survey scores and SLA attainment as restarting at cutover, because capture rules, survey methods and clocks change with the platform.

My forecast is narrower than the familiar advice to record a baseline and expect a dip. The leaders who come out ahead will stop asking whether the new tool performs better and start asking whether its numbers mean the same thing as the old ones. Records move. Rules do not.

Some outcomes would weaken this forecast. If migration services began carrying SLA policies, business-hours calendars, survey responses and full event history across platforms intact, post-cutover numbers would become comparable without a restatement. The same would follow if buyers wrote each metric's definition into the contract and held vendors to it at go-live. Neither is the norm in the material I reviewed. Migration onboarding still places a test migration before the paid full run, and that test checks records rather than the rules that score them.

I hold the volume prediction most loosely. A team that already logs every contact may see little movement at all. The survey prediction carries a different gap: no source here compares survey trigger defaults across vendors, so it rests on how scores are built rather than on measured drift, and the first publisher to document those defaults side by side will either confirm it or retire it.

What actually breaks in your metrics during a help desk migration?

Migration tools move ticket records, not the rules that compute your metrics, so SLA policies, business-hours clocks, timezone handling and survey context usually get rebuilt or lost at cutover.

Before you judge any post-cutover number, answer four questions in order:

1. Which SLA policies were rebuilt by hand in the new platform, and do their targets and calendars match the old ones?
2. Were timestamps normalized between UTC and the account's configured timezone during the transfer?
3. Where did historical CSAT responses land: as ticket fields, as tags, as separate survey objects, or nowhere at all?
4. Did the rule for what creates a ticket change, either by policy or because the new tool is faster or slower to log in?

Picture the first weekly report after go-live. SLA attainment has dropped, and leadership wants a reason by Friday. Before anyone blames the agents or the new tool, the useful question is narrower: which parts of the measurement system came across intact, and which were reconstructed by someone during a busy migration week?

Migration specialists are candid about the split. Zendesk stores timestamps in UTC, while some platforms store them in the account's configured timezone, and one migration services firm warns that if the migration layer does not normalize them, ticket ordering breaks and SLA calculations break with it. The same firm's migration matrix marks automations, triggers, macros and SLA policies as items that must be manually rebuilt in the target. It also lists historical survey response context and granular event history as commonly lost, because audit logs and ticket events are rarely available through export APIs.

Another vendor's migration guide draws the same line from the opposite direction. Subject lines, description bodies, statuses, priority levels, contact profiles and knowledge base articles transfer reliably between most platforms. Proprietary if-this-then-that automation rules from Zendesk or Freshworks typically do not, and have to be rebuilt. To be clear, those are the vendors' own descriptions of their services, not independent tests. They still agree on the pattern that matters here.

The common assumption is that a migration carries your reporting along with your tickets. It carries the nouns (tickets, contacts, articles) and leaves behind the verbs: the clocks, pauses, triggers and policies that turn raw timestamps into a first-response time or an SLA attainment rate. A review of 4 sources, two migration vendors and two practitioner threads, points the same way.

Practitioners describe what that looks like on the ground. In a 2025 r/sysadmin thread, one commenter whose organization moved from ConnectWise to FreshService said all open tickets were forwarded and the older tickets were lost; the CSV export they received "did not have the notes of the ticket, so it was pretty much useless." Another commenter in that 2025 thread said their organization, leaving a ticketing system that had been in place for 15 years, kept the old platform accessible in read-only mode for a year. Neither approach preserves the event history you would need to recompute an old metric under a new definition.

The new tool can also change what gets counted at all. In a 2024 r/sysadmin discussion about whether a service desk should record everything, one commenter described ticket-system waits of up to 5 minutes and said agents skipped logging quick fixes rather than sit through them. Logging friction is a property of the platform. Change the platform and you may change the denominator.

Zazachat's reviews are written and edited by our editorial team, led by Daniel Calloway, and I read these sources with that independence in mind: vendor descriptions show what a service claims to carry, while practitioner threads show what teams actually lost. If you are still choosing a destination, our ranking of help desk software with live chat lets you compare options before the migration questions start.

So when SLA attainment drops in week one, the first suspect is the business-hours calendar someone typed into the rebuilt SLA policy, not the agents working against it.

Which help desk metrics shift by definition rather than performance?

CSAT is the most exposed, followed by survey-measured first contact resolution and SLA attainment; raw first-response time is the sturdiest, provided the clock and calendar stay the same.

I put CSAT at the top because almost every part of it is a configuration choice. Maryna Paryvai's 2026 guide for Missive defines it on a 1-5 scale where 4s and 5s count as satisfied, divides satisfied ratings by total ratings, and tells teams to expect response rates of 5-20%. She also advises against surveying after every interaction, because "response rates crater, and the data becomes unreliable."

Other published definitions disagree on nearly every one of those points. A 2020 guide from an experience-management vendor recommended measuring CSAT after each interaction with a customer service agent. A call center benchmarking firm, writing in 2022, counted only the top box on a five-point scale where 1 meant very satisfied, and reported an industry average of 78% on that basis. Those are three different CSATs. Same customers, different numbers.

The trigger matters most after a switch. If the old platform surveyed every solved ticket and the new one surveys on close after a delay, or samples a fraction of conversations, the people who answer change before anything about service changes. With so few customers responding in the first place, a modest shift in who receives the survey can move the score on its own.

First contact resolution carries the same risk in a different form. That 2022 benchmark put average first call resolution at 70%, but it measured resolution with a post-call survey. A help desk that infers first contact resolution from ticket data (no repeat contact inside some window) is reporting a different metric under the same name, and a cutover is exactly when a team tends to swap one method for the other without noticing.

SLA attainment and resolution time sit in the middle. Both are computed from timestamps that do migrate, but against rules that do not. Whether a ticket stops its clock at solved or at closed, whether a reopen restarts the clock or extends the original one, and which states pause it are all settings. Change one and the average moves with no customer feeling the difference.

Raw first-response time is the sturdiest of the five. The same 2020 vendor guide defined it as the time of first response minus the time of the customer request, which leaves little room for interpretation. Its fragility sits at two edges: whether an automated acknowledgment counts as a response, and channel mix. That guide's 2020 benchmarks ran from 24 hours or less for email to 3 minutes for phone and instant for live chat, so adding chat at cutover can pull a blended average down while email performance stays exactly where it was.

Not every shift is drift. One AI help desk vendor's 2026 benchmark reported a median first response of about 5 minutes with or without automation, against a median resolution of 4.4 hours with automation and 71 hours without. If your switch also introduced automation, a falling resolution time may be a real process change, and the definitions are what let you prove it. Our rankings of AI customer support software are the place to compare tools when automation is part of the reason for moving.

Telling the two apart requires the definitions on paper for both platforms, captured while the old system can still answer questions.

How do you build a metric continuity map before cutover?

Write six definitions down on both platforms before cutover, verify each against migrated test tickets, and tag migrated history so reports never blend old and new rules.

A metric continuity map is a one-page record, kept per KPI, of how each platform computes the number: what starts the clock, what stops it, what pauses it and who gets surveyed. Built while both systems are still live, it turns a post-cutover argument into a lookup.

The sequencing advice from practitioners is old and still right. In a 2022 r/helpdesk thread, one commenter said the first step is to implement reporting on the KPIs you track, then review processes "to ensure they make sense and can be used," and only then diagnose problems. I would apply that order to the cutover itself. A definition nobody wrote down cannot be compared later.

With the six definitions recorded, work through four steps in order:

1. Capture the definitions while both systems answer queries. Screenshots of SLA policies, survey settings and business-hours calendars from the old platform are worth more than any later reconstruction. Build the matching groups, custom fields and policies in the new platform first, because one migration tool's walkthrough notes that groups, agents and custom fields must already exist in the target before they can be matched.
2. Hand-pick the test tickets. Help Desk Migration's getting-started documentation, as of 2024, described a default demo of 20 random tickets and a custom demo where you specify up to 20 record IDs, and it recommended choosing records that stress-test the transfer. I would choose them by definition: one per row of the table above.
3. Read the mapping report, not the success message. One migration vendor says every migration produces a record of what moved, what was transformed, what was skipped and every failed record with its reason. Check it for the fields your metrics depend on: status history, survey scores, timestamps and any custom reopen counter.
4. Tag migrated history. The same walkthrough lists an option to add a new tag to every migrated ticket. Use it, so dashboards can separate tickets computed under old rules from tickets created on the new platform.

The field-mapping rules deserve a slow read. The same documentation says required fields cannot be skipped, system fields are mapped automatically and cannot be changed, and choosing "Skip this field" leaves the target field empty for all migrated tickets. A skipped CSAT field is not a gap in some tickets. It is a blank across your entire history. A clean demo is not a clean migration either, since the documentation notes that skipped or failed counts in a demo do not necessarily reflect the full run.

Capture scope needs the same care. If live chat becomes a ticket source for the first time, record it as a change in the last row of the table rather than as new demand; our live chat software rankings are a reasonable starting point if that channel is still undecided.

Several migration vendors also offer a delta run to capture changes made during go-live, which means tickets touched in that window ran under two sets of rules and deserve a flag of their own.

What should you lock down before your next help desk switch?

Lock down six metric definitions while both platforms are still live, then judge post-cutover numbers against the restated baseline instead of the old dashboard.

A metric that moves after a switch is a question, not a verdict. Maryna Paryvai, in a Missive guide updated in April 2026, calls the NPS trend over time "the bigger signal" than the absolute score. Trends are exactly what a migration breaks. A trend only means something when the clock, the reopen rule and the survey trigger held steady from one end of it to the other.

Survey timing deserves special care. The same guide ties NPS timing to the type of business: web apps survey after onboarding and then quarterly, while e-commerce stores survey within a week of delivery. Your team chose that timing. A new platform's default trigger will not remember the choice.

I expect go-live to become a planned break in the series rather than a line drawn straight through it. Before you sign, export raw timestamps, survey responses and event history in an open format, then run a test migration on tickets you pick and compute FRT and CSAT under both rule sets. Where the two numbers disagree, you have found definitional drift, and that gap belongs in a footnote on every chart your executives see until the old baseline is retired.