Migrate from SYDLE ONE to Zendesk

SYDLE ONE Account records map directly to Zendesk Organization. The Account name becomes Organization.name, website maps to Zendesk Organization.website, and any Account custom fields map to Zendesk organization custom fields. Organization is created before Contact/End User import to satisfy the organization_id lookup on ticket requesters. We use organization domain matching as the deduplication key during import to avoid duplicate Organizations.

SYDLE ONE Contact records map to Zendesk End Users. Email, name, phone, and custom properties migrate as user fields. A Contact without an email address cannot become a Zendesk End User and is flagged separately for manual resolution. Contact-Account relationships map to Zendesk organization_id on the End User record. Active agent Contacts from SYDLE ONE migrate as Zendesk Agents with their role set by the customer's admin during provisioning.

SYDLE ONE Service Desk Tickets map 1:1 to Zendesk Tickets. The most critical mapping step is explicit status remapping: SYDLE ONE status values (Open, In Progress, Resolved, Closed, and any custom statuses) must be explicitly mapped to Zendesk ticket statuses (New, Open, Pending, Hold, Solved, Closed, or custom Zendesk statuses from Suite Professional). Requester maps to the Zendesk end_user_id, assignee maps to the agent_id, and the original ticket ID is preserved in a custom field for cross-reference.

SYDLE ONE ticket conversation history (public and private comments) maps to Zendesk Ticket Comments. Public comments from agents map to Zendesk public comments; internal notes map to Zendesk internal comments (visible to agents only). Author is resolved by matching the SYDLE ONE Contact email to the Zendesk End User created in the Contact phase. Comments are imported in chronological order to preserve conversation threading.

SYDLE ONE ECM Documents attached to Tickets migrate as Zendesk Ticket Attachments. Documents linked to Process records without a ticket context migrate as Help Center article attachments if the Help Center content migration scope includes the relevant article. File metadata (original filename, mime type, size, upload date) is preserved. Files over 1MB may be excluded by default JSON export and are flagged in the pre-migration report for explicit inclusion via the Zendesk Content API.

Tags applied to Contacts, Accounts, Tickets, and Processes in SYDLE ONE migrate as Zendesk Tags. We normalize tag names that contain spaces, special characters, or non-ASCII characters before import to avoid Zendesk tag validation errors. Tags applied at the ticket level migrate as ticket tags; tags applied at the Contact level are stored in a custom field since Zendesk Tags are primarily a ticket-level feature. Multi-select custom field values in SYDLE ONE that function as tags map to Zendesk tags on the corresponding ticket.

SYDLE ONE custom fields on Tickets (dropdown, text, numeric, checkbox, date) require explicit mapping to Zendesk ticket custom fields. Dropdown fields map to Zendesk dropdown custom fields with options created in advance to match the SYDLE ONE picklist values. Numeric fields map to Zendesk integer or decimal fields. Checkbox fields map to Zendesk boolean fields. Date fields migrate as Zendesk date fields. Any unmapped custom fields from SYDLE ONE are flagged in the pre-migration report with a recommendation to create a corresponding Zendesk custom field before import.

SYDLE ONE BPMN Process definitions and their execution history do not map to any native Zendesk object. Process definitions export as structured JSON but have no equivalent representation in Zendesk. We export Process definitions as JSON and deliver them as a written inventory document for the customer's admin to assess for rebuild as Zendesk Triggers and Automations. Process execution history (timestamps, step completions, assignee paths) is not migratable in structured form and is flagged as excluded scope.

SYDLE ONE SYBOX Chatbot flows for WhatsApp, Facebook, Telegram, and other channels store as process-like JSON objects. These do not map to Zendesk's chatbot or messaging configuration. We export the flow logic and intent definitions as a configuration document. The customer's admin rebuilds the routing in Zendesk AI or Sunshine Conversations. This is a manual rebuild scope, not a data migration.

SYDLE ONE Service Portal records and portal page configurations store ticket and contact references by SYDLE ONE IDs. Because portal routing rules and page configurations reference source IDs that cannot be preserved in Zendesk Help Center, we export the portal configuration as a written document. The customer rebuilds Help Center articles, sections, and categories in Zendesk. Links within migrated Help Center content are preserved via cross-reference mapping during the content import.

SYDLE ONE Deal records attached to Tickets via cross-module links migrate as a custom field on the Zendesk ticket holding the original Deal ID, or as a Zenn (if the destination uses Zendesk Sell). If the customer is not using Zendesk Sell, Deals migrate as a written record in the deal inventory document for the customer's sales ops team to manually associate post-migration. Deal stage values are preserved in the custom field for reference.

SYDLE ONE custom objects with implementation-specific schemas migrate as Zendesk custom objects or Zenn objects depending on the destination Zendesk edition. We read the source custom object definitions via the SYDLE ONE admin interface, pre-create the destination custom object schema in Zendesk (field types, lookups, validation rules), and import the records in the standard dependency sequence. Custom object records that reference Tickets, Contacts, or Accounts are linked via ID remapping during the import phase.