Introduction

Migrating your PSA is one of the most disruptive projects an MSP can undertake. Everything your business runs on — tickets, contracts, billing, client history — lives inside that system. Get the migration wrong and you're looking at lost data, billing errors, and weeks of your team working around a broken setup.

The good news: migrating from Autotask to HaloPSA is absolutely doable, and in most cases the end result is worth the short-term disruption. HaloPSA's modern automation engine, cleaner interface, and all-inclusive pricing make it a genuinely better fit for most growing MSPs.

The bad news: it's not as simple as exporting a CSV and pressing import. The native migration tools have real limitations, some Autotask concepts don't map cleanly to HaloPSA, and certain things — automations, notification templates, complex contract types — will need to be rebuilt from scratch.

I've completed this migration with MSP clients and this guide reflects what actually happens in the real world, not what the marketing materials suggest.

Before You Start

The biggest mistake MSPs make is treating a PSA migration as a technical project. It's not — it's a business transformation project that happens to involve technology. Before you touch a single export or import, you need to answer three questions.

Do you have an internal PSA owner?

Someone on your team needs to own this migration end to end. Not just the technical setup, but the workflow decisions, the team communication, and the post-go-live troubleshooting. Without a named owner, migrations drift — timelines slip, decisions get deferred, and the whole project stalls halfway through.

Have you audited your current Autotask setup?

Before migrating anything, document what you actually have. Pull a list of all your active contracts, billing rules, workflow automations, and notification templates. You'll quickly discover that some of them are outdated, redundant, or no longer relevant. A migration is the best opportunity you'll ever have to clean house — don't just replicate your Autotask setup in HaloPSA, improve it.

Do you have a parallel operation plan?

You cannot cut over to HaloPSA on a Monday morning and hope for the best. Plan for a parallel operation period — typically 2 to 4 weeks — where both systems run simultaneously. This gives your team time to get comfortable with HaloPSA before Autotask is switched off, and gives you a safety net if something doesn't migrate correctly.

What HaloPSA's Native Migration Tool Can Do — And What It Can't

HaloPSA provides a built-in import tool that handles the most common migration scenarios via CSV. It covers clients and contacts, assets, tickets and ticket history, and time entries. For a straightforward migration, this gets you most of the way there.

However, the native tool has hard limits that you need to know about before you start.

What it can import:

• Clients and Contacts
• Employees
• Products and Services
• Billing Codes
• Assets
• Tickets
• Basic contract structures

What it cannot do:

• Migrate workflow automations — every automation rule you have in Autotask needs to be manually recreated in HaloPSA from scratch
• Migrate notification templates — all your email templates, acknowledgement messages, and SLA notifications need to be rebuilt
• Fully replicate complex contract types — some Autotask contract structures don't have a direct equivalent in HaloPSA and require a different approach

This last point is the one that catches most MSPs off guard. If you're expecting a like-for-like migration of your billing setup, you'll be disappointed. Plan for reconstruction, not replication.

The Critical Part: Contracts & Billing

This is where migrations succeed or fail. Everything else can be fixed after go-live — a billing error that goes unnoticed for three months cannot.

Autotask has one of the most mature billing engines in the PSA market, built up over two decades. It handles a wide range of contract types and billing scenarios with a level of granularity that reflects years of MSP feedback. The problem is that this complexity doesn't always translate cleanly into HaloPSA's contract model.

Here's what you need to do before migrating any billing data:

Map every active contract type you have in Autotask

Sit down with your billing admin and list every contract type currently in use — recurring fixed fee, time & materials, block hours, per-device, per-user, managed service agreements. For each one, identify the closest equivalent in HaloPSA and document any gaps.

Identify your edge cases

The standard contract types migrate reasonably well. It's the exceptions — multi-tier pricing, custom billing rules, contracts with legacy structures that have been patched over the years — that cause problems. These need to be handled individually, not as part of a bulk import.

Validate billing output before go-live

Before you switch off Autotask, run a parallel billing cycle in HaloPSA for at least one full billing period. Compare the output line by line. Any discrepancy needs to be resolved before cutover — not after.

Don't migrate services you're about to retire

A migration is the perfect moment to clean up your service portfolio. If a service is no longer actively used or is being phased out, don't migrate it. Start HaloPSA clean.

One important advantage of HaloPSA's billing model: the ability to sync subscription and license quantities automatically via native integrations with platforms like Pax8, Giacom, and Microsoft CSP. If you're currently updating these quantities manually in Autotask, the migration is a good opportunity to set this up properly in HaloPSA from day one.

What You'll Need to Rebuild from Scratch

Be honest with yourself about this section. These items are not migrated by any tool — they need to be rebuilt manually in HaloPSA, and they take time.

Workflow automations

Every automation rule in Autotask — ticket routing, escalation rules, SLA triggers, recurring task creation — needs to be rebuilt in HaloPSA. The good news is that HaloPSA's automation engine is more powerful and flexible than Autotask's, so in many cases you can rebuild a cleaner, more efficient version of what you had. The bad news is that if you have dozens of automation rules, this is weeks of work.

Use the migration as an opportunity to audit your automations. In most Autotask environments I've seen, a significant portion of automation rules are outdated, redundant, or actively causing problems. Don't rebuild what doesn't need to exist.

Notification templates

Every email template — ticket acknowledgements, SLA breach notifications, client updates, engineer assignments — needs to be created from scratch in HaloPSA. HaloPSA's templating system is flexible and supports AI-generated acknowledgements, but the initial setup takes time. Prioritise the templates your clients see first.

Contract types that don't map cleanly

Some Autotask contract structures simply don't have a direct equivalent in HaloPSA. This doesn't mean they can't be replicated — it means they need to be rethought. In some cases the HaloPSA equivalent is actually better. In others, you'll need to make a conscious decision to change how you bill for a particular service. Either way, this needs to happen before go-live, not after.

Integrations

Every third-party integration — your RMM, accounting software, documentation tool, security vendors — needs to be reconfigured in HaloPSA. The integrations themselves are generally straightforward to set up, but testing each one properly takes time. Build integration testing into your migration timeline, not as an afterthought.

User roles and permissions

HaloPSA's permission model is different from Autotask's. Don't assume roles will map across. Define your permission structure from scratch based on how your team actually works, rather than trying to replicate what you had.

Go-Live Checklist

Before you switch off Autotask, work through this checklist. Every item should be green before cutover.

• All active clients and contacts imported and verified
• All active assets imported and assigned correctly
• Open tickets migrated and assigned to the correct queues and engineers
• All active contracts configured and billing output validated against Autotask
• Subscription integrations (Pax8, Giacom, Microsoft CSP) configured and tested
• RMM integration configured and alert-to-ticket automation tested
• Accounting integration configured and test invoice generated
• All priority notification templates created and tested
• Core workflow automations rebuilt and tested end to end
• User roles and permissions configured and reviewed with team leads
• Client portal tested from a client perspective
• Parallel billing cycle completed and output verified
• Team training completed — every engineer has logged in and handled at least one ticket

Don't treat this as a box-ticking exercise. Each item on this list represents a category of things that can go wrong after go-live. The goal is to have no surprises on cutover day.

Realistic Timeline

The most common question I get is: how long will this take? The honest answer is longer than you think, and the reasons are almost always the same — contracts are more complex than expected, automations take longer to rebuild, or the parallel testing phase reveals issues that need to be resolved before cutover.

Here's a realistic timeline for a mid-sized MSP with 10-30 technicians:

Weeks 1-2: Audit and planning

Document your current Autotask setup. Map contract types to HaloPSA equivalents. Identify edge cases. Define your permission structure. Don't touch HaloPSA yet — this phase is about understanding what you have before you start rebuilding it.

Weeks 3-4: HaloPSA foundation

Configure the core platform — clients, contacts, ticket types, queues, SLA policies, user roles. Get your team logging into HaloPSA and familiarising themselves with the interface. Import assets.

Weeks 5-6: Billing and integrations

Configure contracts. Set up integrations — RMM, accounting, subscription platforms. Run a test billing cycle. This is the most time-consuming phase and the one most likely to overrun.

Weeks 7-8: Automations and templates

Rebuild workflow automations. Create notification templates. Test end-to-end workflows. This phase often reveals gaps in the platform configuration that need to be addressed before go-live.

Weeks 9-10: Parallel operation and cutover

Run both systems simultaneously. Migrate open tickets. Complete the go-live checklist. Cut over when every item is green.

For smaller MSPs with simpler setups, this can be compressed to 6 weeks. For larger MSPs with complex billing structures and many automation rules, allow 12 weeks or more.

Not Sure Where to Start?

Migrating from Autotask to HaloPSA is a significant project — but it's one we've done before. At Kinesys, we manage the entire migration process: auditing your current setup, mapping your contracts, rebuilding your automations, and ensuring your billing output is correct before you go live.

If you're considering the move or already in the planning stages, we offer a free initial consultation with no commitment.

→ Book your free consultation

kinesys.it • info@kinesys.it • HaloPSA Official Partner & Autotask Experts