Migrate from Autotask Professional Services Automation (PSA) to Intercom

Autotask Tickets map to Intercom Conversations as the primary migration object. Ticket status maps to Intercom's conversation state machine (Open, Closed, Snoozed, Resolved) — we define the status-to-state translation rule during scoping. Priority and queue assignment map to Intercom Conversation Priority and the assigned Team or Agent. Ticket-level UDFs migrate as conversation custom attributes. Attachments on tickets migrate as Intercom conversation parts (file attachments), though large attachment volumes require a separate migration phase to manage API call counts against Intercom's per-minute rate ceiling.

Autotask Contacts map to Intercom Users (if they have an email address and are active customers) or Leads (if they are anonymous visitors, unsubscribed, or do not yet have an email). The contact's parent Company reference is preserved as a custom attribute on the Intercom User or Lead, maintaining the account relationship that Autotask defines through the separate Company object. Contact-level UDFs migrate as Intercom custom attributes on the User or Lead.

Autotask Companies have no native Intercom equivalent because Intercom has no account object. We handle this in one of two ways during scoping: store company data (name, address, billing reference, account tier) as custom attributes on the primary User record, or create a separate Intercom Custom Object to represent accounts. The chosen strategy depends on whether the customer needs to query across multiple contacts by company in Intercom's reporting. We pre-create any custom attribute definitions in Intercom before the data load phase begins.

Autotask Resources (technicians and staff) map to Intercom Team Members. Resource role (admin, technician, manager) maps to Intercom's admin or agent role. Department and license status are stored as custom attributes on the Team Member record. Availability and assignment rules that exist in Autotask have no direct Intercom equivalent — we document these as configuration recommendations for the customer's admin to implement in Intercom's inbox routing and assignment rules after migration.

Autotask Projects (with tasks, milestone dates, resource assignments, and budget tracking) have no native Intercom object. Projects, project phases, and project-level UDFs are flagged during discovery and excluded from the migration scope. We deliver a project archive export (CSV or JSON) that the customer can store in a document repository or migrate to a separate project management tool. This gap must be acknowledged explicitly before migration begins.

Autotask Contracts (with billing arrangements, labor rates, service level terms, and recurring billing rules) have no native Intercom object. Contract data is flagged during discovery and excluded from the migration scope. We deliver a contract archive export (CSV or JSON) and document any SLA terms as custom attributes on the relevant User or Lead record if the customer wants contract context visible in Intercom. This gap must be acknowledged explicitly before migration begins.

Autotask Time Entries (linked to Tickets, Projects, or standalone work) have no Intercom destination. Time-entry data is excluded from the migration scope. We deliver a time-entry archive export (CSV or JSON) with parent object references preserved so that historical billing can be audited. Customers who need to retain time-entry context for billing reconciliation export this to a spreadsheet or a dedicated time-tracking tool. This gap must be acknowledged explicitly before migration begins.

Autotask Ticket UDFs (text, number, date, dropdown, checkbox) map to Intercom Conversation custom attributes. We enumerate every UDF on the Ticket object during discovery, capture its data type and picklist values, and create matching custom attribute definitions in Intercom before the data load. Any UDFs without a matching Intercom attribute type are flagged and resolved during the schema design phase. Ticket UDFs without a valid Intercom destination are documented for manual post-migration entry.

Autotask Contact UDFs map to Intercom custom attributes on the corresponding User or Lead record. The same discovery process applies: enumerate UDFs per object, capture types and picklist values, create matching Intercom attribute definitions, and flag any without a valid destination. Contact UDFs that reference parent Company data may require additional attribute creation on the account strategy chosen in object 3.

Autotask Ticket queues map to Intercom Teams with corresponding Inbox routing. Each Autotask queue assignment becomes an Intercom Team and an Inbox with routing rules configured to direct conversations by topic, priority, or source. Queue-based SLA rules require reconstruction in Intercom as SLA rules attached to the relevant Team or conversation tag. This is configuration work rather than a data migration and is implemented during the Intercom setup phase.

Autotask ticket status values (New, In Progress, Waiting, Resolved, Closed) map to Intercom conversation states (Open, Closed, Snoozed, Resolved). We define the mapping table during discovery and apply it as a field transform during the data load. Any custom status values are mapped to a closest-match Intercom state and flagged for the customer's admin to review. Status change timestamps migrate as conversation part timestamps for timeline integrity.