How to Migrate Historical Ticket Data During an ITSM Platform Switch

ITSM ticket data migration is the part of a platform switch most teams get wrong. What you migrate, how you clean it, and how you validate it decides whether your new platform starts clean or inherits the mess from the old one.

This guide covers what to migrate, what to leave behind, how to clean data before it moves, how to run the migration safely, and how to validate before go-live.

Planning a platform switch and want an experienced view of your data scope before committing? Book a diagnostic call and we will map your migration scope and timeline in 30 minutes.

Why ITSM Ticket Data Migration Is Harder Than It Looks

Exporting from one platform and importing to another sounds straightforward. In practice, three things make it complex.

Data model differences. Every ITSM platform structures data in its own way. Fields in the source may not exist in the target. Fields in the target may not exist in the source. These gaps need mapping decisions before the migration runs, not during it.

Data quality problems. Most platforms accumulate years of bad data: wrong categories, duplicate contacts, inactive agents on open tickets, custom fields nobody uses, and outdated knowledge base articles. Moving this mess to a new platform costs significantly more to fix later than it would have to clean before migration.

Relationship preservation. Tickets have comments, notes, attachments, linked problems, changes, assets, and requesters. Moving tickets without these links produces records that look complete but lack the context that makes them useful.

The preparation gap

Research from Kaopiz Software found that 65% of failed migration projects spent less than 20% of their total timeline on planning. In ITSM data migration specifically, the preparation steps most commonly skipped are data cleaning, demo migration, and field mapping documentation. These are also the steps that prevent the most expensive post-go-live problems.

Step 1: Decide What to Migrate

More is not better. Every record you migrate costs time to clean, map, test, and validate. Migrating data nobody will ever access is wasted effort that also adds noise to reporting in the new platform.

Migrate This

• Open tickets. Every open, pending, or on-hold ticket must move. These are active work items your team needs on day one.
• Recent closed history. A rolling 12-month window covers most audit and reporting needs. Extend to 24 months only for a specific compliance requirement.
• Active users. All current agents and requesters with group and role assignments. Do not migrate inactive users. Deactivate them in the source first.
• Current assets. If asset management is in scope, migrate the clean, current inventory. Remove retired assets and fix ownership records before migration.
• Current knowledge base articles. Review each one. Migrate what is accurate and current. Archive the rest. Start with a knowledge base your team trusts.

Do Not Migrate This

• Old ticket history. Tickets from two or three years ago add noise without adding value. If compliance requires them, keep them in the old system or a static archive.
• Inactive users. They create orphaned records and pollute the directory in the new platform.
• Unused categories and fields. If a category has not been used in 12 months, do not migrate it. Collapse to what is actively used.
• Outdated knowledge base articles. Articles not updated in 12 or more months should be reviewed individually. Outdated articles are worse than no articles.
• Attachments (optional). They increase migration time significantly. For most ticket types, history and comments provide enough context. Skip unless compliance requires them.

Step 2: Clean Data Before You Move It

Cleaning feels like overhead. It is not. Every problem found after migration costs more to fix than it would have before. In practice, data cleaning is the step that most directly determines whether the new platform starts productively or spends its first month in remediation.

• Deduplicate contacts. Run a duplicate report. Merge duplicates before migration. One requester with three records becomes three partial records in the new platform.
• Deactivate inactive users. Find agents and requesters who have not logged in or submitted a ticket in 12 months. Deactivate them before migration.
• Fix categories. Map old categories to your new structure. Recategorise tickets in bulk before migration rather than one by one after.
• Review open tickets. Close resolved tickets. Reassign tickets from departed agents. These tasks are easier in the familiar platform than in an unfamiliar new one.
• Check custom field values. Fix inconsistent dropdowns, wrong capitalisation, old abbreviations, and legacy options. These cause field mapping errors during import.

Step 3: Build the Field Mapping Document

This is the most important technical output of the preparation phase. It defines where every source field lands in the target platform. Without it, the migration tool guesses. When the migration tool guesses, data ends up in the wrong place or gets lost silently.

Source Field	Target Field	Decision
Ticket ID	Custom field	Store old ID for cross-reference
Subject	Subject	Direct map
Description	Description	Direct map
Status	Status	Map each value to Freshservice equivalent
Priority	Priority	Map to new four-tier model
Category	Category	Map to new simplified structure
Requester	Requester	Match by email. Pre-create records first.
Agent	Agent	Match by email. Map departed agents to default group.
Comments	Conversations	Public replies and internal notes
Custom fields	Custom fields	Pre-create in Freshservice before migration runs

For fields with no match in the target, decide: create a custom field, map to the closest option, or exclude it. Document every decision. The field mapping document also serves as your post-migration validation checklist.

Create all custom fields in Freshservice before the migration runs. The tool maps source to target. Target fields must exist first. Data migrated to a field that does not exist is silently lost with no error message.

Step 4: Prepare the Target Platform

Before any data import begins, prepare Freshservice to prevent automation from firing during the import process.

• Turn off notifications. If active during import, every migrated ticket sends emails. For 10,000 tickets, that is a flood of unwanted messages to agents and requesters.
• Turn off workflow automations. Active rules can reassign tickets, change statuses, or close records during import. That corrupts historical data in ways that are difficult to reverse.
• Turn off the Priority Matrix. It overwrites source priority values with Freshservice defaults. Disable it to preserve source priorities. Re-enable after validation is complete.
• Import users first. The migration tool matches tickets to requesters and agents by email address. Those records must exist in Freshservice before tickets arrive or assignments fail silently.

Step 5: Run the Demo Migration

Never skip this step. A demo migration transfers 100 to 200 records and verifies field mappings before the full run. The demo migration consistently catches issues that the field mapping document does not anticipate, usually because source data is less consistent than the field mapping assumes.

Check five to ten migrated tickets against the source. Verify subject, description, priority, category, and status. Check custom fields are present. Verify comment visibility is correct: public replies as public, internal notes as private. Confirm requester and agent assignments. Check attachments if in scope. Fix every issue found before the full run. The most common problems are missing custom fields, status mismatches, and email address mismatches between the source and target user directories.

Step 6: Run the Full Migration

Schedule the full migration for a quiet period. Friday afternoon or Saturday morning works well for most ANZ teams. Running without new tickets being processed simultaneously reduces variables during the import.

Monitor it live. Watch for timeout errors on large attachments, field validation failures, and duplicate record errors. Run the delta migration after the main run completes, as this step catches records created in the source system during the migration window. Record the final totals: tickets, contacts, knowledge base articles, and assets migrated. These numbers form your validation baseline.

Step 7: Validate Before Go-Live

Validation is not optional. Run it before re-enabling automations and before go-live. Validation found during this step costs minutes to fix. Validation found by users after go-live costs significantly more in trust and remediation time.

• Count check. Compare migrated record totals against the source system. Discrepancies need investigation before go-live.
• Spot-check 20 to 30 tickets. Across different categories, priorities, and statuses. Compare every field against the source.
• Validate every open ticket. Correct requester, correct agent, correct priority, complete history, correct SLA. A missed open ticket affects a real user on day one.
• Check users. Confirm agents and requesters are present with correct groups and roles.
• Check knowledge base. Spot-check 10 to 15 articles. Folder structure intact, content complete, accessible in the portal.

Once validation is complete, re-enable notifications, automations, and the Priority Matrix. The platform is ready for go-live.

Common ITSM Data Migration Mistakes

Mistake	What Happens	How to Avoid It
No data cleaning before migration	Duplicates and old records carry into the new platform	Clean in source first. Deactivate, merge, and recategorise before migration runs.
Skipping demo migration	Errors found only after the full run	Always test with 100 to 200 records first and fix every issue before the full run
Custom fields not pre-created	Data has nowhere to land and is silently lost	Create all target fields before the demo migration runs
Automations left on during import	Emails flood agents and users, tickets get corrupted	Turn off notifications, automations, and Priority Matrix before any import begins
Too much data migrated	Noise in the new platform, slower performance, corrupt reporting	Default to 12 months of closed history. Archive anything older.
Users not imported first	Tickets have no requester or agent assignment	Import user records before ticket data in every case
No validation plan	Issues discovered by users after go-live	Validate systematically before re-enabling automations

Migration Tools for ANZ Teams

Help Desk Migration. Supports 80+ platforms. Demo and delta migrations. No-code interface. AU$500 to AU$5,000 for most ANZ mid-market teams. The most commonly used tool for Freshservice migrations in the ANZ market.

ClonePartner. Built for complex migrations from ServiceNow, Jira, and BMC to Freshservice. Good for CMDB, changes, and problems with relationship mapping. Used when source data models are complex or when CMDB relationships need to be preserved.

Native import. Freshservice CSV imports for tickets, users, and assets. Simple and low-volume only. No relationship support or delta runs. Suitable for straightforward migrations with small data volumes.

API migration. Provides the most control and handles the most complex scenarios. However, it requires the most effort. Most ANZ mid-market teams get faster results with a purpose-built migration service than building custom API integrations.

What preparation skips actually cost

The steps most commonly skipped in self-directed ITSM data migrations are data cleaning, demo migration, and turning off automations before import. Each skipped step takes less than a day to complete properly. Post-migration remediation for problems caused by skipping these steps typically takes two to four weeks. That is the actual cost of skipping preparation.

For teams planning a full ITSM platform migration, our ITSM Platform Migration service covers data migration planning as a core component. You can also read our complete ITSM migration checklist for ANZ teams for the full preparation process that surrounds the data migration work, and our article on ITSM implementation mistakes for the broader project decisions that affect whether a migration succeeds.

Book a 30-minute diagnostic call. We will tell you honestly what is broken, what is not, and what to fix first.

Frequently Asked Questions

Sources

• Help Desk Migration. (2026). Complete Freshservice Data Migration Checklist.
• Help Desk Migration. (2026). Quick Freshservice Data Import.
• Freshworks. (2025). Zendesk to Freshservice Migration.
• ClonePartner. (2026). Freshservice Custom Data Migration.
• Kaopiz Software. (2025). The Hidden Complexity of Data Migration.