When you are leaving another PSA
Switching from Autotask or HaloPSA: what moves and what does not
Years of tickets, notes and logged time sit in the system you are trying to leave. Nobody switches a service desk because the new one looks nicer. They switch when they are sure the history survives the move, and when somebody has told them plainly what does not come with it. This guide walks the switch from the outside in: what the two connectors actually read, what they deliberately never touch, the two decisions nobody can make for you, and what a parallel week looks like before you throw the one switch that ends it.
What you will have
- A record by record list of what arrives on day one, and where the two sources differ.
- A short list of what stays behind, with the reason it stays behind.
- The two things you still decide by hand: how your statuses map, and which tech is which.
- A parallel week where the old system keeps running and nothing in it is written to.
- One switch that ends the parallel run, and a clear statement of what changes the moment you throw it.
Why it works this way
While the old system is still connected, everything it sends is a copy and is treated as one. A ticket that carries an external PSA id, on an instance where a PSA is still configured, is skipped by dispatch, by the SLA clocks, by the auto-close sweeps, by the automation engine's ticket actions and by every notification. That is one condition checked at every automated door, not a switch an operator can forget.
Nothing is ever written back to the system you are leaving. The two functions that used to push a reply or a status change outward do nothing at all now, and the setting that used to turn them on is read only and always reads Off. The old system is the one being retired; it should not start receiving work from the one replacing it.
Re-running the import is safe by construction. Every record is reconciled on the id the source gave it, and the ticket thread and the time entries are guarded by real database constraints rather than by a careful loop. Run the same range twice and you get the same result, which is what lets you start with one month instead of betting the whole history on the first attempt.
Money is the one thing deliberately left behind. Imported tickets arrive with no billing status at all, and the invoicing sweep only ever looks at tickets that have one. Labour that was already billed, or already ruled non-billable, in the system you are leaving cannot be billed a second time here.
This is the part worth checking on whoever you are evaluating. Ask what an import writes into the billing tables, and ask what happens to a ticket that arrives mid-migration and is already closed. Either the answer is a design decision somebody can name, or it is a cleanup job waiting for you.
Steps
Open Integrations, then PSA, and read the two cards before you touch anything.
Both read Not Configured, and each card states in one line what its connector reads. Autotask says client records, tickets, contacts, resources. HaloPSA says client records, tickets, contacts. That line is the whole read surface, and there is no separate migration product behind it: the connector that keeps the two systems in step is the same one that moves you off the first, run with no cutoff date.
Open Integrations, then PSA, and read the two cards before you touch anything. Open the Autotask card and read what it asks for.
API User Username, API User Secret and Integration Code are the three that matter. Server Base URL and Web UI Base URL are both marked optional because the zone is discovered from the API user on the first connection, and the web address is captured then too so client records can link back. Make a dedicated API user rather than reusing a person's login: resources whose licence type is API User are dropped from the staff import on purpose, because a service account often shares a real technician's address and would overwrite that person's name.
Open the Autotask card and read what it asks for. Open the HaloPSA card and read what it asks for.
API Base URL, Client ID and Client Secret, with Tenant marked optional. Same shape, different vendor. Credentials are stored against the integration rather than in a configuration file on a server, so connecting, testing and later disconnecting are all ordinary screen actions and none of them needs a deployment.
Open the HaloPSA card and read what it asks for. Notice the three cards under the credentials, and that all three are dark.
Sync health, Status & priority mapping and Backfill historical data each read "Configure Autotask credentials first to use this section." Those three are the whole of the switch once the connection is live: the guess you review, the import you run, and the health you watch afterwards. The HaloPSA page carries the same three plus a fourth, Staff → HaloPSA Agent ID.
Notice the three cards under the credentials, and that all three are dark. Review the status and priority mapping before you import anything, and know that the two sources differ here.
On Autotask the connector reads your own status and priority picklists out of the tenant at run time and matches them to the portal's by label, then stores the result so it is not rediscovered on every restart. Status & priority mapping is where you check that guess row by row. Several source statuses are allowed to fold onto one of yours, and where nothing fits, the same panel creates a new status carrying the same governance flags the stock ones have, including whether it pauses the SLA clock. On HaloPSA that card reads "Picklist discovery is not implemented for halopsa yet.": the connector ships a default map of HaloPSA's stock status and priority ids and uses it, and an override is a stored map rather than a table you edit on screen.
Warning: An Autotask status id that did not match falls through to New, and a priority that did not match falls through to Medium. That default is deliberate, so an unknown status can never break an import or invent a closure, and it is exactly why the map is worth a pass before the first run rather than after it.Run the backfill, and start with a short range.
The card asks two things: whether to backfill, and how far back, with 1 month, 6 months, 1 year and All time. The run is two phases, organizations and then tickets, and it detaches the moment you start it, so a decade of history is not riding on a browser request that times out at ninety seconds. The card polls while it runs, shows the phase, the counts and any errors, and picks the run back up if you reload or hand the screen to somebody else. Every finished run is kept, so that card becomes your record of what was pulled and when.
Read what actually lands, record by record.
Clients arrive with their billing address, city, state, postal code, country and phone. Contacts arrive under their client; one with no email address on file still arrives, keyed on its source id, with a placeholder address on a non-deliverable domain so an accidental send fails loudly instead of quietly reaching nobody. Tickets arrive with subject, description, mapped status, mapped priority, the creator, the assignee, the original creation date and the closure date, and a closed ticket is stamped closed rather than arriving as open work. Notes and replies arrive as the ticket's thread, sanitised on the way in, each keeping the source system's own id so a second run recognises them. Time already logged on a ticket arrives as a time entry against that ticket, capped at sixteen hours per entry. Technicians arrive as people: an agent with an email address on the source system is matched to the person with that address, which is most of a shop's staff list on the first run.
Note: Four differences worth knowing. Autotask splits a ticket's activity across notes and time entries, and most of the narrative lives in the time entries, so the connector reads both and merges them into one thread; its time entries carry the hours actually worked rather than the hours adjusted for billing, and their internal notes are deliberately left behind, because tech-only commentary should not land one flag away from a client's view. The source system's ticket type arrives as a tag under a tag category named PSA Type, from Autotask only. A ticket's category and its copied-in email recipients come across from HaloPSA and not from Autotask, which holds neither on the record the connector reads.Read what does not move, and why it does not.
There is no read for agreements or contracts, invoices, products, projects, assets or configuration items, knowledge base articles, documented passwords, or SLA policies. That is not a gap in a mapper that somebody will fill in later: those methods do not exist on the connector at all, so there is nothing that half-arrives and nothing to reconcile afterwards. Sites are the near miss worth naming out loud: both connectors read a ticket's site id and site name, and the import drops them, so a client's branch offices do not arrive with its tickets. Queues and boards do not come across either. Every imported ticket lands on your default board, and board layout is yours to design rather than inherit. Documentation and passwords have their own door under Documentation, on their own schedule, and are not part of a PSA switch at all.
Expect new ticket numbers, and understand what keeps the old ones findable.
Your tickets get new numbers. The number on screen is this instance's own sequence; the source system's id is kept beside it as the external id, unique across the instance, and that is the key every re-run reconciles against instead of duplicating. Clients keep their source id the same way, and it is what a client record's link back into the old system is built from while the old system is still up. The one identifier genuinely reconciled rather than copied is your own company: every PSA carries a customer-shaped record of the MSP itself, and the import matches it on domain and links it to your own organization instead of creating a client out of you.
Note: A client whose domain is already held by another client on the instance is given a placeholder domain and logged as needing a human decision, rather than being quietly merged into a company it is not.Open any client, then its Integrations tab, and read the External PSA card.
It says what it pulls and how often: "Tickets and time entries from the configured PSA. Synced globally via cron - not per-client manual sync.", with "Schedule: Every 1 minute (tickets)". There is no per-client PSA button, on purpose. Tickets are pulled on a one minute tick against a stored cursor, so a missed tick catches up instead of dropping the change, and client records are refreshed on their own six hour cadence. That pair is what keeps a parallel week honest without anybody remembering to run anything.
Open any client, then its Integrations tab, and read the External PSA card. Run the parallel week, and let the platform refuse to act on what it does not own.
A ticket that came from the old system carries a banner at the top of its own page: "Mirrored from Autotask: this ticket is managed in Autotask until cutover; changes made here will be overwritten by sync." It informs rather than blocks. A tech can still reply or change a status, and the next tick overwrites it, because the source system is still the one holding the truth. Underneath the banner the refusal is much wider than the warning: dispatch skips those tickets, the SLA clocks skip them, the auto-close sweeps skip them, the automation engine's ticket actions skip them, and notifications about them reach nobody. That is why a ticket raised in the old system on the Wednesday of your parallel week does not page anyone here and does not get assigned twice.
Note: Tickets and replies created in the old system during the parallel week keep arriving on the one minute tick for as long as it stays connected. Nothing you do on this side reaches back the other way.Map the technicians the automatic match could not place.
On the HaloPSA page the fourth card is Staff → HaloPSA Agent ID, and it lists each team member with an editable agent id beside them; it is dark here because nothing is connected on this instance. Most of the work is already done by then, because an agent with an email address on the source system was matched to the person holding that address during the import. The list is for the remainder, and for a source system holding an agent with no email at all. An assignee the import cannot resolve leaves the ticket unassigned with the original name kept for display, which is visible and fixable, rather than being handed to whoever looked closest.
Map the technicians the automatic match could not place. Check what can be sent back to the old system: Settings, then System, then Integration Sync.
PSA Write-Back is marked "View only" and reads Off. Its own note on screen says why: "Set automatically. View only. Permanently retired - the "WE ARE THE PSA" ruling (2026-08-29) banned write-back for good, so this is always off and can no longer be turned on. A connected PSA is a read-only migration mirror; disconnect it (Admin → Integrations → PSA) when you are ready to cut over." There is nothing to configure here and nothing to get wrong. A connected PSA is read in one direction only, for as long as it is connected.
Check what can be sent back to the old system: Settings, then System, then Integration Sync. Cut over by disconnecting, and use the wizard for the settings the old system used to own.
Make ezCyber my PSA sits at the bottom of the same page and walks six keys across three sections: whether generated invoices go out on their own or wait for a human, whether an accepted quote becomes a draft invoice, whether a discount is shown as its own line, and the two proration settings that keep mid-cycle changes honest. It takes them one at a time with a recommended value for a shop making the switch, and its own advice is to keep invoice approval manual until a few cycles come out clean. The cutover itself is the disconnection, not a flag: the moment no PSA is configured, every ticket that was a read-only copy becomes an ordinary ticket, and dispatch, the SLA clocks, the automation engine and notifications arm on all of them at once. There is no second import to run and no per-ticket flag to flip.
Cut over by disconnecting, and use the wizard for the settings the old system used to own.
The pages behind each click
Other ways to do this
Preview before you import
Press Preview on the Backfill historical data card instead of Start Backfill. It counts the organizations, tickets and contacts the source holds and returns a handful of sample client and contact names, and it writes nothing.
Widen the range afterwards
Run the backfill again with a longer range. Reconciliation is on the source system's own ids, so the months you already have are updated rather than duplicated, and the ticket thread and time entries are deduplicated by database constraint rather than by hope.
If it did not work
- Tickets arrived but their client did not: a company marked inactive in the source system is skipped on purpose, and its tickets are skipped with it because the import has nowhere to place them.
- Everything arrived as New: the status map did not match your own labels. Open Status & priority mapping and set the rows by hand, then run the range again; an unmatched id reads New because the import must never guess a closure.
- Replies are there but nobody is credited on them: the source system held no email address on those agents. Map them by agent id, then ask for the historical action walk again; the reply and time entry ids are already stored, so nothing is imported a second time.
- Nothing new has arrived since the first run: the one minute tick is forward looking and reads from its own cursor. A fresh connection with no imported tickets yet only looks back twenty-four hours, so pulling the history is the backfill's job and never the tick's.
- A client arrived with a domain that looks made up: two clients wanted the same real domain, so the second kept a placeholder and the collision was written to the system log for a person to settle.
Questions this page answers
What does PSA Write-Back do?
Nothing anymore. Write-back to a connected PSA was retired for good, so this row always reads Off and cannot be turned on. ezCyber is the system of record. If you still have a PSA connected, the Make-ezCyber-my-PSA wizard at the top of this page walks you through disconnecting it, which is the step that actually finishes the cutover.
Was this helpful?