HaloPSA migration: exporting tickets, contracts and time to a unified RMM and PSA

Leaving HaloPSA for a unified RMM and PSA comes down to four exports and one rebuild: export clients and contacts, active contracts, open tickets and unbilled time entries as CSV or via the Halo API, then rebuild SLAs and workflows by hand in the new platform. Closed ticket history is usually better archived than migrated. Plan two to four weeks of preparation and one cutover weekend, timed just after you have run a billing cycle.

The onboarding fee you paid Halo is gone whichever way you decide, so it should not weigh on the choice. What matters is moving the data that earns money next month and leaving behind the configuration that only made sense inside Halo. Here is how we would do it, step by step.

Why a HaloPSA migration is mostly a PSA problem

If you run Halo alongside a separate RMM, you are really moving two things: your service desk and billing data out of Halo, and your agents out of the RMM. The agent side is well understood and covered in our guide on how to switch RMM platforms without dropping an endpoint. This article concentrates on the harder half, the PSA records.

The PSA half is harder because Halo is deeply configurable. Custom fields, ticket types, statuses, workflows and charge rates are all things you built, and none of them export as a portable recipe. Data travels. Logic does not. If you are still weighing whether to leave at all, the HaloPSA alternatives article covers that decision. Here we assume you have made it.

What to export, and in what order

Halo gives you two routes: report exports to CSV from the reporting module, and the REST API for anything larger or more structured. For most small MSPs, CSV reports are enough and far easier to sanity-check in a spreadsheet.

1. Clients, sites and contacts first. Everything else references them, so they must exist in the new system before tickets or contracts can attach. Export client name, site addresses, primary contacts, email domains and any account-manager field you use. Skip this and every later import fails on missing parents.
2. Contracts and recurring billing. Export each active contract with its client, start and end dates, billing frequency, recurring line items and quantities. Contract templates do not transfer cleanly between products, so export the values and rebuild the templates. Skip this and your first invoice run under the new system is a guess.
3. Open tickets. Export ticket number, client, contact, subject, status, priority, assigned technician, created date and the most recent notes. Keep the Halo ticket number in a reference field so clients who quote it can still be found. Skip this and someone chases an old reference that no longer exists.
4. Unbilled time entries. Export every time entry not yet invoiced: technician, ticket, client, date, duration, charge rate and billable flag. This is money, so reconcile totals per client before and after import. Skip this and you either lose revenue or bill twice.
5. Assets and configuration items, if you use them. Your new RMM will rediscover devices once the agent is installed, so only export manually maintained items such as licences, domains and line-of-business software records.

Rebuilding SLAs rather than copying them

SLAs are where Halo configuration runs deepest: response and resolution targets per priority, working-hours calendars, holiday schedules, pause-on-status rules and escalation triggers. None of that exports as something another product can read. You will rebuild it, and that is an opportunity rather than a chore.

Start by writing down what you have actually promised clients in their contracts, not what Halo is currently enforcing. These often drift apart. Then rebuild the minimum:

• Priority definitions. Three or four levels with plain descriptions your technicians agree on. If nobody can explain the difference between P2 and P3, merge them.
• Business hours and UK bank holidays. One calendar per support tier, not one per client unless contracts genuinely differ.
• Response and resolution targets. Matched to contract wording, with a clear rule on which statuses pause the clock.
• Escalations. Who is notified, and when, if a target is about to breach.

Most MSPs find they ran far more SLA variants in Halo than their contracts required, because building one was easy and deleting one felt risky. An SLA nobody can name is a timer wearing a promise's clothes.

What to archive instead of migrating

The instinct is to bring everything across. We think that instinct is wrong. Years of closed tickets, old time entries and invoiced history rarely get opened again, and importing them drags Halo-shaped categories and statuses into a system that does not need them.

Archive these, read-only, somewhere you control:

• Closed tickets older than your useful lookback, commonly twelve months. Export to CSV and keep the attachments separately.
• Invoiced time entries and invoice history. Your accounting package is the system of record for invoices anyway. Keep a CSV for audit and dispute purposes.
• Retired contracts, ex-clients and old custom fields that no current process depends on.
• Knowledge base articles that nobody has opened recently. Move the good ones by hand and let the rest go.

Check your own retention obligations under UK GDPR and any client contract terms before deleting anything from Halo. Keep the account readable until you are sure, then cancel.

What a realistic cutover weekend looks like

The weeks before are where the work happens. By Friday, agents should already be deployed alongside your old RMM, clients and contracts imported and reconciled, SLAs rebuilt and tested on dummy tickets, and technicians trained. The weekend itself is short and boring if you did that properly.

Friday afternoon

Run the final invoice batch in Halo so unbilled time is as small as possible. Tell clients that from Monday, support email and the portal point somewhere new, and that existing ticket numbers will still be honoured.

Friday evening

Stop technicians logging time in Halo. Export open tickets and the remaining unbilled time. Import both, then run the reconciliation test again.

Saturday

Switch support mailbox forwarding to the new platform and send a test ticket from an outside address for each client domain. Confirm SLAs start correctly. Decommission alerting in the old RMM only once the new monitoring policies are raising alerts, so you never have a gap.

Sunday

Leave it alone apart from on-call. Spot-check a handful of migrated tickets and contracts with fresh eyes.

Monday and the following month

Expect a few emails to land in Halo from clients replying to old threads. Forward them across for a week or two. The real proof comes at the first invoice run: compare it line by line against the last Halo invoice for each client.

The cutover weekend should be the least eventful part of the whole migration. If it is exciting, something was skipped.

Failure modes worth avoiding

• Migrating everything. Slow imports, cluttered categories and no real benefit.
• Cutting over mid-billing cycle. Time splits across two systems and someone does maths by hand.
• Copying SLAs blindly. You inherit years of drift you were trying to escape.
• Cancelling Halo too early. You lose a reference copy the week a client disputes an old invoice.

Where this fits with Helios

Helios puts monitoring, patching, remote access, ticketing, SLAs, time tracking and client billing in one product, so a Halo plus separate RMM setup becomes a single platform. Clients, contracts, tickets and time import from CSV, and Helio, the built-in AI agent, can triage the open tickets you bring across from day one. It will not rebuild your SLAs for you or decide what to archive: most of this plan is discipline, not tooling. Pricing is flat per MSP and published on our pricing page.

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