How to migrate PSA/ITSM platforms without downtime
Most PSA migration plans are really data migration plans. Export the tickets, clients, and contracts out of the old platform, transform the fields, load them into the new one, sign off, go live. That part is well understood. Every PSA vendor has an import tool, most migrations use one, and the process is the same whether you’re moving from ConnectWise to HaloPSA, from Freshservice to HaloITSM, or anywhere else, and whether it’s 2,000 tickets or 200,000.
The part that goes wrong isn’t the export. It’s the ticket that’s open right now.
The gap nobody plans for
A migration isn’t a single event, it’s a window. Between the day the decision is made and the day the new platform goes live, there are usually weeks, sometimes months, where the business still has to run. Technicians keep working tickets. Customers keep emailing in. SLAs keep ticking.
The historical export handles everything closed before the cutover date. It says nothing about the ticket that was opened on Monday and won’t close until the week after go-live. During the migration window, that ticket exists in a strange in-between: still live in the old platform, expected to eventually exist in the new one, updated by whoever happens to have both tabs open.
That’s where migrations lose time. Not in the data conversion, which is a solved problem, but in the weeks either side of it where two platforms are both technically “the system” and neither one has the whole picture.
What breaks during the window
Technicians work from two screens. Anyone updating an in-flight ticket has to know which platform is authoritative today, and that answer often changes department by department during the transition.
Customers get inconsistent answers. A status update logged in the old PSA doesn’t show up if someone checks the new one, and vice versa. Whoever answers the phone is guessing which system has the current note.
Closure handling gets messy. A ticket that closes mid-migration needs its resolution code and notes to land wherever the record of truth ends up living, not wherever it happened to be sitting when someone closed it.
Nothing is complete until it’s imported twice. Teams end up manually copying updates across so the new platform doesn’t go live with a pile of stale in-flight tickets on day one, which is exactly the manual, error-prone work the migration was supposed to get rid of.
None of this shows up in a migration project plan, because a project plan is built around the data conversion. It’s the part of the process nobody sells you a tool for.
Bridge the platforms, don’t just move the data
The fix isn’t a better export. It’s keeping both platforms live and in sync for the length of the migration window, so nothing in flight has to be tracked by hand.
Support Fusion connects the old PSA and the new one directly, whether that’s ConnectWise moving to HaloPSA, Autotask moving to HaloPSA, or an ITSM-to-ITSM move like Freshservice to HaloITSM. Tickets, comments, status updates, and attachments created or changed in either platform sync to the other automatically, in both directions, for as long as the migration takes. Technicians keep working wherever they already are. Nobody has to be told which system is “real” this week, because both of them are, in real time.
Closure is handled the same way. When a ticket resolves in one platform, the resolution code and notes carry across on the platform’s own closure terms, so the record lands correctly on both sides regardless of which one it closed in first.
Once the new platform is confirmed live and every in-flight ticket has closed out, the connection comes off. There’s no code to write and no field-by-field mapping project to run first, it’s configuration, set up in hours rather than weeks, which matters because most migration windows are already tighter than anyone would like.
What the project plan looks like
At a high level, running the two problems side by side rather than one after the other looks like this:
- Scope the historical migration and set a target cutover date. Decide what moves through the vendor import tool: closed tickets, clients, contracts. This is the plan most migration projects already have.
- Connect the old and new PSA before the historical migration starts. Turn the bridge on first. From that point, anything created or updated in either platform is already visible in both, well before a single record has been converted.
- Run the historical export on its own timeline. Data conversion carries on as its own workstream, without a deadline pressuring it, because active work isn’t waiting on it to keep moving.
- Let the team move across at their own pace. There’s no mandated switch day for technicians. Some start working in the new platform immediately, others stay in the old one until the week of cutover. Both platforms stay current regardless of who’s using which.
- Confirm every in-flight ticket has closed. Before the old platform is switched off, check nothing that was open before the decision date is still open. Closure syncs both ways, so a ticket resolved in either system shows resolved in the other.
- Turn the bridge off. Once the historical data is verified and nothing active still points at the old platform, the connection comes down. No teardown project, no leftover field mappings to unwind.
Steps two and five are the ones a standard migration plan usually misses, and they’re the two that decide whether the cutover is uneventful or the source of three weeks of “which system do I check” emails.
How do you migrate tickets from one PSA to another without downtime?
By separating the two problems. Historical data - closed tickets, clients, and contracts - moves once, using the export/import tools already built for that job. Active tickets, the ones still open when the migration starts, need the old and new PSA kept in sync in real time for the length of the cutover window, so technicians and customers see the same status regardless of which platform they’re in. The migration finishes when the data conversion is done. Continuity has to hold for the whole window either side of it.
If you’re planning a PSA migration and want the in-flight tickets to be a non-issue, check your platform pairing and book a demo - we’ll walk through what a live bridge looks like for your specific stack.