Migrate from Wolken Service Desk to Zendesk

Wolken Requests map directly to Zendesk Tickets. We map Request.status (open, in-progress, resolved, closed) to Zendesk Ticket status (open, pending, hold, solved, closed), with sub-status values preserved in a custom field wolkensubstatus__c for audit. Request.priority maps to Zendesk priority (low, normal, high, urgent). The Request subject becomes Ticket subject; the Request description and internal notes become Ticket comments. Wolken's Request Metadata API custom fields map to Zendesk custom fields by field ID, with type conversion (Wolken dropdown to Zendesk dropdown, checkbox to checkbox). We pre-scan the full Request metadata schema during discovery to build the typed field map before any data moves.

Wolken Customers are the central contact repository and map to Zendesk Users (end-users who submit tickets) and optionally to Zendesk Organizations (company-level grouping). We determine the mapping strategy during scoping based on whether Wolken Customers represent individual requesters or organizational entities. If Wolken stores company-level Customers, we map them to Zendesk Organizations; individual requesters map to Zendesk Users with an OrganizationId reference. Email address is the primary dedupe key. Name format (first/last vs full name) is normalized during extraction.

Wolken Agent records (name, email, role, team assignment) map to Zendesk Agent user accounts. We resolve by email match during migration. If a Wolken Agent email has no corresponding Zendesk user, we hold the record in a reconciliation queue for the customer to provision the Zendesk account first, since OwnerId is required on Ticket creation. Team structures and role hierarchies from Wolken do not map directly to Zendesk Groups and Agent Roles; we flag these as configuration items requiring manual setup in Zendesk Admin after migration.

Wolken SLA Policy definitions (response and resolution time windows per priority or category) map to Zendesk SLA Policies, which are configured in Zendesk Admin under Business Rules. We export the SLA Policy metadata including name, first response time, next resolution time, and business hours assignment, then deliver a written SLA configuration map specifying which Zendesk SLA Policy to create, which SLAs to assign to which Views, and how the Wolken priority-to-Zendesk-priority mapping drives SLA eligibility. SLA policies do not migrate as active enforcement records because Zendesk SLA Policies are evaluated at ticket creation time against current business hours, not retroactively applied to historical tickets.

Wolken published knowledge base articles map to Zendesk Guide Articles. We map article title, body (rich text), author, publication status, and tags. Wolken category hierarchy maps to Zendesk Guide section and category structure. Note that Zendesk Guide must be activated by the account owner before articles can be imported; we flag this in the pre-migration checklist. Permissions, translations, and user segment restrictions from Wolken articles map to Zendesk article permissions and content tags where the destination schema supports them; any Wolken-specific permission model that Zendesk does not replicate is documented as a gap in the handoff report.

Wolken Forms act as structured intake channels that route submissions to specific Request types. We export Form definitions and field structures as a written inventory. The routing logic tied to Forms (which Form submission triggers which Request type and category) does not migrate as automation because it is Wolken-specific. We deliver a form-field mapping document showing each Wolken Form field and its equivalent Zendesk ticket field or custom field so that the customer can rebuild intake forms in Zendesk or a third-party form tool. Zendesk's native form builder or Formstack integration is the recommended replacement path.

Wolken stores attachment references linked to individual Requests but exposes no bulk blob-export endpoint. Each attachment must be resolved individually by its reference URL during migration. We pre-scan all attachment references during scoping, estimate the per-file resolution time based on file size sampling, and factor the total attachment count into the timeline and price estimate. Large attachment volumes significantly extend the export phase. We download each attachment, validate it, then upload to Zendesk via the attachment API, linking it to the corresponding Ticket comment. Attachments without a valid parent Request in the migration set are flagged as orphaned and documented separately.

Wolken's Request Metadata API exposes dynamic custom fields defined per Request type. We export the full metadata schema (field name, type, options for dropdowns) and map each to a Zendesk custom field of the equivalent type. During discovery we enumerate all distinct Request types and their associated custom field sets to identify overlaps and conflicts in the Zendesk destination schema. Some Wolken custom field types may require Zendesk custom field type approximation (e.g., a Wolken multi-select without a Zendesk multi-select equivalent may map to tags or a text field); we document each approximation in the field mapping sheet during scoping.

Wolken team structures and agent team assignments do not map directly to Zendesk Groups because the two platforms use different permission models for team-scoped routing. We export team membership per Agent as a written mapping (Agent email to team name) and deliver it with the configuration handoff. Zendesk Groups are created manually in Admin, and routing rules are rebuilt using Zendesk's Trigger and Automation builders post-migration. This is flagged as a configuration rebuild item rather than a data migration item.

Wolken Request comments (internal notes and public replies from agents and requesters) map to Zendesk Ticket Comments. We preserve is_public flag from Wolken as public vs private comments in Zendesk, and preserve the original timestamp on each comment for full conversation history integrity. Comment author maps to the Zendesk Agent or end-user by email match. Comments without a resolvable author are assigned to a default agent and documented in the reconciliation report.