Migrate from Atomicwork to Zoho Desk

Atomicwork Requests map to Zoho Desk Tickets. We map Request status (Open, In Progress, Resolved, Closed) to Zoho Ticket Status values, Request priority to Zoho Priority, and Request category to Zoho Ticket Category or a custom field. The AI-resolved vs human-resolved resolution flag from Atomicwork is preserved as a custom picklist field on the Zoho Ticket for SLA reporting and quality assurance. Atomicwork's Request number is stored as a custom field OriginalRequestNumber__c for audit traceability.

Atomicwork conversation threads (agent replies, requester replies, system notes) attached to a Request migrate to Zoho Ticket Comments. Each comment carries the author name, timestamp, and body text. Thread direction (incoming/outgoing) is inferred from the author (requester vs agent) and stored as a comment type indicator. We use Zoho Desk's comment API endpoint to insert threads in chronological order against the migrated Ticket ID.

Atomicwork Users (both internal agents and employee requesters) map to Zoho Desk Agents. We match by email address as the dedupe key. Agent role in Atomicwork (Admin, Agent, Requester) maps to Zoho Desk role (Support Admin, Agent, Light Agent). Inactive Atomicwork users migrate as inactive Zoho Desk agents so that historical assignee references resolve without creating orphaned tickets. We flag any Atomicwork user without a matching email in the destination for the customer's admin to provision before the agent phase runs.

Atomicwork Assets (CI items with name, type, owner, location, and Request linkage) map to Zoho Desk Assets. Asset type and ownership fields migrate directly. However, Atomicwork's Asset Discovery scan results — network-connected devices, software versions, and configuration items from Discovery runs — are not accessible via the documented API. We request a Discovery export CSV from the customer before migration begins and map the CSV fields to Zoho Desk Asset fields manually. This is a manual step that must complete before the asset phase to maintain an accurate CMDB in Zoho Desk post-migration.

Atomicwork KB articles (title, body, category, status) map to Zoho Desk Knowledge Base articles. We preserve article body as HTML content and category as the Zoho KB section. Atomicwork tag relationships migrate as Zoho Desk article tags or a custom tag field. A known limitation: Zoho Desk's native Zwitch migration tool and its assisted migration process explicitly exclude KB article attachments. We flag this and provide two paths — a manual re-upload checklist for the customer, or a custom API script to transfer attachments individually if the volume is manageable.

Atomicwork Changes (RFC records with status, priority, risk level, and CAB approvers) do not have a direct equivalent module in Zoho Desk's standard structure. We map Changes to Zoho Tasks with a custom record type ChangeRequest, preserving the risk level, priority, approval chain, and associated Request linkage. The customer may alternatively choose to map Changes to a Zoho Creator custom module if deeper Change management workflow modelling is required — this is decided during scoping.

Atomicwork intake Forms (field structure, labels, and field types) are exported via API for mapping. Conditional branching, required rules, and form logic are not fully exposed via API, so we document the form structure and recommend equivalent Zoho Desk layout and field configurations. The customer's admin rebuilds form logic in Zoho Desk's Layouts and Fields section. We provide a field-by-field map for each form during the handoff.

Atomicwork workspaces are top-level organisational containers that must map to Zoho Desk Departments. Multi-workspace accounts require us to create corresponding Departments in Zoho Desk, configure department-level SLAs, and ensure that ticket routing rules reference the correct department context. We validate during scoping which workspaces contain live data versus sandbox environments, and whether the destination Zoho Desk instance can accommodate multi-department isolation or requires a single-department flatten strategy.

Atomicwork Tags applied to Requests and Articles are exported as a flat list. We map tags to Zoho Desk Tags on Tickets and KB articles. Where the destination uses Zoho categories or taxonomies, we ask the customer to confirm the target taxonomy structure during scoping and then map source tags accordingly. Tags with no clear destination are preserved as a custom field for manual classification post-migration.

Atomicwork workflow automations (triggers, conditions, actions) are stored server-side and not exposed via API for export. This is a high-severity limitation that affects every migration from Atomicwork. We run a full workflow audit during discovery — documenting every active trigger, condition, action, and SLA escalation timer across all workspaces. This inventory is handed to the customer as a Zoho Blueprint rebuild checklist. There is no shortcut: every automation, approval routing rule, and SLA escalation timer must be manually reconstructed in Zoho Desk Blueprint and workflow rules post-migration.

Atomicwork Reports and dashboards are not API-exportable. We advise customers to document critical SLA metrics, ticket volume dashboards, and custom report configurations before migration begins. We do not migrate Reports. The customer recreates analytics in Zoho Desk's Reports module or Zoho Analytics. We provide a list of migrated data points available for reporting so the customer knows which metrics are reportable post-migration.

Native integrations with Slack, Microsoft Teams, Jira, GitHub, and other tools are configured per-account in Atomicwork and are not exported via API. We document which integrations are active during discovery and note which ones need to be reconfigured in Zoho Desk post-migration. Zoho Desk has a native Slack integration and a Teams connector, but Jira and GitHub integrations require Zoho Marketplace apps or webhook-based custom implementations.