Migrate from Atomicwork to Zendesk

Atomicwork Request maps directly to Zendesk Ticket. The Request status lifecycle (Open, In Progress, Pending, Resolved, Closed) maps to Zendesk Ticket Status with a custom field at_request_status__c preserving the original atomicwork status for audit. Priority and category map to Zendesk Priority and Tags respectively. The AI-resolved versus human-resolved flag is not native to Zendesk; we store it in a custom field at_resolution_type__c on the Ticket. Conversation threads from the Request detail view migrate as Ticket Comments with public/private distinction preserved via Zendesk's comment.author_type or channel attributes.

Atomicwork internal agents map to Zendesk Agent accounts. We resolve by email match against the Zendesk user table. Agent role (Tier 1 support, Tier 2 support, IT manager) maps to Zendesk Agent role (Agent, Admin) with the team assignment preserved in Groups. Any Atomicwork agent without a matching Zendesk account enters a reconciliation queue for the customer's admin to provision before record migration continues.

Atomicwork employee requesters map to Zendesk End Users. Name, email, and department migrate directly. Inactive or deactivated Atomicwork users are set to suspended in Zendesk rather than deleted, preserving historical requester linkage. Department information maps to a custom user field at_department__c if the customer's Zendesk plan supports custom user fields.

Atomicwork Assets (CI items linked to Requests) map to Zendesk Assets. We map asset name, type, owner, location, and the relationship to the originating Request by linking the Zendesk Asset to the migrated Ticket via a custom relationship field or by attaching the Asset URL as a Ticket comment. Asset Discovery scan results are not accessible via Atomicwork API and require a manual CSV export from the customer before migration; we ingest this CSV and map it to Zendesk Assets as a separate pre-migration step.

Atomicwork intake form field definitions (labels, field types, required flags) are exported via API and used to configure Zendesk Ticket Fields in the target account before Request migration begins. Conditional branching and required-rule logic are not fully exposed via the Atomicwork API, so we document the visible form structure and advise the customer to rebuild equivalent conditional logic in Zendesk's own field configuration. We do not migrate form logic as executable code.

Atomicwork Knowledge Articles (title, body, category, status, and article-to-category assignments) migrate to Zendesk Guide Articles within their corresponding Sections. We export articles in bulk, map the Atomicwork category hierarchy to Zendesk Guide Sections and Categories, and ingest via the Zendesk Help Center API. Article deduplication is a known risk: migration tools that do not validate by article title can create duplicates. We use title dedupe keys before insert to prevent duplicate articles. Tags from Atomicwork map to Zendesk Article labels.

Atomicwork Changes (RFC records with status, priority, risk level, and CAB approvers) do not have a direct Zendesk equivalent object. Standard Changes with simple approval routing map to Zendesk Macros applied manually by agents. Complex Changes with formal CAB approval chains and risk scoring map to Zendesk SLA Policies with custom Ticket fields for risk level and approval status. The mapping is determined during discovery by reviewing the Change record complexity across the source account.

Atomicwork Request conversation threads (agent replies, requester replies, and system notes) migrate as Zendesk Ticket Comments preserving the original timestamp and author. We distinguish internal notes from public replies using the Atomicwork conversation visibility attribute, mapping internal notes to Zendesk private comments (comment.public = false). Attachment URLs are migrated as references; large binary attachments may require re-upload via Zendesk's attachment API. The chronological ordering of the thread is preserved by setting comment.created_at to the original Atomicwork timestamp.

Atomicwork Tags applied to Requests and Articles migrate as Zendesk Tags on the corresponding Ticket or Article record. We export the tag list as a flat set and insert via Zendesk's tag API. Tags used for content classification on Articles map to Zendesk Article labels. The customer selects tag strategy during scoping if there is ambiguity between tagging for ticket organisation versus article categorisation.

Atomicwork workspaces are top-level organisational containers that may represent separate business units. Zendesk does not have a direct workspace equivalent at the Suite tier. During scoping we determine whether to flatten workspaces into Zendesk Groups (suitable for most ITSM use cases) or to use Zendesk multi-org if the customer has a Suite Enterprise account requiring full data separation. Workspace isolation requirements are confirmed before migration begins; failing to scope this correctly results in Requests being imported into the wrong organisational context.

Atomicwork Workflows (triggers, conditions, and actions built in the visual builder) are not API-exportable and do not migrate. We run a full workflow audit during discovery, documenting every active trigger, condition, and action across all workspaces. This inventory is handed to the customer as a rebuild checklist mapped to Zendesk equivalents: Atomicwork event-based triggers map to Zendesk Triggers; conditional routing rules map to Zendesk Macros; SLA escalation timers map to Zendesk SLA Policies. The customer's admin or a Zendesk partner rebuilds these post-migration.