1. Freeze the scope before export
List the exact objects that must move: tickets, comments, contacts, organisations, attachments, tags, custom fields, knowledge articles, consent records and SLA data. Mark what the vendor's standard export includes and what requires an API or manual handling.
- Open and historical ticket counts
- Attachments and internal notes
- Contact and organisation fields
- Knowledge base and redirects
- Reporting history that must be archived
2. Build a field and status map
Map every status, priority, group, owner, tag and custom field from the old system to the new one. Decide how values without a direct equivalent will be archived. A documented map makes both test imports and a possible rollback auditable.
3. Test-import a difficult sample
Do not select only recent, simple tickets. Include long threads, attachments, merged tickets, several languages, sensitive permissions and records that crossed multiple teams. Verify content, timestamps, senders, ownership and searchability after import.
4. Run in parallel with a clear cutover
Define when new requests start entering the new system and how late replies in the old inbox will be captured. Test email, forms, chat, social channels, integrations, notifications, SLAs and human handoff before cutover.
- One owner for the cutover decision
- A monitored list of open defects
- Daily reconciliation of ticket volume
- A documented fallback plan
- No deletion of source data during verification
5. Approve the move with measurable checks
Reconcile record counts by object, run manual samples and let agents resolve real tickets in the new environment. Archive export files and the migration log under the company's security and retention rules. Retire the old system only after data, routing and reporting are verified.