Migrate from DeskDirector to Freshdesk

Discovery and scoping

We audit the DeskDirector tenant for ticket volume, board count, contact count, company count, agent roster, SLA policy definitions, and knowledge base size. We assess whether any stale tickets need timestamp patching to survive the six-month culling window. We confirm the Freshdesk tier (Blossom minimum required for API) and map the board-to-group structure. We extract the VIP/Approval/Invoice permission flags for custom field planning. The output is a written migration scope document covering record counts, permission translation logic, SLA mapping, and explicit exclusions (chat history, AI Assistant rules, dynamic forms as code).

Schema design and Freshdesk environment preparation

We provision or configure the Freshdesk destination environment: Groups (one per DeskDirector Board), SLA Policies (mapped from DeskDirector board-level SLA definitions), custom fields (for VIP, Approval, and Invoice permission flags), Knowledge Base categories, and agent accounts. We validate that the Freshdesk API is accessible on the configured tier before migration tooling begins. Schema design is validated in a Freshdesk test account or sandbox if the customer has one available.

Export instrumentation and rate-limit management

We instrument the DeskDirector REST API using cursor-based pagination against the Tickets endpoint since no bulk export endpoint exists. We batch exports in chunks to stay within DeskDirector's rate limits and avoid throttle-based lockouts during large-volume reads. Contacts and Companies export with their permission flags and multi-company associations preserved. We run a delta pass immediately before migration cutover to capture any records created or updated during the migration window.

Demo migration and reconciliation

We run a demo migration of a representative sample (typically 50-100 tickets, 25 contacts, 10 companies) into the Freshdesk destination. The customer's team reconciles the sample against DeskDirector records for field accuracy, SLA policy assignment, group placement, and permission flag preservation. Any mapping corrections are documented and applied before the full migration begins. We do not proceed to full production migration until the demo sample is signed off.

Production migration in dependency order

We run production migration in record-dependency order: Companies (first, as they are referenced by Contacts), Contacts (with permission flags as custom fields and multi-company associations resolved), Agents (matched by email), Groups (one per DeskDirector Board), SLA Policies (mapped from board-level definitions), Tickets (with board-to-group lookup resolved and stale tickets excluded per scope), Knowledge Base articles (with category hierarchy preserved), Tags (1:1 string arrays), and Attachments (URL references flagged for post-cutover remediation). Each phase emits a row-count reconciliation report.

Cutover, deliverables handoff, and non-migratable asset documentation

We freeze DeskDirector writes at cutover, run a final delta pass for records modified during migration, then mark Freshdesk as the system of record. We deliver the Dynamic Form configuration JSON with a written mapping to Freshdesk form fields, the AI Assistant rule inventory with Freddy AI equivalents, the permission-rebuild recommendation document, and the Knowledge Base structure export. Chat history export remains the customer's manual responsibility per the gap flagged at scoping. We offer a one-week post-migration hypercare window for reconciliation issues but do not rebuild automations, forms, or workflows as part of the standard migration scope.