Migrate from Atomicwork to HubSpot Service Hub

Atomicwork Requests map to HubSpot Tickets. The Request status lifecycle (Open / Triaged / Assigned / In Progress / Resolved / Closed) maps to a HubSpot pipeline with matching stage names. Atomicwork's priority (Low / Medium / High / Critical) maps to HubSpot Ticket Priority. The AI-resolved versus human-resolved flag from Atomicwork's resolution_type property is preserved in a custom Ticket field aw_resolution_type__c for audit. Request category maps to Ticket Subject or a custom field.

Atomicwork Conversation threads attached to a Request migrate as HubSpot Ticket conversation entries. Agent replies, requester replies, and system notes preserve their author, timestamp, and body. The chronological order of the thread is preserved by setting the conversation timestamp on each entry. Attachment URLs migrate as references; actual file attachments require the customer to export them separately and re-attach post-migration.

Atomicwork internal agents and employee requesters map to HubSpot Users. We match by email address as the dedupe key. Internal agents with ticket assignment permissions become HubSpot Users with Service Hub seat access. Employee requesters who will not handle tickets become HubSpot Contacts rather than Users, reducing unnecessary seat consumption. Deactivated or inactive Atomicwork Users are mapped to inactive HubSpot Users with tickets reassigned to active owners.

Atomicwork CI items (Assets) migrate to a HubSpot Custom Object named CMDB_Asset__c. Asset name, type, owner, location, and relationship to Request migrate as custom fields. We pre-create the Custom Object schema including all fields before migration because HubSpot Custom Objects require Enterprise tier and schema must exist before records import. Asset Discovery scan results are NOT API-accessible from Atomicwork and must be exported manually as CSV before migration begins; we include this step in the pre-migration checklist.

Atomicwork intake forms migrate as form definitions. We export field labels, field types, and required rules via API. Form logic including conditional branching and auto-assignment rules are not fully exposed via API and must be reconstructed in HubSpot Forms manually. We deliver a Form Rebuild Checklist mapping each Atomicwork form to its HubSpot Forms equivalent with the customer completing the visual rebuild.

Atomicwork RFC (Request for Change) records with status, priority, risk level, and linked CAB approvers migrate to a HubSpot Custom Object named Change_Request__c. Approval chain and associated Request linkage migrate as custom fields and lookups. If the customer has Service Cloud Cases enabled alongside Tickets, Change Requests can alternatively be modelled as Cases with a Record Type for Change. We recommend the Custom Object approach for ITSM-specific Change workflows.

Atomicwork KB articles (title, body, category, status, tags) migrate to HubSpot Knowledge Base articles. The destination Knowledge Base must be enabled in HubSpot and a knowledge base slug created before migration. Article categories map to HubSpot article sections. Tag relationships migrate as HubSpot article topic assignments. HTML content in Atomicwork articles may require reformatting to HubSpot's article editor constraints. We preserve the original article slug in a custom field aw_article_slug__c for redirect mapping if URLs are published externally.

Labels applied to Atomicwork Requests export as a flat tag list. We map each tag to a HubSpot Ticket tag. Where tags represent categories or taxonomies used for reporting rather than simple labelling, we recommend migrating them as a multi-select picklist custom field on Ticket to support filtering and reporting in HubSpot without tag proliferation.

Atomicwork workspaces are top-level organisational containers that do not have a direct HubSpot equivalent. We map each live Atomicwork workspace to a HubSpot Team (Service Hub Professional+) or to a named Inbox for routing. Sandbox or archived workspaces are excluded from migration scope during discovery. Multi-workspace accounts with different data isolation requirements are handled as separate migration batches each targeting the corresponding HubSpot Team.

Native Atomicwork integrations with Slack, Microsoft Teams, Jira, GitHub, and other tools are configured per-account and are not API-exportable. We document every active integration connection during discovery: integration name, authentication method, trigger events, and target system. The customer's admin uses this Integration Audit document to reconfigure equivalent HubSpot integrations or third-party connectors post-migration.

Atomicwork workflow automations are not API-exportable. We document every active workflow during discovery: trigger type, conditions, and actions. This Workflow Audit document lists each automation with its recommended HubSpot Workflow equivalent (trigger type, filter criteria, enrollment action). The customer's admin rebuilds them post-migration. Workflows are out of migration scope and do not appear as migrated records.

Atomicwork dashboards and SLA analytics reports are stored as user-specific configurations and are not API-exportable. We advise the customer to document critical SLA metrics, ticket volume dashboards, and CSAT trends before migration. We do not migrate reports as data or configurations; the customer rebuilds them in HubSpot using Service Hub Analytics or exports them to a BI tool. Reports are out of migration scope.