Migrate from Vision Satellite Help Desk to Zendesk

Vision Tickets map directly to Zendesk Tickets. The Vision ticket ID is preserved in a custom field vision_ticket_id__c for cross-referencing. Vision's private staff notes and client-visible comments split into Zendesk's internal note versus public comment model — we detect Vision's private/public flag during export parsing and set Zendesk's is_public property accordingly. Status values (Open, Pending, Resolved, Closed) map to Zendesk ticket_status values with a configurable mapping table defined during scoping.

Vision Clients map to Zendesk End User records. The Vision client-to-Organization linkage maps to Zendesk user organization's field, preserving the foreign-key relationship. Email address serves as the dedupe key. Vision Clients with no email address are flagged during scoping and mapped to Zendesk's partial user format with a note field holding the name.

Vision Organizations map to Zendesk Organizations. Organization name maps to name, domain to domain, and custom fields to Zendesk organization custom fields. The client-to-org linkage is preserved as the Zendesk user's organization_id lookup. Organizations are imported before Clients so that the organization_id reference is satisfied at the moment of User insert.

Vision Staff Agents map to Zendesk Agent accounts. We match by email against the destination Zendesk User table. Role names from Vision (Agent, Supervisor, Admin) are normalized and mapped to the closest Zendesk role: Vision Admin maps to Zendesk Admin, Vision Supervisor maps to Zendesk Agent with custom admin-group membership, and Vision Agent maps to Zendesk Agent. Any Vision Staff without a matching Zendesk User goes to a reconciliation queue for the customer's admin to provision before record import resumes.

Vision Labels and Tags migrate to Zendesk Tags via a direct name match. Vision Flags (a Vision-specific boolean taxonomy) have no Zendesk native equivalent; we map them to Zendesk custom fields of type checkbox or tag-prefixed values based on the customer's preference during scoping. When multiple Flags exist on a single ticket, we create a multi-select custom field or a compound tag string to preserve the full taxonomy. Labels stored as comma-separated in CSV exports are split during the normalization step before tag creation.

Vision stores multiple assigned agents as a comma-separated list on the ticket. We split this list and designate the first agent as the Zendesk assignee. Subsequent agents map either to the ticket CC field (if Zendesk Suite supports CC on tickets) or to a custom multi-agent field agent_cc__c defined during scoping. The customer chooses the strategy during scoping; the written migration spec documents which approach is used and why.

Vision custom fields on tickets and user registration forms export as additional columns in the CSV. Each custom field is typed during scoping (text, dropdown, checkbox, date, numeric) and mapped to the equivalent Zendesk custom field type. Zendesk custom fields automatically generate tags for reporting; we document this behavior and configure tag-prefix naming to avoid collisions with Vision's original Labels and Tags. Custom fields that cannot be typed (long text or JSON payloads) are migrated as Zendesk text fields with a note in the migration spec.

Vision KB articles and folders export from the reporting module. We strip or preserve HTML based on whether Zendesk Guide is active on the destination account. If Guide is not active, articles migrate as Zendesk ticket comments on a designated migration article ticket. If Guide is active, we remap Vision folders to Zendesk Sections and Vision categories to Zendesk Categories. Enterprise plan customers with Guide get a 5-level article hierarchy; lower tiers get 3 levels, and we flatten Vision's deeper hierarchies accordingly during the transform step.

Vision approval records (available on Pro tiers and above) export with requester, approver, status, and timestamps. These map to Zendesk's Approval Request objects on Zendesk Enterprise with Support. On lower Zendesk tiers where approvals are not available, we migrate approval records as a custom ticket field (approval_status__c) and a linked ticket comment noting the original approver and timestamp. The customer is informed during scoping which Zendesk tier is required for native approval migration.

Vision ticket attachments export as file references. We extract the files, verify each against Zendesk's 25 MB per-attachment limit, and re-upload to Zendesk's attachment store via the Zendesk API. Files exceeding 25 MB are flagged during scoping; options include splitting into multiple smaller files, zip bundling, or linking to an external document store (SharePoint, Google Drive, S3) with a comment on the Zendesk ticket. We preserve the original filename and relink each attachment to the corresponding Zendesk ticket ID after upload.

Vision Reports are configuration objects (charts, grids, dashboards) rather than data records. They cannot be migrated programmatically. We deliver a written inventory of every Vision Report with its name, filter criteria, output columns, and schedule, mapped to a recommended Zendesk Explore equivalent. The customer's admin or a Zendesk partner recreates the reports in Explore post-migration.

Vision ticket filters and saved views export as filter configurations. We map the filter criteria to Zendesk Views with the equivalent status, assignee, and custom field conditions. Vision's advanced ticket filters (multi-criteria with AND/OR logic) are translated to Zendesk View filter syntax. Views are recreated during the configuration phase before ticket import so that agents can use them during the post-migration validation window.