PSA Migration guide
PSA Migration
Plan a PSA migration with verified vendor tools, source exports, destination imports, mapping, pilot validation, cutover and retained history.
On this page
Plan the move as a sequence of verified workflows
A PSA migration joins source export, destination import, mapping, validation and cutover. Begin with the destination’s official named importer or migration service, then collect the source records it requires. Give the historical archive its own owner and acceptance check.
Choose a documented migration route
| Source → destination | Tool ownership | Guide |
|---|---|---|
| Autotask PSA → HaloPSA | Halo-maintained named importer | Autotask to HaloPSA |
| Autotask PSA → Syncro | Syncro-maintained named importer | Autotask to Syncro |
| ConnectWise PSA → Syncro | Syncro-maintained named importer | ConnectWise to Syncro |
| Atera → Syncro | Syncro-maintained named importer | Atera to Syncro |
| Freshdesk → Zoho Desk | Zoho-maintained Zwitch workflow | Freshdesk to Zoho Desk |
Each direction has its own evidence and prerequisites. For other destinations, consult the import pillar. Officially listed third-party migration services belong in a separate ownership category from vendor-maintained tools.
Inventory the source and choose what moves
Agree on active work, historical work and archive-only material. Include customers, sites, contacts, technicians, tickets, replies, internal notes, attachments, statuses, priorities, tags, custom fields, time, service history and relevant finance records. Add knowledge-base articles and embedded images to the checklist.
For every group, assign an export method, destination method, acceptance rule and owner. Capture source totals and the account’s time zone. Use the vendor export guides for extraction details so the migration plan stays focused on coordination.
Map relationships and preserve identity
Create customer and user maps before tickets and conversations. Record destination IDs as they are created. Define a searchable legacy-ticket identifier and a policy for inactive staff. Review how contracts, invoices and time entries connect to customers and tickets, particularly where one platform combines concepts another separates.
Obtain explicit answers for original timestamps, note visibility, attachments and status transformations. For instance, a source status called Closed may need a different destination value to count as resolved. Preserve the source label in the archive when a transformation is necessary.
Use a pilot as the cutover gate
Include a multi-site customer, a long thread, an internal note, an inactive agent, a file, a custom field and relevant finance records. Have service staff locate the same work in both systems. Reconcile parent counts, child counts, file readability, permissions, hours and totals.
Record accepted exceptions and repair paths. Establish how retries match existing records and how a failed batch is handled. Approve the pilot before committing to a cancellation date.
Schedule the final-change window
Agree when the old system stops receiving new work and when inbound mail, portals, integrations and automations switch. If the chosen tool documents a delta pass, identify the exact records it updates. Otherwise arrange a controlled final export or a vendor-agreed reconciliation process.
Retain source access through validation. Record the last successful export, import job and comparison results. Give staff the source-to-destination ID crosswalk and the archive location before reopening normal intake.
Separate history from configuration
Assign a separate owner to routing, email channels, automations, roles and reporting configuration. A successful ticket migration proves only the selected record workflow. Test new ticket intake, requester visibility and billing handoffs before the service team begins using the destination.
Keep useful history available afterward
Store original exports, file manifests, mappings and signed-off exceptions together. Test the archive with a real service question, such as finding the earlier agreement or the private note explaining a resolution. Set access and retention responsibilities and use the migration archive use case to plan the handover.
Additional destination-owned routes
| Source or requirement | Destination workflow | Preparation guides |
|---|---|---|
| ConnectWise PSA → Autotask | Vendor-assisted migration with an implementation checklist | ConnectWise exports and Autotask imports |
| Kaseya BMS → Autotask | Vendor upgrade route with object-specific scope | BMS exports and Autotask imports |
| Historical tickets → Atera | Atera Professional Services ticket/comment files | Source exports and Atera imports |
| Zendesk → Zoho Desk | Zoho Zwitch using three source ZIP packages | Zendesk exports and Zoho Desk imports |
| Freshdesk → Halo | Shared Halo migration guide; verify the module in the HaloPSA tenant | Freshdesk exports and HaloPSA imports |
These directions have different transfer rules. Use the linked guides for ownership, prerequisites and archive decisions before choosing a service or preparing a file.
Preserve history through a platform change
Keep old service conversations accessible after cutover. Join the waitlist for invitation-only BackupPSA access.