Not all your tickets need to migrate. Filtering lets you move only what matters.
Most teams migrate everything by default. Then they spend days after go-live cleaning up resolved tickets from three years ago, closed spam, and test records that never should have moved. Data filtering during migration prevents that.
It lets you define exactly which tickets transfer to Freshdesk or Freshservice. Less data means faster migration, a cleaner target system, and less noise for agents from day one.
Why filtering matters
Moving all your data sounds safe. It isn't always. Here's what unfiltered migrations lead to:
- Agents waste time in a cluttered system full of outdated or irrelevant tickets
- Reporting gets skewed by historical data that no longer reflects current performance
- Migration takes longer, increasing the window of risk
- Storage costs in the new system grow from day one
Filtering gives you a cleaner starting point.
One important thing to understand first
The filters available during migration depend on what the Freshdesk or Freshservice API exposes. Migration tools like Help Desk Migration pull data through the API. If a field isn't filterable via the API, it can't be used as a migration filter. This isn't a tool limitation. It's an API limitation.
Available filters for Freshdesk
When migrating from Freshdesk, one filter is available based on what the API exposes:
- Updated date — migrate only tickets updated before or after a specific date
Available filters for Freshservice
When migrating from Freshservice, the API supports filtering by:
- Type — incidents or service requests
- Updated date — tickets updated before or after a specific date
For changes and problems, filtering by update date is also available.
Other filters can be configured on request. Contact Help Desk Migration to discuss your specific setup.
Tip 1: Test before you commit
Don't filter too aggressively on the first pass. Run a Demo Migration with 20 sample tickets first. Check how your filter criteria behave before applying them to thousands of records. Skipped or failed records appear in the migration report so you can adjust before the full run.
Tip 2: Use filters to migrate in phases
You don't have to move everything at once. Start by filtering for recently updated tickets — for example, everything updated in the last 90 days. Migrate those first. Your team can start working in the new system on the most active, relevant data while the rest of the historical records are still transferring in the background.
This approach keeps support running. Agents aren't waiting for a Full Migration to complete before they can do their job. Once the recent data is in place, run a second migration for older records without disrupting live operations.
Data filtering is included in Help Desk Migration's setup. You configure filters before the full migration starts — no coding required.
Have you used data filters during a Freshdesk or Freshservice migration? What criteria did you filter by, and did it save time after go-live?
