Migrate from SysAid to Freshdesk

Credentials and API access

We confirm the SysAid environment type (cloud or on-premise), database version for on-premise installations, SSO enforcement status, and API user availability. If SSO is enforced, the customer's SysAid admin provisions a dedicated API user that bypasses SSO. We test connectivity to the SysAid REST API, verify offset-based pagination capacity, and confirm the Freshdesk destination subdomain and API key. The Freshdesk plan is identified to confirm the applicable rate limit tier (Growth 200/min, Pro 400/min, or Enterprise 700/min). If the destination is a trial account, we recommend upgrading before migration to avoid the 50-call/min limit.

Source data audit and mapping design

We extract an inventory of all SysAid record types and counts: Service Records, Assets, Users, Companies, Tasks, Projects, Knowledge Base articles, and Action Items. We identify custom field definitions and types on each entity, note layered category structures, and flag attachment volumes. We design the field mapping from each SysAid field to the equivalent Freshdesk field, including custom field creation in Freshdesk before any data is written. This mapping document is reviewed with the customer before any extraction begins, with particular attention to custom field type compatibility and category level preservation.

Demo migration

We run a sample migration of up to 50-100 Service Records with a representative mix of statuses, priorities, and custom fields to validate the mapping. Attachments and notes are included in the demo to confirm re-linking behavior. The customer reviews the demo output in Freshdesk, identifies any field mapping corrections, and signs off before the full migration is scheduled. Any mapping issues discovered during demo are corrected in the mapping document before the production run. This step reduces the risk of large-scale mapping errors reaching the production environment.

Production migration in dependency order

We run the full migration in record-dependency order to satisfy foreign key and lookup relationships. Companies migrate first (as Freshdesk Companies). Users migrate second (as Freshdesk Contacts with company lookup resolved). Assets migrate in batched chunks to avoid timeout (as Freshdesk Assets and Configuration Items). Service Records migrate third with requester resolved to Contacts, assignees resolved to Freshdesk agents, category levels preserved, and attachment references re-linked. Tasks and Projects migrate fourth with parent entity references resolved. Knowledge Base articles migrate last. Each phase emits a row-count reconciliation report before the next phase begins.

Attachment and note handling

SysAid attachments (files from service records, comments, and notes) are extracted and re-linked in Freshdesk. The attachment filename is inserted into the ticket body as a note reference. For attachments stored in comments, the comment content migrates as a Freshdesk conversation entry. Internal notes from SysAid map to Freshdesk private notes. Public notes map to Freshdesk public conversation entries. We flag any attachment that exceeds Freshdesk's storage size limits for the customer's admin to address separately.

Cutover, validation, and automation rebuild handoff

We freeze SysAid writes during cutover, run a delta migration of any records modified during the migration window, then enable Freshdesk as the system of record. We validate record counts in Freshdesk against the pre-migration audit and spot-check 25-50 records for data fidelity. We deliver the automation and SLA inventory document to the customer's admin team for rebuild in Freshdesk's rule builder. We do not rebuild automations as code inside the migration scope; that is a separate engagement or an internal admin task.