Migrate from Spiceworks Cloud Help Desk to Freshdesk

Preparation and scoping

We audit the source Spiceworks Cloud account for ticket volume, active technicians, organizations, Knowledge Base article count, and any custom ticket fields. We verify the destination Freshdesk plan (must be Growth or above for API access) and confirm that all Freshdesk custom fields are pre-created to match the Spiceworks export schema. If the Spiceworks account data exceeds 4 GB, we develop an archiving strategy (closing or moving old tickets) and scope a multi-pass export if needed. The output is a written migration scope, a field mapping table, and a ticket volume estimate for rate-limit budget planning.

Freshdesk schema pre-configuration

Before any data moves, we configure the Freshdesk destination: agents provisioned and assigned roles, Companies created or mapped from Spiceworks Organizations, Knowledge Base sections and categories created to match the Spiceworks KB structure, and custom ticket fields pre-created in Freshdesk Admin with correct API names and field types. This step ensures that when the migration runs, no record is rejected due to a missing destination field. We coordinate with the customer's Freshdesk admin who has the necessary write permissions to Admin settings.

Spiceworks export and data extraction

We trigger a full all-time ticket export from Spiceworks Cloud via Exports > Create Report > All-time, downloading the JSON file. We extract technician accounts, requester records, organizations, Knowledge Base article content, and ticket records from the JSON. If comment thread screenshots are required by the customer, we flag this as a manual step to be completed before the migration window. We also extract attachment metadata (filenames, types, original ticket URLs) from the export for the post-migration attachment reconciliation step.

Sandbox migration and reconciliation

We run a trial migration into the customer's Freshdesk test environment (or a fresh Growth trial) using a sample of ticket records, agents, and contacts. We reconcile record counts (tickets in, contacts in, companies in), spot-check field mapping on 20-30 random tickets against the Spiceworks source, and verify that Freshdesk custom fields are populated correctly. Any mapping corrections, missing field mappings, or status translation errors are corrected before the production migration begins. This step prevents data-quality issues from reaching the live Freshdesk instance.

Production migration in dependency order

We run production migration in record-dependency order: Agents first (Freshdesk agent IDs resolved), then Companies (from Spiceworks Organizations), then Contacts (with company_id resolved via email or organization name lookup), then Knowledge Base Articles (with section mapping), then Tickets (with requester_id and responder_id resolved via prior agent and contact imports). We write tickets in batches respecting Freshdesk's per-minute rate limit, implement exponential backoff on 429 responses, and emit a per-phase reconciliation report before moving to the next object. Custom fields are populated per the mapping table during ticket writes.

Cutover, attachment reconciliation, and automation handoff

We freeze Spiceworks Cloud writes during cutover, run a final delta migration of any tickets created or modified during the migration window, then make Freshdesk the system of record. Attachment metadata from the Spiceworks export is delivered as a checklist for the customer's admin to re-attach from Spiceworks Cloud directly. We deliver a written inventory of Spiceworks Workflow equivalents mapped to Freshdesk Automation Rules with trigger, condition, and action documentation. We support a 48-hour post-migration validation window. We do not rebuild Spiceworks automations as Freshdesk Automation Rules inside the migration scope.