Autotask PSA Migration
Import your data from Autotask PSA into Ascent so you can switch without re-keying your customers, contacts, and history. The migration is read-only and one-directional — nothing is ever written back to your Autotask tenant.
The migration imports your Companies, Contacts, Resources (technicians), Tickets, ticket notes, time entries, configuration items (assets), contracts and their services (line items), projects and tasks — including each record's Autotask user-defined fields. You can optionally also bring across ticket attachments, run a dry run to preview a migration without writing anything, and run a delta cut-over that only pulls records changed since a chosen time.
Who can run a migration
Running a migration is available to the organization Owner and Admins
by default. Because it is controlled by a dedicated migrations permission, you
can also create a custom role that grants migration access to specific people
and withhold it from other admins. It handles raw source credentials and
bulk-creates records, so grant access deliberately.
Before you start
Create an API-only user in Autotask (Admin → Resources/Users → an API User (API-only) security level) and note its three credentials:
- API User (UserName)
- API Secret
- API Integration Code (the tracking identifier for your integration)
Autotask uses no OAuth or SSO for the REST API — these three values are all that is required.
Connecting and running
- Go to Admin → Autotask Migration.
- Enter the API User, Secret, and Integration Code.
- Click Test connection. Ascent automatically discovers your Autotask zone and runs an authenticated probe. A clear error is shown if the credentials are rejected.
- Click Create migration. Your credentials are validated and stored encrypted at rest; they are never shown again or written to logs.
- Press Start. The import runs in the background and you can watch per-entity progress (pulled / loaded / skipped / failed).
Migration options
When you create a migration you can set three optional switches:
- Include attachments — also migrate your ticket attachments. This runs as a final pass on a separate, slower rate limit (attachments are large), so the bulk transfer can never push your tenant over its Autotask API threshold. Each attachment is downloaded once and linked to its imported ticket; a re-run does not re-download attachments it already brought across.
- Dry run — a preview. The migration reads your Autotask data, stages it, and produces the full report (per-entity counts and any unmapped picklist values) without writing a single record to Ascent. Use it to see what a real run would do before committing. Attachments are never pulled in a dry run.
- Delta cut-over — changed since — leave blank for a full import, or pick a date/time to only pull records that changed in Autotask since then. Because the import is idempotent, a delta run updates the records you already imported and adds only genuinely new ones — ideal for a final catch-up just before you go live on Ascent.
Exporting the run report
From any run that has started, use CSV or JSON to download its report — per-entity counts plus the unmapped / skipped / failed log — for your records or to review which picklist values still need attention.
How it works
- Zone discovery — the correct Autotask zone URL is resolved automatically; no zone is hardcoded.
- Throttling — every call goes through a single conservative rate limiter
that stays well under Autotask's per-hour threshold and backs off on
429, so a migration can never suspend your live Autotask tenant's API access. - Idempotent — each Autotask record is matched to its Ascent record by source id. Re-running a migration updates existing records instead of creating duplicates.
- Resumable — progress is checkpointed per entity. If a run is interrupted, starting it again continues from the last checkpoint rather than restarting.
- Reported — each run produces per-entity counts plus a log of skips, unmapped picklist values, and any records that failed (with the raw payload retained for review).
What is mapped
| Autotask | Ascent | Notes |
|---|---|---|
| Companies | Clients | companyType maps to client type; unknown values are flagged for review and default to Customer. Inactive companies import as Inactive. |
| Contacts | Contacts | Linked to their imported company. A contact whose company was not imported is skipped and logged. |
| Resources (technicians) | Users | Active staff only — API-only and inactive resources are skipped. Imported resources become disabled, login-less placeholder accounts that exist to own ticket/time history; a resource whose email matches someone already in your organization is linked to that person instead of being duplicated. |
| Tickets | Tickets | Linked to their imported client (a ticket with no imported client is skipped), contact, and assigned technician. Ticket priority, status, queue and source are translated from your Autotask picklists. |
| Ticket notes | Ticket notes | Imported as internal notes on the matching ticket, preserving the author and the original timestamp. |
| Time entries | Time entries | Linked to their ticket and technician, with hours, billable flag, date and rate preserved. An entry whose technician was not imported is skipped and logged. |
| Configuration items | Assets | Linked to their imported client where possible (an item whose company was not imported still imports, just without a client). The Autotask CI type is tenant-defined, so it imports as Other and is flagged in the report for you to reclassify. Serial number and name are preserved. |
| Contracts | Contracts | Linked to their imported client (a contract with no imported client is skipped). The Autotask contract type (Block Hours, Time & Materials, …) is preserved as a label. A contract with no dates defaults its term so the import never fails. |
| Contract services | Contract line items | Linked to their imported contract (skipped if the contract was not imported), with quantity, unit price and computed amount. |
| Projects | Projects | Linked to their imported client (skipped if the client was not imported) and to a project manager where the lead resource was imported. Status, dates and estimated hours are preserved. |
| Tasks | Project tasks | Linked to their imported project (skipped if the project was not imported) and to an assignee where the resource was imported. Status and estimated time are preserved. |
| Ticket attachments (opt-in) | Ticket attachments | Only when Include attachments is on. Each file is stored in Ascent and linked to its imported ticket; an attachment whose ticket was not imported is skipped. |
Each imported configuration item, contract, contract line item, project and task also carries its Autotask user-defined fields, stored alongside the record so none of your custom data is lost.
Your Autotask priority / status / queue / source picklists are customizable, so they are translated using sensible defaults. Ticket statuses and queues match your Ascent statuses and categories by name. Any value that has no mapping is surfaced in the run report for you to review rather than being dropped or silently defaulted — so after a run, check the report for unmapped entries and adjust your Ascent statuses/categories (or your expectations) accordingly.
Cleaning up
Deleting a migration run removes its staging data, id map, logs and the stored encrypted credentials — use it once a migration is complete.