Migrate from CommBox to Freshdesk

Discovery and schema mapping

We perform a live authenticated export scan of the CommBox environment to discover available objects, custom field definitions, conversation volume by channel, agent count, team structure, and active routing rule configurations. We pair this with a Freshdesk environment audit to identify the destination plan tier, existing custom fields, groups, and routing configurations. The discovery output is a written Migration Scope document that includes a complete CommBox-to-Freshdesk object mapping, custom field migration matrix, and the Automation Inventory of all active AutoX scripts for the customer's admin to review.

Freshdesk schema pre-creation

Before any data moves, we pre-create the destination schema in Freshdesk. This includes custom contact fields and custom ticket fields (matching the CommBox custom field types and formats), Freshdesk Groups (aligned with CommBox teams), Freshdesk agents (matched by email to CommBox agent records), ticket categories, and SLA policies. Freshdesk requires custom fields to exist in the schema before data import; we create them in the correct order so that subsequent imports satisfy field references. This phase runs in a Freshdesk test environment first, with a customer review before production configuration.

Demo migration and reconciliation

We run a demo migration of a representative subset (typically up to 100 tickets with associated contacts, attachments, tags, and custom fields) into a Freshdesk test environment. The customer's support admin and one working agent review the migrated records for accuracy: conversation thread completeness, attachment rendering, custom field values, tag application, and agent attribution. We adjust the mapping based on feedback and re-run the demo if corrections are needed. This step catches mapping gaps that record counts alone do not reveal and prevents them from propagating into the full production migration.

Agent and group reconciliation

We extract every distinct CommBox agent and team referenced on conversations and map them to Freshdesk Users and Groups. Agents without a matching Freshdesk user account are placed in a reconciliation queue. The customer's Freshdesk admin provisions missing users (active or inactive depending on whether the original CommBox agent is still employed) before record migration proceeds. Group-to-Team mapping is confirmed at this stage so that ticket routing references are valid at import time.

Production migration in dependency order

We run production migration in record-dependency order: Agents and Groups first (already provisioned but verified), then Contacts (from CommBox customers with custom fields), then Tickets (from CommBox conversations with channel metadata, tags, attachments, and SLA metadata linked to the correct Contact and Agent). Custom fields are populated during each phase using the pre-created Freshdesk field schema. Attachments are uploaded separately and linked via Freshdesk's attachment API, respecting the 10 MB per-file limit on Growth plans. Each phase emits a row-count reconciliation report before the next phase begins.

Cutover, validation, and automation handoff

We freeze CommBox writes during cutover, run a final delta migration of any records created or modified during the migration window, then enable Freshdesk as the system of record. We deliver the Automation Inventory document (documenting all AutoX scripts) and the Routing Rules Configuration Notes to the customer's Freshdesk admin. We support a one-week hypercare window where we resolve any reconciliation issues raised by the support team. We do not configure Freshdesk routing rules, Freddy AI Copilot, or SLA policies as part of the migration scope; those are documented separately for the admin to configure based on the inventory deliverables.