Migrate from Autotask Professional Services Automation (PSA) to Salesforce Service Cloud

Autotask Tickets map to Salesforce Cases. We pre-configure Case Record Types to mirror Autotask queue structures, and Case Status values correspond to Autotask Ticket status values. The Autotask Ticket ID is preserved in a custom field at_original_id__c for audit and cross-reference. Custom Ticket Fields (UDFs) are enumerated during the UDF audit phase, typed (text, number, date, checkbox, dropdown), and created as Salesforce custom fields before Case import begins. Attachment handling is phased separately due to Autotask's per-attachment API requirement and the 10,000/hour call ceiling.

Autotask Company records map to Salesforce Account. The Company name becomes Account Name; physical address maps to BillingAddress; the Company phone becomes Account Phone. Autotask Company UDFs migrate to Account custom fields. We load Accounts first in the dependency order because every Contact requires an AccountId lookup. The Autotask Company ID is preserved in at_original_id__c.

Autotask Contacts map to Salesforce Contacts with the parent AccountId resolved at migration time from the Company-to-Account mapping. FirstName, LastName, Email, Phone, and Title migrate directly. Contact-level UDFs require a matching Salesforce custom field on Contact. We preserve the Contact-to-Company linkage by ensuring Account load completes before Contact insert, avoiding orphaned Contact records.

Autotask Projects have no direct Salesforce Service Cloud equivalent. Service Cloud is a service desk platform, not a PSA. If the customer's migration scope includes project management, we create a custom Project__c object in Salesforce with fields for Project Name, Status, StartDate, EndDate, Budget, and Resource (lookup to User). Autotask Tasks within Projects map to Task records linked to Project__c via WhatId. For customers not migrating projects, we flag the gap in the scope document and recommend Certinia (FinancialForce PSA) as a Salesforce-native PSA add-on.

Autotask Contracts with labor rates, service terms, and billing rules map to Salesforce Contract if the destination org includes the Contract object (available from Professional). Contract start date, end date, billing terms, and annual value migrate as fields. Complex rule-based billing configurations (Autotask billing rules) cannot be replicated in Salesforce without custom development or a billing integration; we document the billing rule logic in the migration handoff for the customer's admin and ERP team to address.

Autotask Time Entries have no native Salesforce equivalent. We map them to Task records with the Type field set to 'Time Entry' and custom fields capturing hours (Task.DurationInMinutes mapped from Autotask hours), billing status, and the parent reference (WhatId pointing to the related Ticket/Case or Project__c). Alternatively, for customers with strict billing reporting requirements, we create a custom Time_Entry__c object with hours, date, owner, and parent lookup fields. The mapping strategy is chosen during scoping based on the customer's reporting and billing integration needs.

Autotask Resources (technicians and staff) map to Salesforce Users. We match by email address. Any Autotask Resource without a matching Salesforce User is held in a reconciliation queue; the customer's Salesforce admin provisions missing Users (active or inactive based on current employment status) before record migration resumes. Role, department, and license status from Autotask Resource are preserved in custom User fields.

Autotask UDFs exist per-customer per-object and are not discoverable via a bulk export. Before migration, we run a UDF audit enumerating every custom field on Tickets, Companies, Contacts, Projects, Contracts, and Time Entries. We capture the field label, API name, data type (text, number, date, checkbox, dropdown), and any picklist values. Each UDF is created as a matching Salesforce custom field (with __c suffix) before data load begins. Any UDF without a clear Salesforce equivalent is flagged as a gap requiring manual post-migration data entry or custom development.

Autotask documents attached to Tickets, Projects, and Contracts are retrieved via sequential per-attachment API calls. Because of Autotask's 10,000 calls/hour ceiling, we phase attachment migration separately in an off-peak window after primary record migration completes. Each attachment is uploaded as a Salesforce ContentVersion and linked via ContentDocumentLink to the parent Case, Account, or custom Project__c record. We pre-count total attachment volume during scoping to estimate the attachment migration window.

Autotask Service Calls (field service scheduling and dispatch) have no documented export path in the REST API. We do not migrate Service Call records. If the destination Salesforce org includes Field Service Lightning, we recommend mapping Service Calls to Work Orders or Service Appointments and rebuilding the dispatch data manually. This is scoped explicitly out of the migration with a gap note in the handoff document.

Autotask To-dos are individual action items tied to users rather than tickets or projects and lack a bulk export endpoint. We do not migrate To-dos as records. If the customer requires To-do migration, we recommend converting them to Salesforce Task records manually post-migration or using a third-party migration tool. This gap is documented in the scope.