Common Help Desk Data Migration Mistakes and How to Avoid Them 

Help desk migrations fail in predictable ways. After handling over 1,200 migrations across platforms like Zendesk, Freshdesk, Intercom, and Jira Service Management, we've cataloged the failure patterns that repeat. This guide covers the nine most common mistakes, organized by the migration phase where they occur, and explains the technical mechanics behind each one.

Migration Phase Model

Before diving into mistakes, it helps to understand the five phases of a help desk migration. Each mistake below is tagged to the phase where it causes the most damage.

Phase	What Happens	Typical Duration
Pre-Migration	Planning, data audit, field mapping, backup, compliance review	1–3 weeks
Trial Run	Migrate a subset of data to validate mapping and identify issues	2–5 days
Delta Migration	Migrate tickets and data created after the trial run cutoff	Hours to 1 day
Cutover	Final switch to the new system, disable old system, re-enable notifications	Hours
Post-Migration Validation	QA testing, data integrity checks, team verification	2–5 days

Every mistake below maps to one or more of these phases. Skipping a phase is itself a mistake — and it's usually the root cause of the others.

Mistake #1: No Migration Plan — Phase: Pre-Migration

The most common failure mode is starting without a documented plan. Without one, scope creep, missed deadlines, and budget overruns become inevitable.

Why It Fails

Without a plan, teams discover dependencies mid-migration that force restarts. Common consequences:

• Scope creep: The project expands to include data objects (e.g., knowledge base articles, satisfaction ratings) that were never scoped, adding weeks.
• Missed deadlines: Go-live dates slip because nobody estimated the time required for field mapping or QA.
• Budget overruns: Custom scripting, overtime, and vendor fees accumulate when the scope wasn't defined upfront.
• Unrecoverable data loss: Without defined rollback criteria, teams discover missing data too late to recover it.

How to Avoid It

Before moving any data, document answers to these questions:

• What data objects are in scope? (Tickets, contacts, organizations, knowledge base articles, attachments, satisfaction ratings — be explicit.)
• Who owns each phase? (Assign named individuals, not departments.)
• What is the realistic timeline? (Add a 20% buffer for unexpected issues.)
• What are the rollback criteria? (Define the conditions under which you abort and restore from backup — e.g., more than 2% of tickets fail validation, or any attachment loss is detected.)

For a detailed planning framework, see our A Step-by-Step Guide to Planning Your Help Desk Data Migration.

Mistake #2: No Pre-Migration Backup — Phase: Pre-Migration

Skipping the backup before migration removes your only recovery path. If the migration corrupts data or the mapping is wrong, there is no undo.

Why It Fails

Without a backup:

• Compliance violations: Regulations like HIPAA (which requires covered entities to maintain data integrity and availability under the Security Rule, 45 CFR §164.312) and GDPR (which requires data controllers to ensure data integrity under Article 5(1)(f)) impose penalties for data loss. A migration without a backup puts you in violation if data is destroyed.
• Customer trust destruction: Lost ticket history means agents cannot reference prior interactions, and customers must re-explain issues.

How to Avoid It

Perform a full export of your source helpdesk before starting. Then validate the backup:

1. Export all data objects (tickets, users, organizations, articles, attachments).
2. Verify record counts match the source system's reported totals.
3. Restore a sample subset (e.g., 100 tickets with attachments) to confirm the backup is not corrupted.
4. Store the backup in a separate, access-controlled location — not on the same system you're migrating from.

Mistake #3: Underestimating Time and Cost — Phase: Pre-Migration

Migrations consistently take longer and cost more than initial estimates. The gap between expectation and reality grows with ticket volume and system complexity.

Why It Fails

Unrealistic timelines force teams to cut corners on QA and field mapping — the two steps that most directly affect data integrity.

• Rushed QA: When the deadline is tight, teams skip post-migration validation or test only a handful of tickets.
• Team burnout: Engineers and support leads working nights and weekends make more errors, not fewer.
• Hidden costs: Data validation, custom field scripting, attachment re-linking, and delta migration passes are rarely budgeted upfront.

Complexity by Volume

Migration complexity scales non-linearly with ticket volume:

Ticket Volume	Typical Complexity	Notes
Under 10K	Low	Often achievable with standard tooling; minimal custom scripting
10K–100K	Medium	Custom field mapping and a trial run become essential
100K–500K	High	Delta migration pass required to handle tickets created during the transfer window
500K+	Very High	Multiple migration passes, rate limit management, and dedicated QA cycles needed

For detailed benchmarks, see our Help Desk Data Migration Timeline and Cost of Help Desk Data Migration.

Mistake #4: Poor Data Mapping — Phase: Pre-Migration / Trial Run

Data mapping defines how every field in the source system translates to the destination. When mapping is wrong, data arrives in the new system corrupted or misplaced — and the damage is often invisible until agents start working tickets.

Why It Fails — Technical Mechanics

The core problem is field type mismatches between platforms. Common failures:

Source Field Type	Destination Field Type	What Breaks
Multi-select dropdown	Single-select dropdown	Only the first value is preserved; all other selections are silently dropped
Rich text (HTML)	Plain text	Formatting, inline images, and embedded links are stripped. Inline images become broken references
Custom date field	Text field	Date values lose their sortability and cannot be used in reporting or SLA calculations
Numeric field	Text field	Values are preserved as strings but break any automation that performs arithmetic
Null / empty field	Required field in destination	Import fails or inserts a default value, corrupting the record

Platform-specific behaviors compound these issues:

• Zendesk custom fields have a 255-character key limit. Fields with longer keys in other systems must be truncated or renamed.
• Freshdesk does not support nested dropdowns natively. Multi-level category fields from other platforms must be flattened.
• Intercom treats conversations and tickets as distinct objects. Migrating from a system where everything is a "ticket" requires deciding which object type each record maps to.
• Jira Service Management uses a different permission and field scheme per project. Fields that exist in one project may not exist in another, causing selective import failures.

How to Avoid It

Create a field-by-field mapping document before any data moves. For every field:

1. Record the source field name, type, and whether it allows null values.
2. Record the destination field name, type, and constraints (required, max length, allowed values).
3. Define the transformation rule for any type mismatch (e.g., "concatenate multi-select values into a comma-separated string").
4. Flag fields where data loss is unavoidable and document the accepted trade-off.

We provide CSV templates for this process in our Data Mapping Template guide.

Mistake #5: Ignoring Workflows and Automations — Phase: Pre-Migration / Cutover

Migrating tickets and contacts without migrating the logic that routes, escalates, and processes them leaves your team operating manually on day one.

Why It Fails

Automations are not portable. Every helpdesk implements automation differently:

• Zendesk uses triggers (event-based) and automations (time-based) as separate objects.
• Freshdesk uses Automations (formerly Dispatch'r, Supervisor, Observer) with different trigger conditions.
• Intercom uses Workflows with a visual builder that has no direct equivalent in most other platforms.

These cannot be exported and imported. They must be audited, documented, and manually rebuilt in the destination system.

How to Avoid It

Before migration, audit every automation:

1. Export or screenshot each active automation, macro, and workflow.
2. Document what it does, what triggers it, and what conditions it checks.
3. Identify which automations are still needed (retire any that reference deprecated fields or processes).
4. Rebuild the required automations in the destination system and test them in the trial run.

For a detailed walkthrough, see How to Migrate Automations, Macros and Workflows.

Mistake #6: Skipping QA and Testing — Phase: Post-Migration Validation

Skipping the testing phase after migration means going live with unverified data. Every issue your team discovers in production is an issue a customer will also experience.

Why It Fails

Without QA, the following problems go undetected until agents or customers report them:

• Broken attachments: Inline images that rendered in the source system appear as broken links in the destination. This is especially common when migrating between platforms that handle attachment storage differently (e.g., Zendesk stores attachments on its own CDN; Freshdesk uses S3-backed storage with different URL structures).
• Missing ticket relationships: Parent-child ticket links, merged ticket references, and side conversations may not survive the migration.
• Corrupted timestamps: Ticket creation and update times may shift if timezone handling differs between source and destination.
• Workflow misfires: Rebuilt automations may trigger on migrated tickets if "created" or "updated" events fire during import.

How to Avoid It

Build a QA checklist with binary pass/fail criteria:

Test	Pass Criteria
Total ticket count matches source	Destination count = Source count ±0.1%
Attachments render correctly	Random sample of 50 tickets with attachments — all inline images and files load
Custom field values preserved	Spot-check 100 tickets across all custom field types — values match source
Ticket-agent assignment intact	100 randomly sampled tickets show correct assignee
Timestamps accurate	Created/updated dates match source within the same timezone
Knowledge base articles render	All articles load with correct formatting, images, and internal links
Automations do not fire on migrated data	No outbound emails or status changes triggered by imported tickets

For a complete 20-point QA plan, see our Post-Migration QA guide.

Mistake #7: Missing Admin Permissions — Phase: Pre-Migration

This is a technical blocker that stops migrations before they start. The migration tool or script connects with insufficient permissions, and the process fails with access errors.

Why It Fails

A migration needs to perform operations that exceed standard agent permissions:

• Create and modify users and organizations
• Write ticket data including internal notes and custom fields
• Access and download all attachments
• Set ticket timestamps to historical values (backdating)
• Create knowledge base articles and categories

A standard agent account cannot do most of these. The migration fails, and the team loses time diagnosing permission errors.

How to Avoid It

Before connecting any tool, verify that the accounts used for both the source and destination platforms have full administrative privileges. Specifically:

• Zendesk: The account must be an Admin or Owner. API token access must be enabled.
• Freshdesk: The account must be an Account Administrator, not just an Agent or Supervisor.
• Intercom: The account must have "Super Admin" role with full API access.
• Jira Service Management: The account needs Jira Administrator and project-level admin permissions for every target project.

Mistake #8: Not Muting Notifications — Phase: Cutover

When a migration tool creates thousands of tickets in the destination system, the helpdesk does what it's designed to do: send notifications. If notifications are not disabled, every customer receives emails about "new" tickets, and agent inboxes explode.

Why It Fails

Helpdesks fire notification rules on ticket creation and update events. A migration that imports 20,000 tickets generates 20,000+ outbound emails. This is:

• A trust-destroying event for customers who receive dozens of unexpected emails
• A deliverability risk — email providers may flag your domain as spam
• An internal disruption — agents cannot distinguish real incoming tickets from migration noise

How to Avoid It

Before migrating a single ticket into the destination system:

1. Disable all outbound email notifications and triggers.
2. Disable all automations that fire on "ticket created" or "ticket updated" events.
3. Disable all webhook integrations that react to ticket events (Slack notifications, CRM syncs, etc.).
4. Verify the muting by creating one test ticket manually and confirming that no emails or webhook calls are sent.
5. Only re-enable notifications after the full migration is complete, tested, and verified.

Mistake #9: Not Vetting Your Migration Partner's Security — Phase: Pre-Migration

When you use a third-party migration tool or service, you grant them administrative access to your entire customer data history. Failing to verify their security posture creates compliance exposure.

Why It Fails

If the migration partner is not compliant with the standards your business is subject to, you inherit their risk. A breach on their side is your breach in the eyes of regulators and customers.

Compliance Requirements by Standard

Standard	What It Requires from a Migration Vendor	What to Request
SOC 2 Type II	Demonstrated controls for security, availability, and confidentiality over a sustained audit period	Current SOC 2 Type II report; verify the audit period covers your migration window
GDPR	Data processing agreement per Article 28; data minimization; right to deletion after processing	Signed Data Processing Agreement (DPA); documented data retention and deletion policy
HIPAA	Business Associate Agreement (BAA); encryption in transit and at rest; access logging	Signed BAA; documentation of encryption standards (e.g., AES-256 at rest, TLS 1.2+ in transit); audit log access

How to Avoid It

Before granting any third party access to your helpdesk:

1. Request and review their compliance certifications (SOC 2 report, GDPR DPA template, HIPAA BAA).
2. Ask how they access your data — do they store it, or process it in-memory only?
3. Ask how and when they delete your data from their systems after the migration is complete.
4. Verify their encryption standards for data in transit and at rest.
5. Confirm they maintain audit logs of all data access during the migration.

Delta Migration: The Step Most Teams Miss

One critical concept missing from many migration plans is the delta migration. During any migration, your support team continues working. New tickets are created, existing tickets are updated, and customers keep writing in. If you only migrate data once, everything created after your migration snapshot is lost.

A delta migration is a second (or third) pass that captures all changes made in the source system between the initial migration and the final cutover. For migrations involving more than 100K tickets, a delta pass is effectively mandatory — the initial migration takes long enough that a meaningful volume of new data accumulates during the transfer window.

How Delta Migration Works

1. Initial migration: Transfer all historical data from source to destination.
2. Continue operations: Your team keeps working in the source system during QA and testing.
3. Delta pass: Before cutover, run a second migration that captures only tickets created or updated since the initial migration's timestamp.
4. Cutover: Switch to the destination system. The gap between the delta pass and cutover should be as short as possible — ideally under an hour.

Attachment Handling: What Breaks

Attachments are a common source of silent data loss during migrations. The issues are platform-specific:

• Inline images: Many platforms store inline images as attachments with HTML references in the ticket body. If the migration transfers the ticket text but not the attachment, inline images appear as broken links.
• File size limits: Destination platforms may have lower attachment size limits than the source. Zendesk allows up to 50 MB per attachment; some platforms cap at 20 MB or less. Oversized files are silently dropped during import.
• File type restrictions: Some destination platforms block certain file types (e.g., .exe, .zip) that were allowed in the source system.

Always verify attachment integrity as part of your QA checklist. A random sample of 50 tickets with attachments is the minimum viable check.

---

A help desk migration is a chance to improve your support operations — but only if the data arrives intact. The mistakes above are predictable and preventable. Plan each phase, validate at every step, and verify your partner's security posture before granting access.

For a comprehensive best practices framework, see our guide on Best Practices for Help Desk Data Migration.