Post-Migration QA: 20 Tests to Run After Your Help Desk Data Migration

So, you've completed your help desk migration. The heavy lifting is over, the data is in its new home, and you're ready to flip the switch. But how can you be certain everything works as it should? A neglected final step — a thorough post-migration Quality Assurance (QA) process — is one of the most common reasons migrations that technically completed still result in lost tickets, broken workflows, and unhappy customers.

Skipping the QA phase is one of the most disastrous Common Help Desk Data Migration Mistakes you can make. It's like building a new house and not checking if the plumbing or electricity works before moving in. The result? Leaks, outages, and a whole lot of frustrated residents.

At ClonePartner, we've run migrations across Zendesk, Freshdesk, Intercom, HubSpot, and dozens of other platforms. The QA failures we see repeatedly are not random — they follow predictable patterns. This checklist is built from those patterns.

Why Is Post-Migration QA So Important?

The primary intent behind any help desk migration is to improve efficiency, enhance customer experience, and scale support operations. However, without a robust QA plan, you risk the exact opposite. A QA plan shouldn't be an afterthought; it should be developed during the initial planning stage to define what a successful migration looks like.

Here's what's at stake:

• Data Integrity: Are all your tickets, contacts, and knowledge base articles where they should be, with all fields and attachments intact?
• Business Continuity: Do your automations, triggers, and integrations still work? Any broken workflow can bring your support to a screeching halt.
• User Adoption: If agents can't find what they need or the new system is buggy, they'll be frustrated and less productive.
• Customer Satisfaction: A flawed migration can lead to lost customer queries, delayed responses, and a damaged reputation.

A thorough QA process is one of the most important Best Practices for a successful migration. It's your final line of defense against the chaos that a botched migration can cause.

How to Read This Checklist

Each of the 20 tests below includes three components:

• What to check — the specific verification step
• What failure looks like — so you can identify problems quickly
• What to do when it fails — a remediation path, not just a detection signal

Tests are also rated by severity:

• 🔴 Critical — blocks go-live. Do not proceed until resolved.
• 🟠 High — must be resolved within 48 hours of go-live.
• 🟡 Medium — can be addressed post-launch without major risk.

Finally, sequencing matters. Tests in Category 1 (data integrity) must complete before Category 2 (system functionality) results are meaningful. A broken data relationship will cause false failures in workflow tests.

Sampling Methodology

Several tests below call for ticket sampling. Use these thresholds:

• Under 1,000 tickets: check 100%
• 1,000–10,000 tickets: check 10%, stratified by date range, status, and channel
• Over 10,000 tickets: use a minimum 500-ticket stratified sample, distributed across the same dimensions

Stratified sampling matters because migration failures are not random — they cluster around specific ticket types (e.g., tickets with attachments, tickets with custom field values, tickets from a specific date range). A random flat sample will miss these.

The Ultimate 20-Point Post-Migration QA Checklist

Download the Free Tracker: Before you start, grab our free Post-Migration QA Checklist Spreadsheet to assign tasks, track deadlines, and monitor your progress.

To make this manageable, we've broken down the 20 essential tests into four logical categories.

Category 1: Is Your Data Intact and Accurate?

This is the foundation of your QA process. Run all five of these tests before moving to Category 2. Results in later categories are only meaningful if data integrity is confirmed first.

1. Ticket Data Verification 🔴 Critical

   • What to check: Using the sampling methodology above, compare tickets between the old and new systems. Verify ticket IDs, subjects, descriptions, creation dates, status, priority, and custom fields.
   • What failure looks like: Custom field values are blank or mapped to the wrong field. Ticket statuses are uniform (e.g., everything shows as "open"). Creation dates are missing or shifted.
   • What to do when it fails: Do not go live. Identify whether the failure is systemic (a field mapping error affecting all tickets) or isolated. Systemic failures require re-running the migration with corrected field maps. Isolated failures can be patched via API or manual correction.
   • Platform note: Zendesk custom fields use numeric IDs that do not transfer directly. Freshdesk uses string-based field names. Verify field mapping tables before running this test.

2. Contact and Organization Data Audit 🔴 Critical

   • What to check: Ensure all user and organization records have been migrated. Check for correct names, email addresses, phone numbers, and any associated custom data. Verify that contacts are correctly linked to their respective organizations.
   • What failure looks like: Contacts exist but are not linked to organizations. Duplicate contact records appear (common when email addresses were not deduplicated pre-migration). Custom contact fields are empty.
   • What to do when it fails: For duplicate records, use the destination platform's merge tool before going live — bulk merging post-go-live is significantly more disruptive. For missing org links, check whether the source exported org associations in a separate file and whether those were included in the import.
   • Platform note: Intercom's "company" object maps differently than Zendesk's "organization." If migrating between these two, expect manual reconciliation for org-level custom attributes.

3. Attachment and File Integrity Check 🔴 Critical

   • What to check: Spot-check tickets from your stratified sample to confirm that all attachments (screenshots, logs, documents) are present, accessible, and not corrupted. Click through to open each file — do not just verify that a link exists.
   • What failure looks like: Attachment links are present but return 404 errors. Files open but are zero bytes or display as corrupted. Attachments are present on some tickets but missing on others with no clear pattern.
   • What to do when it fails: 404s on attachment links typically mean files were not transferred to the destination's storage, only metadata was. This requires re-running the file transfer component of the migration. Corruption indicates a transfer encoding issue. In both cases, do not go live — agents relying on ticket history will find it unusable.
   • Platform note: HubSpot stores attachments in its own CDN. Freshdesk and Zendesk use S3-compatible storage. Migrations that use CSV-based methods often drop attachments entirely because file content is not included in exports. Verify your migration method transferred binary files, not just URLs.

4. Knowledge Base Article Validation 🟠 High

   • What to check: Review your knowledge base to ensure all articles, categories, and sections are present. Test formatting, embedded images, and hyperlinks within the articles. Use a link crawler (Screaming Frog works well for this) to identify broken internal links at scale.
   • What failure looks like: Articles exist but embedded images are broken. Internal links point to the old platform's URLs. Article categories exist but articles within them are missing. Formatting is degraded (headers flattened to body text, code blocks lost).
   • What to do when it fails: Broken image URLs and internal links can often be batch-corrected with a find-and-replace on the exported content before re-importing. Missing articles require identifying the gap between source export and destination import counts by category.

5. Data Relationship Mapping 🔴 Critical

   • What to check: Verify that relationships between data entities are intact. Tickets should be associated with the correct contacts and agents. Ticket comments should be in correct chronological order. Child tickets should be linked to parent tickets.
   • What failure looks like: Tickets are present but assigned to no agent or a generic system user. Comments are present but in reverse order or missing intermediate replies. Parent-child ticket relationships are flattened into independent tickets.
   • What to do when it fails: Relationship failures are among the hardest to patch post-launch because they require cross-referencing two datasets simultaneously. If agent assignment is broken systemically, check whether agent email addresses were matched correctly between source and destination. Mismatched emails break the assignment lookup.

Category 2: Does Your New System Actually Work?

Run Category 1 tests first. If data integrity is confirmed, proceed here.

6. Ticket Creation and Channel Testing 🔴 Critical

   • What to check: Create test tickets through every channel (email, web portal, social media, API). Ensure they are created correctly in the new system and that all relevant fields are populated.
   • What failure looks like: Test email to the support address does not create a ticket. Web form submissions disappear. API-created tickets do not appear in the queue. Channel-specific fields (e.g., social handle, form source) are empty.
   • What to do when it fails: Channel failures are usually configuration issues, not data issues. Check that email routing (MX records or forwarding rules) has been updated to point to the new platform. Verify API credentials have been rotated for the new system.

7. Agent Roles and Permissions Validation 🔴 Critical

   • What to check: Log in with different agent profiles (admin, team lead, agent) to ensure permissions and access levels are correctly configured. Can agents only see and do what they're supposed to?
   • What failure looks like: Agents can access tickets from groups they are not members of. Admins cannot access system settings. Read-only users can edit ticket fields.
   • What to do when it fails: Permissions failures are a security risk. Suspend go-live, audit the role configuration, and correct before proceeding. Do not attempt to go live with incorrect permissions even if data looks correct.

8. Automation and Workflow Trigger Tests 🔴 Critical

   • What to check: Test all your business rules, triggers, and automations. Do tickets get routed to the correct group? Are SLAs applied correctly? Do automated email notifications get sent?
   • What failure looks like: Tickets sit in an unassigned queue instead of routing. SLA timers do not start. Trigger-based emails do not send. Automations fire on wrong conditions.
   • What to do when it fails: Check whether automations were recreated in the new system or only data was migrated. Most platforms do not export automation logic in a portable format. Refer to our guide on How to Migrate Automations for platform-specific approaches.
   • Platform note: Zendesk's trigger logic uses AND/OR condition trees that do not map directly to Freshdesk's automation rules. If migrating between these platforms, expect manual recreation of complex routing rules.

9. Integration Functionality Testing 🟠 High

   • What to check: Test all third-party integrations (CRM, bug trackers, communication tools like Slack). Does data flow correctly between the help desk and the integrated apps? Use Postman to test webhook delivery and confirm payloads match expected schemas.
   • What failure looks like: Tickets closed in the help desk do not update the linked CRM record. Slack notifications stop firing. Webhook deliveries return authentication errors (401) or payload format errors (400).
   • What to do when it fails: Most integration failures post-migration are authentication failures — API keys or OAuth tokens were issued for the old platform instance. Rotate credentials and update webhook endpoint URLs to the new system.

10. Search and Filtering Functionality 🟡 Medium

    • What to check: Test the search functionality for tickets, contacts, and knowledge base articles. Use a variety of keywords and filters to ensure the results are accurate and relevant.
    • What failure looks like: Search returns no results for known ticket subjects. Filters produce incorrect result counts. Full-text search works but field-specific filters do not.
    • What to do when it fails: Search index failures are common immediately post-migration because many platforms build their search index asynchronously. Wait 24 hours and retest before escalating. If still failing, check whether the platform requires a manual re-index trigger.

11. User and Agent History Verification 🟠 High

    • What to check: Ensure that agent and user profiles show the correct historical activity. This includes ticket assignments, comments, and any other actions taken in the system.
    • What failure looks like: Agent profiles show zero historical tickets. User profiles show activity but attributed to the wrong agent. Comment authors display as "System" or a generic migration user.
    • What to do when it fails: Attribution failures usually trace back to the agent email matching issue noted in Test 5. If source and destination agent accounts do not share the same email address, historical actions cannot be re-attributed automatically. For more details, see our blog on How to Migrate Users.

Category 3: Is the New System User-Friendly?

This category focuses on the human element. Complete Categories 1 and 2 before user testing — there is no value in testing usability against a broken or incomplete dataset.

12. Agent Interface Usability Test 🟡 Medium

    • What to check: Have a few agents perform their daily tasks in the new system. Can they easily find information, respond to tickets, and use the key features?
    • What failure looks like: Agents cannot locate the ticket queue. Macros or canned responses are missing. The new ticket view does not show fields agents rely on.
    • What to do when it fails: Separate usability friction from configuration gaps. Missing macros are a data migration issue (macros are often not exported by platform tools). Missing fields in the ticket view are a configuration issue.

13. Customer Portal Experience Review 🟠 High

    • What to check: Go through the customer portal from a customer's perspective. Is it easy to submit a ticket, track its status, and browse the knowledge base?
    • What failure looks like: The portal URL still points to the old system. Ticket submission form is missing required fields. Knowledge base categories are empty or show draft articles publicly.
    • What to do when it fails: DNS/URL issues are common when a custom portal domain was in use. Verify the CNAME record for the portal domain points to the new platform. Check knowledge base article visibility settings — some platforms default new articles to draft on import.

14. Email Notification and Template Check 🟠 High

    • What to check: Review all automated email notifications (e.g., "ticket received," "ticket updated"). Check for correct branding, formatting, and that all dynamic fields (like ticket ID and customer name) are populating correctly.
    • What failure looks like: Emails send but dynamic fields render as raw variable names (e.g., {{ticket.id}} instead of 12345). Emails are sent from the platform's default address instead of your custom domain. HTML formatting is broken.
    • What to do when it fails: Raw variable names indicate template syntax was copied from the old platform without adapting to the new platform's template engine. Each platform uses different variable formats. Check SPF/DKIM configuration if emails are sending from the wrong domain.

15. Mobile Responsiveness Testing 🟡 Medium

    • What to check: Access the customer portal and the agent interface on various mobile devices (phones and tablets) to ensure the layout is responsive and usable.
    • What failure looks like: Portal layout breaks on small screens. Agent interface is not accessible on mobile browsers.
    • What to do when it fails: Mobile rendering issues are typically a theme or CSS configuration problem, not a data issue. Check whether a custom theme was applied that overrides the platform's responsive defaults.

Category 4: Is the System Fast, Secure, and Insightful?

16. System Performance and Load Testing 🟠 High

    • What to check: Test response times for opening tickets, running searches, and generating reports under realistic load. Use k6 or Locust to simulate concurrent agent sessions if you have a large team.
    • What failure looks like: Ticket views take more than 3 seconds to load. Search times out under concurrent use. Report generation fails or takes more than 30 seconds.
    • What to do when it fails: Performance failures in SaaS help desks post-migration are often caused by an unusually large data volume triggering slow queries on the new platform. Contact the platform's support team with specific slow endpoints and ticket counts. Some platforms require manual index optimization for large accounts.

17. Security and Compliance Validation 🔴 Critical

    • What to check: Ensure that all security settings (e.g., password policies, two-factor authentication) are correctly configured. If you're in a regulated industry, verify that the new system meets all compliance requirements (GDPR, HIPAA, etc.).
    • What failure looks like: 2FA is disabled for all agents. SSO integration is not connected. Data residency settings do not match your compliance requirements (e.g., data is stored in US region when EU residency is required).
    • What to do when it fails: Do not go live. Security configuration failures are not patchable post-launch in a compliant way. Correct before any agents log in to the production environment.

18. Reporting and Analytics Accuracy 🟠 High

    • What to check: Generate key reports (e.g., first response time, resolution time, ticket volume by channel) in the new system and compare to historical reports from your old system. Focus on the period immediately before migration cutover.
    • What failure looks like: Ticket volume numbers do not match. Resolution time averages are significantly higher or lower than expected. Reports show data only from the migration date onward, not historical data.
    • What to do when it fails: Discrepancies in volume counts usually indicate tickets were missed during migration. Cross-reference total ticket counts between source and destination before investigating individual records. Metrics that differ from historical baselines may reflect differences in how the new platform calculates them — verify the metric definitions before assuming data loss.

19. API Endpoint Testing 🟠 High

    • What to check: If you use the help desk's API for any custom integrations or workflows, test the key endpoints using Postman to ensure they are responding correctly and returning expected data structures.
    • What failure looks like: Endpoints return 401 (authentication failure) or 404 (endpoint not found, which may indicate the new platform uses different API paths). Response payloads are missing fields your integration depends on.
    • What to do when it fails: 401 failures require credential rotation. 404 failures require checking the new platform's API documentation — endpoints and field names often differ between platforms. Budget time for integration code changes if migrating between platforms with different API architectures.

20. Backup and Restore Test 🔴 Critical

    • What to check: Before going live, perform a backup of the newly migrated data and, if possible, test the restore process in a sandbox environment. Follow the 3-2-1 backup strategy: three copies, two different media types, one offsite.
    • What failure looks like: Backup export completes but restore into sandbox produces errors. Backup file is missing attachment data. Restore takes longer than your acceptable recovery time window.
    • What to do when it fails: A failed restore test means your safety net does not work. Do not go live without a functioning backup and restore path. If the platform does not support self-service restore, confirm with the vendor what their recovery SLA is and whether it meets your requirements.

Rollback Criteria

Not every failure requires a rollback. But some do. Use this as a guide:

Roll back if:

• More than 1% of tickets in your stratified sample have data integrity failures (missing fields, wrong status, corrupted content)
• Attachment failures affect more than 5% of sampled tickets
• Any Critical-rated test cannot be resolved within your go-live window
• Security or compliance configuration cannot be confirmed before agents access the system

Do not roll back — patch instead — if:

• Failures are isolated to a specific ticket type, date range, or channel
• The failure affects Medium-rated tests only
• The fix can be applied via API or manual correction to fewer than 50 records

Rollback means restoring agents to the old system and treating the new system as a staging environment until failures are resolved. This requires that the old system remain accessible and writable during the QA window — which is why zero-downtime migration approaches run both systems in parallel.

What are the 20 steps I should keep in mind? Here's the list of 20. You can download the free QA spreadsheet here, which includes pre-built dropdowns, deadlines, and assignees for you to track internally.

The ClonePartner Approach: QA Built Into the Process

Going through this 20-point checklist can be a full-time job, and that's after you've already done the hard work of the migration itself.

ClonePartner's engineer-led migrations include a structured QA phase covering data integrity, relationship mapping, and workflow validation before you go live. We work across Zendesk, Freshdesk, Intercom, HubSpot, Salesforce Service Cloud, and others — which means we know where each platform's migration behavior diverges and where the failure modes cluster.

The QA process is the final step before going live, and it's the most critical. Don't leave it to chance.