Migrating your helpdesk platform is disruptive enough on its own. Migrating your QA workflow at the same time risks something far harder to recover: the historical scoring record that compliance teams depend on, the trend lines your CX leaders rely on, and the audit trail that proves your agents were held to a consistent standard. Done correctly, a helpdesk migration does not erase that record. It preserves it, validates it against the new environment, and sets a cleaner baseline going forward. This article provides a practical, step-by-step guide for QA and Support Operations teams navigating exactly that challenge.
- Export and archive historical QA scores, scorecards, and reasoning traces before any migration begins.
- Map your existing QA scorecard fields to the new platform's schema before cutover, not after.
- Run parallel scoring for a defined overlap period so pre- and post-migration data is directly comparable.
- Audit continuity depends on preserving not just scores, but the QA scorecard version and the policy documents that produced them.
- Post-migration QA validation (testing scoring consistency, data integrity, and agent records) is a distinct workstream from the helpdesk migration itself.
About the Author: Revelir AI builds AI customer service QA software for high-volume customer service teams. Its scoring engine, RevelirQA, runs in production at enterprises including Xendit and Tiket.com, evaluating thousands of conversations per week and generating a full audit trace on every score.
Why Is Helpdesk QA Migration Different From a Standard Platform Switch?
Most migration guides focus on ticket data: open cases, customer records, macros, and agent configurations [1]. QA migration is harder because the asset you are protecting is not a record of what happened, but a record of how quality was judged, and by which standard, at a specific point in time.
Three things make QA data uniquely fragile during a platform switch:
- QA scorecard versioning. A score of 4/5 from eight months ago only means something if you know which version of the scorecard produced it. If scorecard versions are not archived alongside scores, the historical data becomes uninterpretable.
- Policy linkage. If your QA scoring was tied to specific SOP documents, a score without its source policy is an orphaned data point. Regulated industries cannot use it for compliance evidence.
- Agent continuity. Agent IDs often change during a helpdesk migration [2]. If the new platform assigns new identifiers, historical performance data can become disconnected from the individuals it describes.
"A QA score without its QA scorecard version and source policy is not an audit trail. It is a number with no context."
What Should You Export and Archive Before Cutover?
Building on the three fragility points above, the pre-migration export checklist needs to go beyond ticket records. Before you touch the new platform, lock down the following from your current environment [5]:
| Asset | What to Capture | Why It Matters |
|---|---|---|
| QA scores | Score value, date, ticket ID, agent ID, reviewer ID | Core performance record |
| Scorecard versions | Full QA scorecard snapshot at the date of each scoring period | Prevents misinterpretation of historical scores |
| Policy documents | SOP versions linked to each scoring period | Required for compliance audits in regulated industries |
| Agent ID mapping | Old platform ID to new platform ID crosswalk | Preserves individual performance continuity |
| Reasoning traces | If AI-scored: prompt, retrieved documents, model, reasoning | Auditable evidence for each AI evaluation |
| Dispute and calibration records | QA disputes raised and resolved, calibration session outcomes | Shows governance process was followed |
Store all of this in a format that is independent of both platforms: structured CSV or JSON exports stored in a controlled archive, with a clear version label and export timestamp [6].
How Do You Map Your QA Scorecard to the New Platform?
Schema mapping is where most QA migrations quietly fail. Teams assume their existing scorecard will translate cleanly, discover mid-migration that the new platform uses different field types or scoring scales, and patch it under pressure during cutover. That patching introduces inconsistency that corrupts trend analysis for months afterward.
The right approach is to complete the scorecard mapping exercise as a pre-migration deliverable, before any data moves [2]. The steps:
- Document every QA criterion in your current scorecard: the label, the type (binary, multi-option, or weighted score), and the scoring scale.
- Map each criterion to its equivalent in the new platform's field types. Flag any that do not map cleanly.
- Resolve gaps before cutover. If the new platform cannot replicate a criterion natively, decide whether to configure a custom field, accept the difference, or retire the criterion with documentation.
- Freeze the new scorecard version and label it clearly as "Version X, effective [migration date]." This becomes the baseline for all post-migration scoring.
If your QA scoring is powered by an AI engine that retrieves your own SOPs before evaluating each conversation (as RevelirQA does via RAG), the mapping exercise also includes re-ingesting your policy documents into the new environment and confirming that retrieval accuracy is equivalent before go-live.
What Does a Safe Cutover Plan Look Like for QA Teams?
A related but distinct question from scorecard mapping is the cutover itself. The safest approach is a parallel-run period rather than a hard cutover [3]. During parallel running, both platforms are active and a subset of conversations is scored on both, allowing QA leads to compare outputs directly.
A practical parallel-run structure:
- Duration: Typically two to four weeks, depending on conversation volume. High-volume operations can validate statistical equivalence faster.
- Sample selection: Score the same ticket set on both platforms. If you are using AI scoring at 100% coverage, this is straightforward. If you use manual QA, randomly select a shared sample of at least 200 tickets.
- Comparison criteria: Score distributions, flag rates, per-agent averages. A significant divergence on any metric signals a configuration problem to resolve before full cutover [4].
- Sign-off gate: QA lead and Support Operations manager both sign off that parallel outputs are consistent before decommissioning the old platform.
How Do You Maintain Audit Continuity After Migration?
Stepping back from the technical detail, a separate concern is the ongoing audit trail after the migration is complete. Continuity means a compliance reviewer can trace any score, at any point in time, back to the QA scorecard, the policy, and the evaluator that produced it, regardless of which platform was active at the time.
Three practices sustain that continuity:
- Label the migration boundary explicitly in your QA records. Any reporting tool should be able to filter "pre-migration" and "post-migration" periods separately, because they were scored under different platform conditions.
- Preserve reasoning traces for AI-generated scores. In AI-powered QA, every score should carry a trace of the prompt used, the documents retrieved, and the model's reasoning. This is the QA equivalent of showing your work. RevelirQA generates this trace on every evaluation, which is particularly important for fintech clients like Xendit where scoring decisions may be subject to regulatory review.
- Archive, do not delete, old platform data. Even after decommissioning, historical QA records from the previous platform should be retained in their original export format for a defined retention period aligned with your compliance obligations.
What Are the Most Common QA Migration Mistakes?
- Migrating ticket data without migrating the scorecard versions that produced historical scores.
- Assuming agent IDs will carry over automatically, then discovering performance history is disconnected post-migration [2].
- Skipping the parallel-run period to hit a faster launch date, then being unable to explain post-migration score shifts.
- Treating QA migration as a sub-task of the helpdesk migration rather than a parallel workstream with its own owner [5].
- Not re-validating AI scoring accuracy in the new environment after policy documents are re-ingested.
Frequently Asked Questions
The helpdesk migration itself can range from a few weeks to several months depending on data volume and platform complexity [3]. The QA-specific workstream (scorecard mapping, parallel run, and post-migration validation) adds two to six weeks on top of that, and should run concurrently rather than sequentially.
It depends on the new platform's data model. Many platforms accept bulk imports of historical records if the schema is mapped correctly. Even when import is not possible, archiving scores externally with their associated QA scorecard versions preserves audit continuity [4].
Scoring should continue without interruption on the current platform until formal cutover. If you use AI scoring, ensure the scoring engine remains connected to the live helpdesk data stream throughout. Do not pause QA coverage during migration.
By maintaining a time-stamped archive of scores, QA scorecard versions, and policy documents from both periods, with a clearly labeled migration boundary date. Any auditor can then reconstruct the standard that applied at any given point.
Yes, if the AI QA engine pulls conversation data via API, the integration must be reconfigured for the new platform and validated before go-live. Additionally, if the scoring engine uses RAG to retrieve your SOPs, the policy documents need to be re-ingested and retrieval accuracy confirmed in the new environment.
Export and archive your QA scorecard versions alongside your historical scores. The scores alone, without the QA scorecard that produced them, cannot support trend analysis or audit review [1].
Run a parallel scoring period where the same conversation set is evaluated on both platforms. Compare score distributions and flag rates. Resolve any statistically significant divergence before decommissioning the old platform [4].
Revelir AI builds RevelirQA, an AI quality assurance engine for customer service teams. RevelirQA scores 100% of support conversations against each client's own policies and QA scorecard, generating a full reasoning trace on every evaluation so QA leads and compliance teams have an auditable record behind every score. The platform evaluates both human agents and AI chatbots on the same QA scorecard, giving CX leaders a unified view of quality across their entire support operation. RevelirQA is in production at Xendit and Tiket.com, scoring thousands of conversations per week across multilingual, high-volume environments.
If you are planning a helpdesk migration and need QA scoring that preserves audit continuity, handles 100% of conversations, and generates a full reasoning trace on every evaluation, Revelir AI is built for exactly that environment.
References
- Help Desk Migration: A Step-by-Step Guide for Support Teams (supportbee.com)
- How do you run a successful help desk migration project (timeline, roles, and cutover plan)? (www.supportbench.com)
- Help Desk Migration Made Easy: A Complete Guide | Freshdesk (www.freshworks.com)
- Post-Migration QA: 20 Tests to Run After Your Helpdesk Migration | ClonePartner Blog (clonepartner.com)
- Help Desk Migration Guide 2026: Steps, Costs, Tools & ... (hiverhq.com)
- How it works | Help Desk Migration Service (help-desk-migration.com)