Switching your PSA is a big, disruptive decision, and it can be the best decision you make, if it’s done correctly. Before you move, be honest about why you’re switching — and understand that it is never a simple lift-and-shift. Your data, your contracts and even the way you work will have to change. This is how to think it through properly before you commit.
First, ask yourself: why switch?
Whenever an MSP tells me they want to switch PSA, my first question is always the same: why? Not to be difficult, but because the honest answer usually decides everything.
I’ve watched a lot of MSPs chop and change PSA tools over the years, forever chasing something “better”, and the pattern is almost always the same. They pick a tool, never set it up properly, get frustrated, and decide that the tool is rubbish. A few months later, once they’ve switched, they’re right back in the same place — because the thing that was actually broken came with them: the setup, the processes and the decision-making behind them.
So before anything else, ask yourself a question: is it really the tool, or is it how the tool has been set up? If you’ve only ever used your current PSA as a glorified service desk — never billed properly from it, never entered your costs, never got to grips with contracts — then you haven’t really given it a fair go, and switching won’t fix that. Sometimes the honest answer is: don’t switch, fix what you’ve got. I’d rather tell you that than sell you a migration you didn’t need.
But let’s assume you’ve been honest with yourself and moving still looks like the right option. Here are the considerations that really matter — the ones I get asked about again and again.
Never bring your ex into a new relationship
This is one of my favourite sayings, and anyone who knows me will have heard me say it hundreds of times — and it’s the single most important mindset to get right before you switch: never bring your ex into a new relationship.
What I mean is this. When people move PSA, the instinct is to bring everything with them — all the data, and every process, exactly as it was. “I did it this way in my old PSA, so I want to do it the same way in the new one.” That instinct is the thing that holds up many migrations — and sometimes stalls them permanently.
The two tools are not the same. They do things differently, and often the new tool has a better way of doing something — but you’ll never benefit from it if you insist on recreating your old habits. Before you switch, you have to be genuinely open to three things:
- Process changes — the way you did something in the old tool may not be the best way in the new one.
- Data changes — you almost certainly shouldn’t bring all of it, and some of it won’t come across cleanly anyway.
- Fundamentally different ways of doing things — some core concepts simply work differently, and you’ll need to learn the new way rather than force the old one.
If you go into this with a closed mindset, you’ll spend a fortune rebuilding your old frustrations in a shiny new interface. If you go in with an open mind, migration becomes a genuine upgrade.
What do you do with all your tickets?
This is probably the question I hear most often. Most MSPs have years and years of tickets, and the worry is always: do I bring all of these into the new PSA? A subset? If a subset, how far back do I go?
My honest answer is: it depends — on two things. First, what that data actually is. Second, how old it is.
Here’s the reality most people don’t want to hear: there’s very little point dragging in tickets that are two, three or four years old, because you’ll almost certainly never look at them. Be honest — how often do you reference an old ticket (of say three or four years old) in your current system? For most MSPs, I bet that happens so rarely. The data’s old, the information’s often out of date, and it just clutters the new system.
So my usual recommendation is to bring in no more than about a year’s worth of tickets. Anything older than that, you’re probably not referencing, and it’s probably no longer relevant. Less really is more.
Keep a read-only copy — and a single licence
“But what if I do need something from further back?” — a good question, and there’s a good answer.
Before you switch off your old system, do two things. First, take a read-only copy of the database. Both Autotask and Halo can give you a read-only copy, and it means everything you didn’t migrate is still there if you ever genuinely need it. Second, keep a single-user licence of the old tool for a while. Between the two, you’ve got a safety net: you can reference the old stuff any time, without bloating your new PSA with years of dead data.
It’s a small ongoing cost that buys you a lot of peace of mind — and, as you’ll see, it solves another problem too.
Not everything comes across — even with the built-in migration tools
This is a big one, and it catches people out. When you move from, say, Autotask to Halo, the built-in migration tool does not bring everything over. Things like opportunities, quotes and projects don’t come across.
That matters, because those are important — that’s your sales pipeline and your project history. So part of planning a switch is deciding how you get that data out and where it goes. This is exactly where that read-only database copy and single-user licence earn their keep: they give you a way to get at the information that the native tool leaves behind.
For what it’s worth, I do have some tools of my own that can help pull that data out and bring it across during a migration — but even with those, the key point stands: don’t assume the built-in migration handles everything, because it doesn’t. Know what’s coming, what isn’t, and what your plan is for the gap before you commit.
Contracts are not a lift-and-shift
One thing I always beat the drum about is this: contracts are fundamentally different between the two systems.
A contract in Autotask is not the same as a contract in Halo. They’re built on different concepts and they behave differently. In particular, Halo bills using something called Billing Rules, which is a genuinely different way of thinking about billing from how Autotask does it — and it trips up a lot of people coming from Autotask.
So your contracts cannot simply be copied over. They have to be rebuilt, deliberately, with an understanding of how the new system actually wants to bill. This is where the real work — and the real risk to your revenue — sits in any migration. If you rush it or assume it’ll “just come across”, your first billing run on the new system will fail and you will learn the hard way.
Don’t forget the true cost of switching
None of the above is a reason not to switch — but it should tell you that a migration isn’t a licence swap, it’s a project. You’ll be running two systems in parallel for a while, rebuilding contracts and billing, deciding what data to bring, learning new ways of working, and babysitting your first few billing runs. Budget the time and focus for it, and don’t kick it off in your busiest period or right before year-end. I’ve seen this all too often: MSPs want a migration done quickly, and it normally ends up going horribly wrong.
And protect your profitability setup while you’re at it: fully burdened engineer costs, cost prices on products and services, and your contract exclusions don’t magically appear in the new tool. Re-enter them, or your shiny new PSA will happily report that every client is 100% profitable — lovely for the ego, useless for the business.
When switching is the right call
Plenty of the time, moving is exactly right — you’ve outgrown the tool, you need something it genuinely can’t do, or the new platform simply fits your business better. When that’s the case, a well-planned switch will land you somewhere much better. The point of this article isn’t “never switch”. It’s “switch deliberately, with your eyes open, ready to do things differently”.
The best way to de-risk the whole decision is to get an honest, independent view before you commit — ideally from someone who works across both platforms and has no reason to push you either way. They can tell you whether it’s the tool or the setup, what will and won’t migrate, and what the move will really involve.
Decided you’re going ahead? Read our practical guide next: HaloPSA & Autotask Migration Services.
