Mapping is the real work
The most common misconception is that a migration is about moving data. It isn't. It’s about deciding how you will work in the new system.
What needs to be sorted out first: your actual agreement types with all exceptions, which price lists apply to whom, how tickets should be categorized, and which integrations need to be in place from day one.
If you skip that step, you end up moving your problems along with you instead of solving them. A migration is one of the few opportunities where it is both permissible and cost-effective to fix old structures.
What gets moved
Customers and contacts. The entire customer database, including organizational structure and contact details.
Agreements and price lists. The most sensitive part, as this is where billing is tied. Always verified manually against a sample.
Assets. Hardware, licenses, and renewal dates per customer.
Ticket history. Open tickets in their entirety, closed tickets to the extent you choose.
Knowledge base articles. Often a good opportunity to clean up – much of what is stored there was accurate three years ago.
What to leave behind
The question we get most often is how far back in time you should go. The answer is almost always shorter than you first think.
Two to three years of case history covers practically everything anyone needs to look up. Ten years of archives makes the migration more expensive, the system slower, and the search results worse.
Also leave behind: customers you no longer have, contract types you have stopped selling, and categories no one has used in years. Keep the old system in read-only mode for a period instead.
How it works
1. Mapping. We go through your business model, contract types, customer structure, and integrations.
2. Configuration. Contract models, price lists, SLAs, customer portal, workflows, and integrations with RMM and accounting systems are set up.
3. Test migration. Data is moved to a test environment first. Nothing is touched in your live production environment.
4. Verification. You check against reality – are the contracts correct, is the billing basis accurate, can the technicians find what they need? You need to set aside time for this.
5. Training. Technicians and administrators are trained before the transition, not after.
6. Live transition. Usually over a weekend. If necessary, we run in parallel for a period so that no billing falls through the cracks.
Where things usually go wrong
The contracts are not verified sufficiently. Errors in price lists are only discovered at the first billing, and then by the customer. Test against a selection of real cases before the transition.
Too much history. See above. It costs more than it's worth.
No owner on your side. Someone needs to be able to make decisions regarding the contract structure. Without that person, the project stalls while waiting for answers.
Last-minute training. A system that technicians haven't had time to learn will feel worse than the old one for two months, regardless of how good it actually is.
Why us
We have made the journey ourselves. MSP Nordics runs its entire operation in HaloPSA – service desk, contracts, time tracking, and billing.
We are the largest distributor of Halo in the Nordics and work in Swedish, Norwegian, Danish, and English in your time zone.
If you first need to determine whether you should switch, there is a comparison against ConnectWise and against Autotask. If you first want to clarify what a PSA should do, the walkthrough is available under PSA.
