Migrating Between Helpdesks
The tickets move easily. Everything that made your helpdesk work has to be rebuilt, and that is the part that overruns.
What moves and what does not
Moves with tooling: tickets, conversations, attachments, contacts, companies, knowledge base articles. Both vendors have importers and there is a healthy ecosystem of migration services.
Has to be rebuilt by hand: triggers and automations, macros or scenarios, views, SLA policies, business hours, ticket forms and custom fields, routing rules, integrations, and the reports everyone relies on.
That second list is the project. Anyone who quotes you a migration timeline based on data volume has not built the second list.
A realistic sequence
Clean before you move
A migration is the one moment when everybody accepts a data cleanup, so use it.
Merge duplicate contacts before you export, because importing them creates two records in the new system and splits every future ticket. And measure your duplicate ticket rate while you are in there. Migrating a queue that runs a tenth duplicates means paying to import work that should never have existed, then paying seats to handle it again.
Frequently asked questions
How long does a helpdesk migration take?+
Data, days. Configuration and testing, usually four to eight weeks for an established setup. Plan for the second number.
Will we lose ticket history?+
No, if you plan the import. Check threading order and attachments on a sample before you trust the whole set.
Should we migrate to fix ticket volume?+
No. Volume follows your customers and your product. Removing duplicates reduces it, and that needs no migration.
Do not import work that should not exist
Measure your duplicate rate before you migrate. It is the cheapest volume reduction available, on either platform.
Start free trial14-day free trial. No credit card required.