Best Practices for a Successful Help Desk Data Migration

Migrating a help desk is a high-stakes infrastructure project. Get it right and your support team gains better tooling, cleaner data, and more efficient workflows. Get it wrong and you face data loss, broken automations, and weeks of remediation.

This guide covers the practices that actually determine success or failure — based on the patterns we see across migrations involving platforms like Zendesk, Freshdesk, Intercom, Help Scout, Salesforce Service Cloud, and Jira Service Management.

1. Audit Your Current System Before You Plan Anything Else

Planning without an audit is guessing. Before you set timelines or pick a destination platform, you need a precise inventory of what you're migrating.

What to inventory:

• Tickets: Total count, status distribution (open, pending, solved, closed), and date range
• Contacts and organizations: Deduplicated count, custom field usage, merge history
• Knowledge base articles: Count, folder/category structure, embedded media, internal-only vs. public
• Attachments and inline images: Total volume in GB — this directly affects migration duration and API usage
• Custom fields: Field names, types (text, dropdown, checkbox, date, regex), and which are required vs. optional
• Automations, macros, and triggers: These almost never migrate automatically. Document every rule, its conditions, and its actions.
• SLA policies and business hour schedules: Platform-specific logic that must be manually rebuilt
• CSAT/satisfaction scores: Whether they're stored as ticket fields, tags, or separate survey objects varies by platform
• Tags and labels: Naming conventions, tag counts per ticket, and whether they map to categories or custom fields in the target
• Third-party integrations: Anything connected via API, webhook, or native app (Slack, Shopify, Salesforce, etc.)

This audit is the foundation everything else rests on. Skip it and you'll discover data gaps mid-migration — the most expensive time to find them.

Data type migration reference

Data object	Typically migrates cleanly	Requires transformation	Commonly lost or degraded
Tickets (subject, body, status)	✅	—	—
Ticket comments / conversation threads	✅	Formatting may shift (HTML → markdown or vice versa)	—
Contacts / users	✅	Dedupe and field remapping often needed	Merge history
Organizations / companies	✅	Hierarchical structures may flatten	Parent-child relationships
Custom fields	—	Type mismatches (e.g., multi-select → text) require mapping	Fields with no equivalent type in target
Attachments	✅ (if within size limits)	URL-referenced attachments need re-hosting	Inline images in HTML bodies
Tags	✅	May need renaming if target has character/length limits	—
Knowledge base articles	—	Category structure, embedded macros, and internal links need rebuilding	Platform-specific macros (e.g., Zendesk dynamic content)
Automations / triggers / macros	❌	Must be manually rebuilt in target	—
SLA policies	❌	Must be manually rebuilt	—
CSAT scores	—	Storage format varies by platform	Historical survey response context
Audit logs / ticket events	—	Rarely available via export API	Granular event history

For a deeper dive into the audit and planning process, see our Step-by-Step Guide to Planning.

2. Decide What to Migrate — and What to Leave Behind

Not all data deserves to move. Migrating everything, including years of spam tickets, orphaned contacts, and broken automations, adds cost, complexity, and risk for zero operational value.

Common exclusion candidates:

• Tickets older than a defined threshold (e.g., 3+ years closed) that have no regulatory or contractual retention requirement
• Spam and junk tickets
• Test or sandbox data
• Contacts with no associated tickets or activity
• Deprecated custom fields no longer in use

What you must keep:

• Any data subject to regulatory retention (GDPR, HIPAA, SOC 2 audit trail requirements)
• Open and pending tickets
• Recent closed tickets within your SLA reporting window
• All knowledge base content that is currently published
• Contact and organization records tied to active accounts

The decision of what to migrate should be documented and approved by stakeholders before the project begins. Our Help Desk Data Migration Playbook covers this in detail.

3. Understand the Common Failure Modes

Migrations fail in predictable, classifiable ways. Knowing these patterns in advance lets you test for them specifically.

Timestamp and timezone corruption: Platforms store timestamps differently. Zendesk stores in UTC; some platforms store in the account's configured timezone. If the migration layer doesn't normalize timezones, ticket ordering in the target system will be wrong — conversations appear out of sequence, and SLA calculations break.

Character encoding errors: Tickets containing non-ASCII characters (accented names, CJK text, emoji) can corrupt during export if encoding isn't explicitly set to UTF-8 at every stage of the pipeline.

Attachment URL breakage: Some platforms store attachments as URLs pointing to their CDN. If those URLs expire or require authentication, the migrated tickets will contain dead links instead of files. Attachments must be downloaded and re-uploaded, not just URL-referenced.

Custom field type mismatches: A multi-select dropdown in the source may not have an equivalent field type in the target. The data either gets flattened to a comma-separated text string (losing structure) or gets dropped entirely.

Duplicate records: If a migration is interrupted and restarted without idempotency controls, you can end up with duplicate tickets, contacts, or organizations. De-duplication after the fact is painful and error-prone.

HTML and rich text degradation: Ticket bodies with HTML formatting may render differently or lose formatting when the target platform uses markdown or plain text. Inline images embedded as <img> tags with source-platform URLs are particularly fragile.

Automation and macro loss: Automations, triggers, macros, and workflow rules almost never transfer between platforms. They must be manually recreated. This is consistently underestimated in migration timelines — see our guide on migrating automations, macros, and workflows.

4. Back Up Everything — Then Test the Restore

A backup you haven't tested restoring is not a backup. It's a hope.

What a complete backup includes:

• Full ticket export (all statuses, all date ranges)
• All attachments and inline images — downloaded, not just URL-referenced
• Contacts, organizations, and their custom field data
• Knowledge base articles with media assets
• Automation and macro configurations (exported or documented)

How to verify your backup:

1. Export your data using your platform's bulk export or API
2. Restore a representative sample to a sandbox or test environment
3. Spot-check at least 20 tickets across different date ranges, statuses, and complexity levels (attachments, long threads, custom fields)
4. Verify attachment files open correctly — not just that the records exist
5. Confirm contact-to-ticket associations survived the round trip

Store backups in a secure, separate location from both source and target environments. If your platform only offers CSV export, verify that multi-line ticket bodies and special characters survived the export without truncation.

5. Choose a Cutover Strategy

There are three primary approaches to the actual switchover. Each has real tradeoffs.

Big bang cutover

All data is migrated at once, and all agents switch to the new platform simultaneously.

• Pro: Clean, single cutover point. No period of running two systems.
• Con: Highest risk. If something fails, everything is affected. Requires a maintenance window where support may be degraded.
• Best for: Smaller teams (under ~50 agents), lower ticket volumes, or teams with a natural low-traffic window (weekends, holidays).

Phased migration

Data is migrated in batches — often by team, department, or date range. Agents transition in waves.

• Pro: Lower blast radius per phase. Issues found in phase 1 can be fixed before phase 2.
• Con: Longer total timeline. Requires running two platforms simultaneously, which complicates routing and reporting.
• Best for: Large organizations, multi-brand or multi-department setups, or teams that can't afford any downtime.

Parallel run (delta sync)

Both old and new platforms operate simultaneously. New tickets are created in both (or synced), and agents work in the new platform while the old one stays live as a fallback.

• Pro: Lowest risk. Rollback is trivial — just keep using the old system.
• Con: Most complex to orchestrate. Requires a sync mechanism to keep both systems consistent. Highest cost.
• Best for: Enterprise or regulated environments where rollback must be guaranteed.

The right strategy depends on your ticket volume, team size, tolerance for downtime, and regulatory requirements. Our zero-downtime migration guide covers the operational details of each approach.

6. Test Relentlessly — With a Structured QA Plan

Testing is not "click around and see if it looks right." It's a structured verification process with specific pass/fail criteria.

Record-level verification:

• Compare total ticket count in source vs. target. An exact match is the minimum bar.
• Pull 20+ tickets across different complexity levels (simple one-reply tickets, long multi-participant threads, tickets with 5+ attachments, tickets with custom field values) and verify every field transferred correctly.
• Check timestamps: are they in the correct timezone? Do conversation replies appear in the correct chronological order?
• Verify that internal notes remained internal (not exposed to customers).

Workflow verification:

• Manually trigger every automation and macro that was rebuilt in the target platform.
• Test ticket routing rules with sample tickets.
• Verify SLA timers start correctly on new tickets.
• Confirm email notifications fire to the correct recipients.

Integration verification:

• Test every third-party integration (CRM sync, e-commerce platform, Slack notifications, etc.).
• Verify API-dependent tools (chatbots, reporting dashboards) are pointing to the new platform.

Agent acceptance testing:

• Have 3–5 experienced agents work real scenarios in the new system.
• Collect specific feedback: what's broken, what's confusing, what's missing.

Document pass/fail results for every test. Do not go live until all critical tests pass. Our Post-Migration QA Checklist provides a full 20-test framework.

7. Plan Your Rollback Procedure

No migration plan is complete without a documented rollback procedure. If go-live reveals critical issues — data corruption, broken integrations, or performance failures — you need a way back.

Key rollback considerations:

• Time window: Define how long after go-live a rollback is feasible. Once agents have been working in the new system for 48+ hours, new ticket data exists only there — rolling back means losing that work or running a reverse migration.
• DNS and routing: If you changed email routing or DNS records to point to the new platform, document exactly how to revert them.
• Communication plan: If you roll back, customers and agents need to know immediately. Pre-draft the rollback communication.
• Data created post-cutover: Any tickets, contacts, or KB articles created in the new system after cutover will not exist in the old system. Decide in advance whether you'll accept that data loss or attempt a reverse sync.

A rollback plan you've never rehearsed is almost as risky as having no plan at all. Walk through the steps at least once before go-live.

8. Handle Regulatory and Compliance Requirements

Help desk data often contains personally identifiable information (PII): customer names, emails, phone numbers, and sometimes payment or health information embedded in ticket bodies.

GDPR considerations:

• If migrating data involving EU residents, ensure both source and target platforms are compliant with GDPR data processing requirements.
• Verify that your migration tool or partner does not store data in transit beyond what's needed for the migration.
• If your migration partner operates outside the EU, confirm appropriate data transfer mechanisms (Standard Contractual Clauses, adequacy decisions) are in place.
• Respect existing deletion requests: data that was deleted under a GDPR request in the source must not be resurrected in the target.

Data residency:

• Some platforms allow you to choose your data center region. If your organization requires data to stay within a specific geography, confirm the target platform supports this.
• During migration, understand where data transits. A migration tool that routes data through US servers may violate EU data residency requirements even if both source and target are EU-hosted.

Audit trail preservation:

• For organizations under SOC 2, HIPAA, or other compliance frameworks, the migration itself becomes an auditable event. Document what was migrated, when, by whom, and what was excluded.

Our GDPR-compliant data migration guide and HIPAA compliance guide cover these requirements in depth.

9. Communicate With Stakeholders Throughout

A migration affects agents, managers, other departments, and customers. Keeping them informed reduces friction and surfaces problems earlier.

Internal communication:

• Brief support agents early. They're the primary users — their feedback on the target platform's workflow during testing is invaluable.
• Notify any department that touches the help desk: sales teams that escalate tickets, engineering teams with integration dependencies, finance teams that rely on reporting data.
• Share the migration timeline and cutover plan. Make the go/no-go criteria explicit so the decision to launch isn't subjective.

Customer communication:

• Send a brief, honest notification before cutover. Let customers know you're upgrading your support system.
• If there will be a maintenance window with degraded response times, say so and give the expected duration.
• After go-live, monitor customer-facing channels closely for 48–72 hours.

10. Know When to Bring In a Specialist

Help desk migrations are deceptively complex. The data mapping, API integrations, edge case handling, and testing effort scales non-linearly with ticket volume and platform complexity.

Signals that you need external help:

• Your source platform has limited or undocumented export APIs
• You're migrating more than 100K tickets or have complex custom field schemas
• You need zero-downtime cutover with delta sync
• You have regulatory requirements (GDPR, HIPAA, SOC 2) that constrain how data can be handled in transit
• Your internal team doesn't have migration-specific experience (general IT or dev skills are not the same thing)

At ClonePartner, migrations are all we do — not a side project bolted onto an implementation engagement. If you want to understand how we approach this work, see how we run migrations.