Migrate from Front to Zendesk

Front Conversations are the primary migration unit and map to Zendesk Tickets. Each conversation's message segments are flattened into a single ticket body with author attribution and timestamp preserved on each comment entry. The conversation status (open, snoozed, archived) maps to Zendesk Ticket status (New, Open, Pending, Solved, Closed). Front's conversation subject becomes the Zendesk ticket subject; the first customer message segment becomes the initial ticket comment.

Front Contacts map to Zendesk End Users (User object with role=end-user). We match by email as the dedupe key. Front contact handles across channels (Twitter DM handle, Facebook handle, phone) map to Zendesk user fields or custom fields depending on the destination field availability. Custom properties on Front contacts migrate to Zendesk custom user fields with type compatibility checked before import.

Front teammates map to Zendesk Agent or Admin users. We resolve teammates by email match against the Zendesk User table. Front role names (Admin, Member, Guest) map to Zendesk roles (Light Agent, Agent, Admin) where possible. Any Front teammate without a matching Zendesk user is held in a reconciliation queue for the customer's admin to provision before record import resumes.

Front Inboxes define channel routing and teammate access. We map each Inbox to a Zendesk Group, preserving which teammates have access by mapping Inbox member assignments to Group membership. Complex permission inheritance across multiple Front Inboxes may require Zendesk Group-of-Group structures or additional Team-level scoping, which we flag during scoping.

Front channel attribution (email, chat, SMS, Twitter, Facebook, phone) is preserved as a custom Zendesk ticket field (channel_source) or by mapping to the Zendesk channel field if the destination uses Zendesk Suite channels. Starter-plan accounts that used only one channel carry that restriction in their historical data; we note this gap in the pre-migration data audit.

Each message segment within a Front conversation (customer message, teammate reply, assignment comment, internal note) maps to a Zendesk ticket comment. The comment author maps to the Zendesk agent or end-user; internal Front notes map to private Zendesk comments accessible only to agents. The original segment timestamp preserves activity ordering in the ticket timeline.

Front conversation tags are flat labels that map directly to Zendesk Tags. We export all tags applied across conversations and create matching Zendesk tags. Tag groupings and hierarchical tag structures from Front do not carry over as structured categories; if the customer uses tag hierarchies for reporting, we document the grouping logic for manual recreation in Zendesk.

Front Notes attached to a conversation or contact migrate to Zendesk as internal ticket comments (is_public=false). Note text, author attribution, and creation timestamp transfer directly. Notes attached to contacts without a ticket association migrate to a Zendesk user profile note or custom field depending on the destination schema configuration.

Front custom fields on conversations (dropdown, text, number, date, boolean) map to Zendesk custom ticket fields of equivalent type. We check Zendesk field type compatibility during the pre-migration field comparison phase and flag any truncations, type coercions, or value mismatches. For Front dropdown fields, the options list is recreated as Zendesk dropdown options before import.

Front custom contact properties migrate to Zendesk custom user fields. Data type mapping follows Front's supported types (text, number, date, dropdown, boolean). Zendesk Light Agents have restricted access to user field data, so we confirm the intended agent visibility during scoping. Multi-select dropdown values from Front map to Zendesk multi-select user fields where available.

Front Automation Rules are documented during discovery as a written inventory. Each Rule is captured with its trigger event, conditions, actions, and delay steps. The mapping is a lookup reference, not a data migration: Front Rules do not port as executable Zendesk Triggers because the conditional logic and action types differ structurally. We deliver a Rule-by-Rule specification document for the customer's admin to rebuild in Zendesk Admin.

Front Workflows are multi-step process automations distinct from Rules. We export the workflow structure (steps, conditions, branches, delays) as a written specification document. The workflow logic does not migrate as code to Zendesk SLA policies or automations because step-count limits, trigger types, and action libraries differ. We deliver a workflow inventory with recommended Zendesk equivalents for manual rebuild.