Migrate from Capacity to Zendesk

Capacity Tickets map directly to Zendesk Tickets. We preserve ticket number, status, priority, assignee (mapped to Zendesk agent), requester email, subject, created_at, updated_at, and resolution time. Capacity ticket IDs are stored in a custom Zendesk field capacity_original_id__c for historical reference and cross-system lookup.

Each Capacity Ticket's Conversation thread maps to Zendesk Ticket Comments. Message content, author type (customer, agent, bot), timestamp, and public-versus-internal visibility transfer. Internal notes in Capacity map to Zendesk's internal comment visibility flag. We preserve the conversation sequence by setting Zendesk comment created_at to the original Capacity message timestamp.

Capacity KB Articles map to Zendesk Guide Articles with article title, body text, author, created date, updated date, and status (draft, published). We note that rich formatting, embedded media, and article version history do not transfer from Capacity's simplified KB export and will require post-migration review and cleanup for articles with complex layouts.

Capacity's two-level KB structure (Category containing Articles) maps to Zendesk Guide's three-level hierarchy (Category containing Section containing Article). We flatten Capacity categories to Zendesk Guide Sections within a parent Category during import. Customers with deeply nested Capacity KB hierarchies will need to decide how to collapse intermediate levels into Guide's three-tier structure.

Capacity Users (agents and end-users) map to Zendesk Users. We match by email address as the dedupe key. Agent status, role (admin, agent, end-user), and team assignment migrate. End-user accounts in Capacity become Zendesk End Users; agent accounts become Zendesk Agents with group assignments resolved post-migration.

Capacity Teams map to Zendesk Groups, which serve as the primary routing unit in Zendesk. Team-based ticket assignments migrate as Zendesk Group assignments. We note that Zendesk's routing rules and SLA policies reference Groups rather than Teams, so post-migration the customer configures routing triggers that assign tickets to the migrated Groups.

Capacity custom fields on tickets require type validation and transformation before Zendesk import. Capacity text fields map to Zendesk text fields; picklist fields map to Zendesk dropdown or tag fields depending on the target plan; date fields map to Zendesk date fields. We flag any Capacity custom field types that have no direct Zendesk equivalent (such as complex JSON payload fields) and document them for manual review or transformation.

File attachments on Capacity tickets and KB articles are extracted and linked to the corresponding Zendesk Ticket or Guide Article. We validate file size against Zendesk's attachment limits (max 50 MB per file). Files exceeding the limit are flagged and either split or excluded from migration with a reference list for manual re-upload.

Tags applied to Capacity tickets migrate as Zendesk Tags. Tags are not tied to a specific ticket field in Zendesk but appear in search, views, and reporting. We migrate the full tag taxonomy and note that Zendesk does not support tag hierarchy, so any nested tag structures in Capacity are flattened.

Capacity automation rules and routing logic are not accessible via the API and cannot be migrated programmatically. We document the current automation configuration (trigger conditions, routing actions, SLA settings) during the discovery phase and deliver a written map with recommended Zendesk Trigger and Macro equivalents. The customer's Zendesk admin rebuilds these manually after migration.