Migrate from Wolken Service Desk to Intercom

Wolken Requests map to Intercom Conversations. The Request status (open, in-progress, resolved, closed) maps to Intercom's Conversation state (open, resolved, closed). Wolken's sub-status and priority (low, medium, high, critical) migrate as custom attributes on the Conversation for filtering and routing. Request title becomes Conversation subject; Request description and thread history become the Conversation message sequence. Wolken's assigned agent maps to the Intercom assignee on the Conversation.

Wolken Customer records map to Intercom Contacts. The Customer name, email, phone, and company fields map directly to Intercom Contact standard fields. Wolken's Customer custom fields migrate as Intercom custom attributes on the Contact. We resolve the email address as the dedupe key during import. If a Wolken Customer has multiple associated Requests, all conversations attach to the same Contact in Intercom.

Wolken Agent profiles (name, email, role, team assignment) map to Intercom Admins and Operators. We match by email and import Agent records before Request migration so that the assignee references resolve at import time. Wolken's agent role hierarchy (admin, agent, viewer) maps to Intercom's admin and operator roles. Team assignments from Wolken map to Intercom Teams if the customer uses the Teams feature.

Wolken SLA Policy definitions (response time, resolution time per priority and category) are exported as configuration documentation. Intercom's SLA rules operate at the inbox level with first response and next response targets rather than per-category SLA policies. We document the Wolken SLA structure in a written handoff so the customer's Intercom admin can configure equivalent SLA rules in Intercom's SLA settings. We do not create enforceable SLA rules in Intercom because the data model differs significantly.

Wolken attachments are referenced per Request but require individual resolution via ID because Wolken exposes no bulk blob-export endpoint. We resolve each attachment URL, download the binary, and upload it to Intercom via the Conversations API attachment endpoint during import. For migrations with thousands of attachments, this extends the timeline significantly. We pre-scan all attachment references during scoping, estimate per-file resolution time, and include the attachment resolution phase in the project timeline.

Wolken's Request Metadata API exposes dynamic custom fields defined per Request type. We export the full metadata schema and map custom field values to Intercom custom attributes on the Contact (for customer-level metadata) or as conversation attributes (for Request-level metadata). Intercom's custom attribute types (string, number, boolean, date, list) must be matched to the Wolken field type during scoping. We flag any Wolken field types without a clean Intercom equivalent (such as multi-select or structured objects) for customer decision on how to represent them.

Wolken published knowledge base articles map to Intercom Help Center articles. We export article title, body content, author, publication status, and category. Wolken category hierarchy maps to Intercom Collections and Sections. Publication status translates: Wolken published maps to published in Intercom, Wolken draft maps to draft. Article permissions (internal vs customer-facing) do not have a direct Intercom equivalent and are documented for the customer to set during Help Center configuration.

Wolken Forms act as structured intake channels that route submissions to specific Request types. We export Form definitions and field structures. The routing logic tied to Forms (which form routes to which Request type) does not migrate as executable rules because Intercom handles intake differently. We document the form-to-Request-type routing as a written handoff for the customer's admin to rebuild using Intercom's operator rules and saved replies. The form field structures map to Intercom Custom Attributes on the Contact created from the form submission.

Wolken Request categories (incident, service request, change request, problem) map to Intercom Tags on the Conversation. We import the category name as a tag and attach it to the corresponding Conversation during migration. Tag taxonomy from Wolken becomes the initial tag set in Intercom, which the customer's admin can extend or consolidate post-migration.

Wolken maintains a Customer/Contact database that may include company-level records. If the Wolken migration includes company data, we map it to Intercom's Company object (available on the Growth and up plans). Company name, domain, and custom fields migrate directly. Intercom's Company object allows linking multiple Contacts to the same Company, enabling account-level context in conversations. If the customer is on Intercom Starter or below, company-level data migrates as a custom attribute on the Contact.