Migrate from Service to Freshdesk

Freshdesk overwrites created_at with import timestamp by default

Freshdesk's ticket creation API sets the created_at timestamp to the moment of import, not the original ticket creation date from the source. This breaks historical SLA reporting and timeline reconstruction in Freshdesk Analytics. FlitStack AI handles this by storing the original created_at value in a custom field (Original_Created_At__c) and the original updated_at in Original_Updated_At__c. Teams that need Freshdesk-native SLA reporting on historical data must configure Freshdesk's SLA policies with a reference to these custom datetime fields or accept that SLA compliance metrics reflect the Freshdesk import date rather than the original ticket date. The workaround requires planning before migration and post-migration validation of any SLA reports built against historical data.

Freshdesk API rate limits are account-wide and plan-tiered

Freshdesk enforces per-minute rate limits that apply to the entire account regardless of how many agents or API keys are making requests. The Growth plan allows 200 calls/min, Pro allows 400/min, and Enterprise allows 700/min. These limits are shared across all active integrations, including any existing Freshdesk apps or webhook consumers. Migrations for accounts with large ticket volumes on Growth-tier Freshdesk accounts require careful pacing — exceeding the limit returns a 429 error and the migration must implement exponential backoff. FlitStack AI monitors rate limit headers (X-Ratelimit-Total, X-Ratelimit-Remaining) and throttles accordingly, but migrations under aggressive timelines often require upgrading the Freshdesk plan temporarily or requesting additional API capacity from Freshworks support before the migration window opens.

Automations and SLA rules do not migrate — source config is the rebuild reference

Every helpdesk platform defines automation triggers, conditions, and actions differently. Freshdesk's scenario automations use event-condition-action patterns with specific trigger events (ticket created, ticket updated, time-triggered) that do not map mechanically from other platforms. SLA policies in Freshdesk are tied to business-hours calendars and multiple policy definitions per ticket type — they require fresh configuration rather than a direct translation of source SLA settings. FlitStack AI exports the source automation definitions as a structured reference document, but the rebuild work sits with the Freshdesk admin post-migration. This is the most common source of post-migration rework — teams discover their routing logic, escalation rules, and SLA timers need to be rebuilt manually after go-live.

Parent-child ticket structures require pre-migration validation

If the source platform uses hierarchical or parent-child ticket relationships (sub-tasks, linked issues, parent cases), Freshdesk represents these through the 'tasks' attribute on a ticket rather than a separate child-ticket object. The migration must determine whether source sub-tickets become Freshdesk tasks attached to the parent ticket or whether they should be migrated as separate tickets with a custom link field. The choice affects how agents see related work in Freshdesk's UI and how reporting aggregates case volume. FlitStack AI surfaces this as a pre-migration decision point, mapping the relationship type explicitly rather than defaulting to one behavior and requiring cleanup afterward.

Custom fields must exist in Freshdesk before the migration run

Freshdesk requires that custom fields be created in the Admin panel before records containing those field values can be imported — the API rejects records with field keys that don't exist in the destination schema. For migrations with dozens of custom ticket fields or contact fields, this means the Freshdesk admin must create every destination field (with correct field type, pick-list values, and required/optional setting) before the migration run begins. FlitStack AI generates the field creation checklist from the source schema and validates that each field exists in Freshdesk before the migration run starts. Any missing fields are flagged with the exact field name, type, and pick-list values needed.