Name the migration owner
One person should own decisions. That does not mean one person does all the work, but someone must approve mappings, answer edge-case questions, and keep the project moving.
Without an owner, migrations stall in small decisions: which fields matter, what to do with inactive agents, whether old tags should be kept, and when final cutover should happen.
Separate historical data from future workflow
Historical records help agents understand customers. Future workflow helps the team operate better. These are related, but not the same.
Do not blindly recreate every old status, group, category, or automation in the new helpdesk. Use migration as a chance to preserve useful history while improving the operating model.
Build a data inventory
List every object type you care about: tickets, contacts, companies, comments, attachments, users, agents, teams, groups, tags, custom fields, SLAs, knowledge base articles, and satisfaction ratings.
For each item, mark whether it must migrate, can be archived, or should be recreated manually in the new tool.
Plan permissions and access early
Migration needs secure access to both source and target systems. Decide who can create API keys, who can approve permissions, and who can validate results.
Security reviews, procurement, and legal approvals often take longer than the migration itself, so do not leave them until go-live week.
Test with real examples
A demo migration should include normal tickets and ugly tickets. Normal tickets prove the expected path works. Ugly tickets prove the edge cases are manageable.
Review tickets with many comments, attachments, private notes, merged customers, deleted agents, changed organizations, unusual encodings, and old timestamps.
Make post-migration QA concrete
After migration, validate counts, timestamps, requester data, assignee history, comments, attachments, tags, custom fields, and search behavior. Also ask agents to inspect real customer examples.
The goal is not perfect theoretical parity. The goal is operational confidence.
Keep a rollback mindset
You may not need to roll back, but you should know what happens if the cutover is delayed. Keep the old helpdesk available during validation and avoid deleting source data immediately after launch.
