Migrate your Atomicwork data

The primary ticket object. Requests have a status lifecycle, priority, category, requester, and assignee. Atomicwork tracks whether a Request was resolved by an AI agent or a human agent — we preserve this as a custom field on the destination. Request conversations (comments, attachments) are migrated as threaded entries.

Atomicwork Users include both internal agents and employee requesters. We map Users to the destination's user/agent object, preserving name, email, role, and department. Inactive or deactivated users are flagged for the customer to decide whether to include or skip them.

CI items linked to Requests. We migrate Asset name, type, owner, location, and relationship to Requests. Asset Discovery records are not API-exportable; we handle these by requesting a manual export or CSV from the customer before migration.

Intake forms and their field structure. We export form definitions and field labels, but form logic (conditional branching, required rules) is not fully exposed via API. We rebuild equivalent forms on the destination and note any field-level mapping changes.

RFC (Request for Change) records with status, priority, risk level, and linked CAB approvers. We migrate Changes with their approval chain and associated Request linkage.

KB articles used by the AI agent for deflection. We export title, body, category, and status. Tag relationships and article-to-category assignments require field-level mapping because the destination may use a different taxonomy model.

Workflow automations (triggers, conditions, actions) are built in Atomicwork's visual builder but are not exposed via API for export. We document every active workflow during discovery and rebuild equivalent automations on the destination platform post-migration.

Atomicwork workspaces are top-level organisational containers for Requests, Assets, Users, and workflows. Multi-workspace accounts require us to map each workspace to an equivalent entity on the destination — either a separate instance, a department group, or a tag-based filter. Workspace-level permissions must be explicitly confirmed before migration scoping.

Comments and internal notes attached to a Request. We preserve the full conversation thread including agent replies, requester replies, and system notes. Attachment URLs are migrated as references; we flag any attachments that require re-upload to the destination's storage.

Labels applied to Requests and Articles. We export tags as a flat list and map them to the destination's tagging system. Where the destination uses categories or taxonomies instead, we ask the customer to define the mapping.

Dashboards and analytics reports are stored as user-specific configurations and are not API-exportable. We advise customers to document critical SLA metrics and custom reports before migration so they can be rebuilt on the destination.

Native integrations with Slack, Microsoft Teams, Jira, GitHub, and other tools are configured per-account and are not exported via API. We document integration connections during discovery and note which ones require reconfiguration on the destination.