Data Migration Checklist for Switching Help Desk Platforms

Switching help desk platforms is one of the few projects where a single missed record can break a customer conversation. A structured checklist reduces that risk by turning a vague “move everything” goal into a series of verifiable steps. Below are nine practices that teams of any size can follow, each with the reasoning behind it and a concrete way to apply it.

1. Inventory All Data Sources

Reasoning: Help desk data lives in more places than the ticket table — contacts, organizations, custom fields, tags, macros, SLAs, and attachment storage may each reside in separate modules or even external services. How to apply: Create a spreadsheet that lists every object type, its source system, the estimated record count, and any dependencies (e.g., tickets reference contacts). Share the sheet with the migration owner and the vendor’s support engineer to confirm nothing is omitted.

2. Define Migration Scope and Priorities

Reasoning: Not every historic ticket needs to move. Legal retention rules, storage limits, and the cost of cleaning old data often make a full‑history migration unnecessary. How to apply: Agree on a cutoff date (e.g., last 24 months) and a priority tier: active tickets, open conversations, and high‑value customers move first; closed tickets older than the cutoff can be archived in a read‑only export. Document the decision in the project plan so stakeholders can sign off.

3. Map Fields and Custom Objects

Reasoning: Source and target platforms rarely share identical field names, data types, or pick‑list values. A direct CSV dump will produce mismatched or truncated data. How to apply: Build a field‑mapping matrix: source field → target field → transformation rule (rename, split, combine, default value). Include custom objects such as “product version” or “region.” Validate the matrix by importing a 50‑record sample and reviewing the result in the new UI.

4. Clean and De‑duplicate Before Export

Reasoning: Duplicate contacts, malformed email addresses, and orphaned tags inflate record counts and create noise after migration. How to apply: Run deduplication scripts on the export files: merge contacts with identical email domains, standardize phone formats, and drop tags that have zero associated tickets. Keep a log of every merge so you can explain any record‑count differences to auditors.

5. Run a Small‑Scale Test Import

Reasoning: A full import can take hours and may hit rate limits or hidden validation rules. A test run surfaces errors early. How to apply: Import the 50‑record sample from step 3 into a sandbox or a dedicated test workspace. Verify that ticket threads appear in chronological order, that attachments open, and that custom fields display the expected values. Document any error messages and adjust the mapping matrix accordingly.

6. Validate Ticket Thread Integrity

Reasoning: The most visible failure mode is a broken conversation — replies appear as separate tickets, timestamps shift, or internal notes disappear. How to apply: After the test import, pick 10 representative threads (including multi‑agent hand‑offs and CC’d external parties). Compare the thread view side‑by‑side with the source system. Check that message IDs, timestamps, and author metadata match. If the target platform supports a “conversation ID” field, map it explicitly.

7. Preserve Attachments and Metadata

Reasoning: Attachments often live in a separate blob store. Losing them means losing contracts, screenshots, or compliance evidence. How to apply: Export attachments with their original filenames and MIME types. In the import CSV, include a column that references the attachment’s storage path or URL. After import, spot‑check 20 random tickets to confirm the files open and retain the correct modification date.

8. Plan for Downtime and Communication

Reasoning: Even a well‑tested migration can require a brief read‑only window while the final delta sync runs. How to apply: Schedule the cut‑over during the lowest‑traffic period (often early morning or weekend). Notify customers via a brief banner in the old portal and an email to key accounts. Provide the support team with a run‑book that lists the exact commands to switch MX records, enable the new inbox, and verify inbound flow. For teams that want a free environment to rehearse the cut‑over, NeuraDesk offers a free shared inbox and AI reply suggestions with no credit card required.

9. Post‑Migration Audit and Rollback Plan

Reasoning: Issues sometimes surface days later — missing SLA timestamps, broken automation rules, or mismatched reporting. How to apply: Define a 48‑hour audit window. Run automated counts (tickets, contacts, attachments) against the pre‑migration inventory. Open a dedicated Slack channel or email thread for agents to report anomalies. Keep the old platform in read‑only mode for at least two weeks; if a critical data loss is discovered, you can re‑run the delta import from the last successful snapshot.

Practical takeaway: Treat the migration as a series of verified, repeatable steps rather than a single “big bang” event. By auditing sources, mapping fields, testing with real data, and preserving a rollback path, you protect both the customer experience and the team’s confidence in the new platform.

Try NeuraDesk free to rehearse your cut‑over in a sandbox environment: try NeuraDesk free.