Migrating from Datto Autotask PSA: exporting tickets, contracts and time entries without losing a billing cycle

Leaving Autotask is mostly a billing problem disguised as a data problem. A clean Autotask migration moves four things live, namely accounts, active contracts, open tickets and unbilled time, archives everything else in a searchable export, and runs one billing cycle in parallel so no invoice is missed. The tickets get the attention. The unbilled time is what costs money. Here is the runbook, record by record.

The four records that cause real pain

Autotask holds years of history, and almost none of it needs to be live in your new platform on day one. Four record types do, because mishandling them hits revenue or SLAs directly, whether the machines you look after belong to clients or to your own company.

• Accounts and contacts. Everything else hangs off these. Export them with their source IDs and parent organisation or site, because every ticket, contract and time entry you import later needs something to attach to. Skip the IDs and you will be matching "Smith & Co Ltd" to "Smith and Co" by hand at midnight.
• Active contracts. Customer, contract or plan IDs, effective dates and renewal terms. A contract that arrives without its renewal date is a renewal you will notice only when the client does.
• Open tickets. Status, requester, dates, custom fields and the full note history. Your users do not care which PSA you use; they care that the technician picking up their ticket knows what was already tried.
• Unbilled time. Technician, linked ticket or customer, work date, duration and billable status. This is the record most often lost, because it looks like history but is actually money not yet invoiced.

That list matches the inventory backuppsa.com recommends for a usable export: tickets and notes with source ticket ID, client, status, dates and custom fields; companies and contacts with source IDs and parent organisation; time entries with technician ID, ticket link, work date, duration units and billable status; and contracts with customer and plan IDs, effective dates and renewal terms.

Getting data out of Autotask: three routes

The native export

Autotask's built-in route is Export > In Import Template Format from each search screen: Service Desk > Search > Tickets for tickets, and CRM > Search > Contacts or Organizations for CRM records. Billing records use a separate XML or CSV export workflow. The native route is free and adequate for accounts and contacts. It is clumsy for ticket notes and time, because you end up stitching several CSVs together on ticket ID.

The REST API

For anything beyond a small estate, the API is the better tool. Autotask provides its APIs free of charge as part of the licence, which matters: you are paying for that access until you cancel, so use it before you do. Authentication is three static headers (the API username, the secret and an ApiIntegrationCode) with no OAuth 2.0, and API credentials are separate from SSO, according to Stitchflow. Create a dedicated API user early rather than discovering in week three that nobody has one.

Two caveats. Datto PSA reserves the right to change the API or suspend access under significant server load, so pull in batches overnight and log what succeeded. And if an inherited export script still uses the legacy SOAP API, check the End of Life timeline published in the AutotaskDevelopment Sample-Code repository before trusting it. An old script that fails silently is a guess wearing a backup's clothes.

Third-party migration tools

Paid services handle the stitching for you. Help Desk Migration advertises no-code transfer of contacts, companies, agents and tickets, mapping agents to resources (including tickets owned by deleted or inactive agents), and merging several Autotask accounts into one target. That last feature is genuinely useful if acquisitions left you with more than one instance. Check what the tool supports on the target side before you pay, and note that contracts and unbilled time usually need separate handling.

Sequencing an Autotask migration so no billing cycle is lost

The order matters more than the tooling. This is the sequence that protects revenue.

1. Pick a cutover date just after an invoice run. You want the smallest possible pile of unbilled time on the day you switch. Skip this and you migrate a month of half-billed entries mid-cycle.
2. Export and import accounts first. Rebuild contracts in the new platform against those accounts and check each one's value, start date and renewal date against Autotask, line by line.
3. Freeze ticket creation in Autotask at cutover. Point the support mailbox and portal at the new system. Move open tickets with notes; leave closed ones for the archive.
4. Bill the final Autotask period from Autotask. Time logged before cutover gets invoiced from the old system, as it always would have been.
5. Bill the first new period from the new platform, then reconcile. Compare each client's invoice with the equivalent Autotask invoice. Differences usually mean a contract was rebuilt wrongly, not that the client used more or less.
6. Cancel only after the reconciliation passes.

The two-invoice test: for every client, the last Autotask invoice and the first new one should differ only by genuine changes in usage. Anything else is a mapping error to fix before the next run.

If you are moving accounting sync at the same time, it is worth reading our notes on PSA billing that syncs to Xero and QuickBooks, because duplicate customers in the accounts package are the classic side effect.

What to archive, and how

Closed tickets, old time entries, expired contracts and historical invoices rarely need to be live, but you will need them for disputes, audits and the occasional "what did you do to that server in 2022" call. Export them in full, store them as CSV alongside a readable format such as PDF or a simple database, and keep the source IDs intact so records still link. Decide retention in line with your own data protection obligations before cancelling, not after.

An archive you cannot search is a loft full of unlabelled boxes.

If you are leaving Datto RMM and backup too

Many MSPs exit Autotask and Datto RMM together. Do the agent swap separately, using our guide to leaving Datto RMM, so a PSA problem and an endpoint problem never land in the same week. The backup stack needs its own deadline: Datto Continuity says devices keep backing up for a 30-day grace period after cancellation and local data is retained indefinitely, but Datto reserves the right to delete offsite cloud data after 60 days unless a copy is requested in that window. Put that date in the project plan in red.

Where this fits with Helios

Most of this runbook is discipline, not tooling, and no platform removes the need to reconcile contracts by hand. Helios gives you one place to land the result: monitoring, patching, a helpdesk with SLA clocks, contracts, time tracking and billing into Xero or QuickBooks in a single product, so the PSA and RMM halves of a Datto exit end up together rather than in two more tools. It is priced by fleet size rather than per technician, with every feature on every plan, and the pricing page sets out the numbers. There is a 14 days free trial with no card, which is enough time to import a sample of accounts and test the reconciliation step before you commit.

Common questions about Autotask migration

How long does an Autotask migration take?

An Autotask migration for a small MSP is usually governed by billing cycles rather than data volume. Allow time to export and rebuild contracts before cutover, then at least one full invoice period of parallel reconciliation after it. Running the cutover just after an invoice run and cancelling only once the reconciliation passes keeps the timeline honest.

Can I export Autotask ticket notes as well as tickets?

Autotask ticket notes can be exported, but the native Export > In Import Template Format route tends to produce separate files that need joining on ticket ID. The REST API or a third-party migration service is usually a better route for ticket notes, because it keeps each note attached to its parent ticket and preserves dates and authors.

Should I migrate closed Autotask tickets or archive them?

Closed Autotask tickets are usually better archived than migrated. Importing years of closed history slows the cutover and clutters the new helpdesk for little benefit. Export closed tickets in full with their source IDs, keep them in a searchable format, and migrate only open tickets and any recent history technicians genuinely refer to.

Researched and written with Helio SEO, our AI writer for business blogs.