Migrate from ASAPP to Zendesk

ASAPP Conversations map to Zendesk Tickets as the primary record. Each conversation thread migrates as a single ticket with the full message history in ticket comments. Channel metadata (messaging, voice, digital) maps to the Zendesk ticket channel field. Conversation ID from ASAPP is preserved in a custom ticket field as a reference anchor for audit and reconciliation. We resolve any duplicate conversations that appear across ASAPP's S3 batch and real-time export channels before insert to avoid double-counting.

ASAPP Agent records map to Zendesk User accounts with role=agent. Agent performance metrics (handle time, resolution outcomes, CSAT) do not have native Zendesk equivalents, so we preserve them as custom user fields on the Zendesk agent profile. Agent identity is resolved by email match; any ASAPP agent without a matching Zendesk user goes to a reconciliation queue for the customer's admin to provision before record import resumes.

ASAPP Customer profiles (the end users initiating conversations) map to Zendesk End Users. Email, name, and any custom attributes stored on the ASAPP customer record map to Zendesk user fields. Customer identity is used as the ticket requester in Zendesk, so end-user records must be created before ticket import to satisfy the requester_id foreign key. We deduplicate by email during the transform phase.

ASAPP's custom structured-data fields are defined via a dedicated API and extract non-standard data from conversations. These map to Zendesk custom ticket fields of equivalent type (text, numeric, dropdown, checkbox, date). We export the full ASAPP field schema before migration and map each field individually, flagging any type mismatches for customer review. Dropdown fields in ASAPP with defined option sets map to Zendesk dropdown fields with equivalent options.

ASAPP Segments define which structured data the system extracts for specific conversation types. Segment definitions migrate to Zendesk tag groups or as freeform tags on the ticket, depending on the customer's preference during scoping. If the ASAPP segment is used for routing classification, we document it as a Zendesk trigger condition for the customer's admin to rebuild post-migration.

ASAPP conversation metadata including routing information, CSAT scores, channel type, and resolution outcomes maps to Zendesk standard ticket fields. CSAT maps to Zendesk's Satisfaction Rating object. Routing metadata is preserved in a custom field for reference. Timestamps (created_at, resolved_at, updated_at) migrate to the Zendesk ticket created_at and updated_at fields to preserve the original conversation timeline.

ASAPP delivers reports via three channels: File Exporter API, S3 batch, and real-time event API. We do not migrate ASAPP report configurations to Zendesk Explore because the data models differ. We deliver a data dictionary mapping each ASAPP report metric to its nearest Zendesk equivalent so the customer's reporting team can rebuild dashboards in Explore post-migration. Historical report data is preserved in the migrated tickets and can be backfilled into Explore once the reporting schema is defined.

ASAPP's AI model tuning, routing rules, intent configurations, and GenerativeAgent® settings are proprietary platform settings that cannot be exported. We document the full configuration inventory during the discovery phase as a requirements spec that the customer's Zendesk admin can use to rebuild routing rules as Zendesk triggers, automations, and SLA policies. This documentation is delivered separately from the data migration scope.

ASAPP S3 batch reports carry predictable time delays and are considered the authoritative historical record. During migration scoping, we compare S3 batch data against real-time event API data to identify and fill any gap windows. We sequence S3 batch records first in the Zendesk import, then backfill any missing conversations from the real-time export. This reconciliation step is essential for accounts with high conversation volume and gaps between batch export windows.

ASAPP real-time event API exports carry lower latency than S3 batch and capture conversations that may not yet appear in batch reports. We use the real-time export as a delta layer during the migration window: after the initial S3 batch migration completes, we run a final real-time export pass to catch any conversations created or modified between the batch export timestamp and cutover. Zendesk API rate limits are respected via chunking and backoff.