Data Migration for Managed Service Providers: Your PSA, Not Your Clients'
Search "data migration for managed service providers" and you'll find article after article about moving client mailboxes into Microsoft 365.
This page covers your PSA, your tickets, your service desk: the system you run your business on. As an MSP, that data belongs to dozens, sometimes hundreds, of clients at once, so per-client isolation, billing continuity, and a quiet cutover matter more here than anywhere else. See how industry-specific migration planning works, then apply it to an MSP PSA migration, where the stakes are sharper.
No credit card required Fast setup
Trusted by 60,000+ companies
Data Migration Types: What Moves in a PSA Migration
A PSA switch is not a ticket migration with extra steps. Under the hood, a single ticket links to boards, queues, custom fields, SLA policies, and configurations that all have to survive the move too. Here is the fuller scope, help desk data first, in the order most MSPs work through it:
| Record set | What it includes | What to watch in a move | Per-client isolation note |
|---|---|---|---|
| Help desk and PSA tickets | Cases, tickets, ticket threads, boards, queues, statuses, tags, custom fields | Board and queue structures rarely match one to one between platforms | Tickets need to retain the correct company or client relationship |
| Time entries and contracts | Time logs, contract records, configurations, billing references | Billing state typically does not travel with the record, see below | Contract terms stay specific to one client and do not merge across clients |
| Knowledge base | Articles, categories, per-client versus internal visibility, article attachments | Visibility settings need a decision, not just a mapping rule | Shared articles need an explicit decision about which clients can access them |
| Client and contact data | Companies, contacts, sites, organisation hierarchy, agent and group structure | This is the backbone the rest of the migration keys off | Where isolation succeeds or fails first |
| Media and attachments | Inline images, file attachments, size and retention limits | Target size limits can be tighter than the source's | Attachments inherit isolation from the ticket or record they belong to |
| Email history | Inbound and outbound threads tied to tickets, header preservation | Header preservation varies a lot by platform pair | Threads stay isolated as long as the parent ticket does |
| Call logs and recordings | Telephony records and recording links attached to tickets | Recording links sometimes point to a third-party system that moves separately | Same dependency as attachments |
That is seven record sets, not one. Tickets are the anchor: they're the biggest pile, and it's easy to mistake a PSA switch for a ticket migration. But each of the other six record sets carries its own per-client isolation to protect while it moves. Time entries and contracts carry financial weight that tickets don't. Client data is the backbone everything else keys off. Even something as ordinary as attachments and call logs inherit their isolation from whichever ticket or record they're tied to. None of them are optional just because nobody mentioned them first.
What actually transfers depends on what your source platform will release and what your target platform knows how to catch. Treat this table as a scoping document you assess before you commit to one.
Supported Migration Platforms for MSP Companies
Accelo
Atera
Atlas
Autotask PSA
BMCHelixITSM
BoldDesk
Chatwoot
ConnectWise
Crisp
CSV
Custify
Deskpro
DevRev
Dixa
Document360
Drift
Dynamics 365
eDesk
eGain
Enchant
Forumbee
FreeScout
Freshchat
Freshdesk
Freshservice
Front
FyneDesk
Gladly
Glassix
Gleap
GLPI
Gmail
Google Docs
Gorgias
Groove
Halo Service Solutions
HappyFox
Harmony
HelpCrunch
HelpDesk
HelpDocs
Helpjuice
Help Scout
HelpShift
HelpSpot
HubSpot Service Hub
InstantDocs
Intercom
Ivanti
Jira Service Management
Jitbit HelpDesk
Kayako
Kayako Classic
KnowledgeOwl
Kundo
Kustomer
Lansweeper
Live Agent
LiveChat
Manage Engine
Mayday
Missive
NinjaOne
Odoo Helpdesk
Oracle Service Cloud (RightNow)
osTicket
((OTRS)) Community Edition
Outlook
Paligo
Plain
Planhat
Pylon
Reamaze
Request Tracker
Respond.io
Richpanel
Salesforce Service Cloud
ServiceDesk Plus
ServiceNow
SherpaDesk
Siit
SmarterTrack
SolarWinds Service Desk
SolarWinds Web Help Desk
SparrowDesk
Spiceworks
Spiceworks Cloud
SQLite
SuperOps
SupportBee
SupportPal
Syncro
SysAid
SysAid (Cloud)
Tawk.to
TeamSupport
TeamworkDesk
Thena
Thulium
Tidio
TOPdesk
Trengo
Unthread
Vitally
Vivantio
Zammad
Zendesk
Znuny
Zoho Desk
Zoho Mail
Check the name for typos or leave us a message.
Why Per-Client Isolation Is the Real Requirement, Not Ticket Count
Isolation is not a feature you can simply turn on. It depends on how the data is mapped and checked during the migration. This is what makes MSP help desk migration different from a single-tenant project: the data belongs to multiple clients, so mapping and validation need to happen for each client, not once for the whole dataset.
That single fact adds more time to a project than record volume ever does. A migration involving 40 clients with moderate data volumes can take more time to scope and validate than a single-client migration with many more records. Each client needs its own mapping review and validation before cutover.
Isolation is not something a platform hands you for free. It comes from decisions made during mapping, and it gets confirmed through per-client validation before cutover, not assumed just because both platforms slap the word “multi-tenant” on their marketing pages.
What deliberate mapping looks like in Autotask PSA
So what does "built deliberately" actually look like? In Autotask PSA, every contact has to link to a company. No workaround. Standalone contacts in your source system get assigned to a company during mapping, not left to sort themselves out.
Autotask PSA also won't let you change a contact's company after it's created, which is exactly why a demo migration to check company assignment matters more here, particularly if you're merging accounts.
On the reporting side, validation runs through the Migration Wizard's live dashboard, tracking tickets, agents, contacts, and companies as separate entities while the transfer happens, and closing with a report on what moved, what didn't, and why. None of that is automatic. It's a mapping rule and a dashboard someone actually reads, which is a smaller claim than "isolation is built in," and a truer one.
What per-client mapping looks like: Migration from ConnectWise
Take ConnectWise PSA as a concrete example. Every ticket, contact, and configuration record in ConnectWise migration rolls up to a company, and a company splits into sites for clients running more than one location. During a migration, those relationships need to be mapped correctly for each client.
This becomes more important when the source platform has several clients grouped under one shared company record. That's a problem to solve before the migration starts, not while it's running. No tool separates commingled client data on its own; that takes a person, a decision, and deliberate mapping. The same discipline applies to data migration for IT service companies more broadly; isolation isn't unique to MSPs, it's just higher-stakes here.
One more myth worth killing: multi-tenancy is a product feature, not a migration outcome. A platform being multi-tenant means it can hold separate clients without them seeing each other while it's running. It says nothing about whether records land in the right place during a migration between two multi-tenant platforms. That's the gap where vendor claims get loose. If someone's selling you a migration, ask them which side of that gap they mean.
Validate each client before cutover
In practice, per-client validation before cutover means checking each client's mapped records on their own, not sampling the aggregate:
For an MSP with a handful of clients, that check moves fast. For one with dozens or hundreds, it's the part of the project that eats the calendar, more than moving the data itself.
A good tip to follow is to validate each client separately before cutover. If something fails, you can roll back that client's migration without affecting clients that have already passed validation. This keeps issues isolated and makes the overall migration easier to control.
Security and compliance questions come up early for MSPs evaluating a migration partner, and they should. Read Help Desk Migration's security policy alongside whatever isolation approach a vendor proposes for your specific migration.
The PSA Records That Come with a Price Tag Attached
MSP help desk migration doesn't stop at tickets. A PSA holds time entries and contract records right alongside tickets, and those two categories carry a financial weight that tickets simply don’t. Lose track of a ticket's history, and you've got a service headache. Lose track of a time entry's billing state, and three weeks after cutover you're staring at a chunk of last month's billable hours that never moved as billable. Any MSP owner will tell you those are not the same fire drill.
| Record type | Moves directly | Needs mapping | Has billing consequence |
|---|---|---|---|
| Tickets | Yes | Field-level, usually straightforward | No |
| Time entries | As records | Yes, structure varies by pair | Yes |
| Contracts | Partially | See placeholder below | Yes |
| Configurations | Partially | Depends on asset model | Sometimes |
| Companies | Yes | Isolation-critical, see above | No |
| Contacts | Yes | Tied to company mapping | No |
| Sites | Yes | Tied to company mapping | No |
| SLA policies | Rarely one to one | Usually rebuilt, not moved | No |
| Custom fields | No | Manual setup on target | Sometimes |
| Attachments | Yes | Size and retention limits vary | No |
Time Entries vs. Billing State
Time entries usually migrate as records, but not as billing state, and the reason is structural: invoicing status typically lives in a platform's financial layer, not on the ticket or the time entry itself. Autotask PSA makes the point well. A time entry logged against a ticket needs approval and posting before it turns into a billable line. What was done and how long it took, that migrates with the record just fine. Whether someone already approved, posted, or invoiced it, that’s a separate question.
One that usually gets reconciled in the target platform's own billing workflow rather than carried across automatically.
Wizard Options & Platform Nuance
Help Desk Migration lists "Migrate Time Entries" as a named, selectable option in the Migration Wizard, described as moving the records agents use to log time against tickets. That's a real, supported option, not a custom work special request. What the published description doesn't spell out is whether approval, posted, or invoiced status transfers with it for your specific pair of platforms.
That's an honest gap in what's public, so treat the general billing-state behavior above as solid and the pair-specific flag question as one to ask your migration specialist directly.
Contracts as Custom Objects
Contracts get the same treatment. Neither ConnectWise PSA's nor Autotask PSA's published field list includes contracts as a standard record type. ConnectWise PSA's documented fields cover members, contacts, companies, and tickets. Autotask PSA's cover agents, companies, contacts, and tickets. Contracts fall under Custom Objects migration instead, the same bucket as assets and warranties, handled through Professional Services rather than the standard field-mapping flow.
In short: contracts don't ride along with your ticket migration by default. Budget for them as their own scoped project.
Company-to-Contact Structure
Help Desk Migration moves ticket and contact records between PSA platforms, preserving the company-to-contact structure that keeps each client's records separate, and treats reconciling billing state as its own distinct step from moving the underlying records. If your evaluation depends on exact billing-flag behavior for your specific pair, that is worth confirming directly before scoping.
See the Autotask PSA data import for the platform-specific detail.
DIY, Managed, or Custom: How to Pick Your Migration for Managed Service Providers
Three ways to get help desk migration for MSP operations done, and which one fits you depends on client count more than record volume:
Migration Wizard, self-service
Good fit if you're a small MSP, a handful of clients, moving one well-supported platform pair with no complicated per-client mapping in the mix. You scope the fields, run a test migration, review it, then run the full migration yourself.
Managed Service
The default for most MSP projects, because per-client mapping across dozens or hundreds of clients is a conversation, not a checklist you fill out alone. This is Help Desk Migration's managed migration service: we scope the project with you, build the mapping, run a test migration for review, then handle the migration.
Consultancy
For the messier ones: unusual source data, custom objects, several source platforms to consolidate at once, or a sequencing problem alongside a separate client-side project.
Native PSA importers deserve real credit here. Most PSA platforms have a CSV or native import tool, and for a clean, well-scoped dataset from a single source, that tool handles the job just fine. So where does a managed migration service actually earn its keep? At the edges a native importer wasn't built for: per-client mapping at scale, billing-record reconciliation across platforms with different financial models, and validation that checks each client's data on its own instead of sampling the aggregate and calling it good.
Picture two MSPs side by side. One runs two clients and a modest ticket volume on well-documented platforms with mapping that's close to one to one. Self-service is a fine call there. The other runs 50 clients, and its total record count might look smaller on paper than the two-client MSP's. That doesn't matter. 50 clients means 50 mappings and 50 validations, because that work scales with client count, not row count, and it doesn't shrink the way a single-tenant migration's effort does when volume drops.
No API on your source at all? That changes the scoping conversation from day one. Some older or heavily customized PSA setups only export by CSV, which is workable, but it shifts how much of the project you can automate vs. how much gets mapped by hand.
For a platform-specific version of this, Halo Service Solutions migration and ConnectWise to Freshdesk migration cover two of the pairs MSPs move between the most.
Cutting Over Leaving No Visible Service Gap
Cutover is where help desk migration for MSP operations gets real: you can't take a maintenance window your clients will notice.
That one constraint is why cutover looks like a parallel operation instead of a single flip-the-switch moment: both platforms stay live for a stretch after the main migration runs, and a Delta migration moves anything created or updated in that window: new tickets, replies, time entries, before you retire the source for good.
Running two platforms live at once has a consequence worth planning for on purpose: agents working tickets on both systems during the overlap, and a numbering scheme that has to make sense across both. That's a decision made ahead, not a detail sorted out on cutover day.
Two decisions specifically, both scheduled before cutover starts
First, ticket numbering: can the target platform keep the source's numbering, or does it start its own sequence?
This genuinely depends on where you're headed. Autotask PSA's documented ticket fields list both ID and Ticket number as separate fields, so the source number has somewhere to land. ConnectWise PSA's documented fields list ID, but not a separate ticket-number field, which means it arrives as a value rather than necessarily reproducing ConnectWise's own sequence. If your clients notice ticket numbers, confirm this specifically for your target before you scope the project. The platform you're leaving is not a reliable predictor of the one you're headed to.
Second: when does the client-facing portal switch over? That's a smaller question with a bigger consequence than it sounds like. Clients have that URL bookmarked and have logged in through it more times than anyone has counted. Scheduling that switch as an afterthought, once the data's already moved, is exactly how a technically clean migration turns into a bad client experience.
There's no such thing as a zero-downtime PSA migration, and anybody telling you otherwise is selling, not describing. What's realistic, in Help Desk Migration's experience, is a near-zero visible impact for the client, and how close you get depends on client count, portal configuration, and how your target platform handles ticket numbering. An MSP whose clients only ever submit by email usually has an easier cutover than one running a heavily used client portal. One less system to switch over live, one less thing that can go sideways.
What MSP Migration Actually Costs and How Long It Takes
MSP data migration pricing follows a different logic than a single-tenant project, and the same question comes first: what's this going to cost, and how long before I'm out the other side? Fair question. Here's what actually moves the number:
Client count is the variable that sets an MSP project apart from a single-tenant one, and it often matters more to cost and timeline than raw record volume does. A low-volume migration spread across 40 clients can end up costing more and taking longer than a high-volume migration for one company, because mapping and validation scale with client count, not row count. Time-entry and contract depth compound that: a PSA with several contract types and detailed per-client billing rules takes longer to map than one running a simple flat structure, regardless of ticket volume.
Whether your source has an API changes cost and timeline directly, too. API access generally means a more automated path. CSV-only or heavily customized sources usually mean more manual mapping before the migration even starts. Help Desk Migration's migration pricing reflects those variables, not a flat per-record number.
Let's put real figures on this instead of talking in circles. Help Desk Migration prices by record count, and the pricing isn't linear: the more you migrate, the less you pay per record. On the Standard plan with no customization, a 1,000-record migration runs $100. A 10,000-record migration runs $514. The math favors volume, which is exactly why 40 small per-client migrations don't get the same economics as one large single-tenant one.
Service packages scale with complexity: Standard covers a one-time hard-switch migration, Premium handles up to 50,000 records with dedicated support, and Signature and Enterprise add Delta migration, interval migration, multi-thread migration, and a dedicated account team for the bigger, multi-client projects.
None of this replaces an actual quote. Help Desk Migration only puts a firm price on paper after a free demo migration confirms what you're actually working with.
Estimate your migration cost for a starting point based on your own client count and platforms, especially if you're a smaller MSP where self-service might genuinely be the right call. Larger client count, more complexity? A scoping call will get you a more useful answer than a volume-based estimate ever will.
Two MSPs, Two Migrations, Two Real Stories
Two real MSP PSA migration stories make the case better than any promise could.
VestaTech, moving into ConnectWise PSA
VestaTech, an IT and security services company out of Ardooie, Belgium, part of the Vestagroup family of companies, needed to move roughly 2,000 tickets, customers, and related activity records off Freshservice and onto ConnectWise PSA. Before the migration, the team was leaning on a home-built export script, and they'd already ruled out doing the import by hand as more work than it was worth at that volume. The initial test run uncovered a few minor errors, which VestaTech and support resolved before the full migration. After reviewing the test results, VestaTech stated that no other option came close. VestaTech's migration to ConnectWise provides an excellent example for services companies stepping into a full PSA. It demonstrates a direct platform switch rather than a merge, a distinction that matters for the next story.
ROIcode, merging two support instances into one
ROIcode, an information technology and services company based in Denver, Colorado, needed to bring two separate help desk systems, Kayako Classic and Zendesk, together into a single cloud-based Kayako account, rather than switching off either one wholesale. ROIcode's account merge in Kayako, consolidated both help desk sources into a single instance while preserving the company's full support history from day one. If your team needs to merge accounts after an acquisition rather than switch platforms entirely, this case study demonstrates how to execute that process smoothly.
Documented Migration Paths vs. Customer Outcomes
Beyond the named customer stories, Help Desk Migration has documented, mapped migration paths for the PSA and RMM platforms MSPs reach for most: SuperOps, Syncro, and Atera, plus step-by-step guides for ConnectWise migrations, Autotask PSA migrations, the SuperOps data migration checklist, and the Halo Service Solutions data migration checklist.
Worth being precise about what these two kinds of evidence actually mean, because MSPs evaluating a vendor notice when the distinction gets blurred. A named customer story, VestaTech’s or ROIcode’s, is an outcome: one company, one migration, one result, reported once and not extrapolated further. A documented migration path is different. It tells you Help Desk Migration supports that platform pair and a mapping already exists for it, not that a project of any particular size or complexity has actually run on it. Both matter. Neither one covers for the other, and any page that treats them like they're interchangeable is a page you should trust a little less.
Scale is the other half of that trust question. Help Desk Migration has completed more than 60,000 migrations, supports upward of 100 platforms, and holds SOC 2 Type II and SOC 3 compliance. None of that replaces VestaTech's story or ROIcode's. It just confirms the same discipline both of them got is available at scale, not as a one-off.
Before You Scope This, Start Here
For an MSP, scope the migration client by client, not as one large dataset.
Before you commit to a cutover, run the same five checks for every client:
Do not reuse one mapping across every client without checking the differences. A low-volume client with a different company structure or custom fields can require different mapping from a much larger client.
Help Desk Migration's SuperOps data migration checklist and Halo Service Solutions checklist follow this same connect, configure, select, map, and test structure. Use that format as the starting point for your own per-client migration checklist.
The rule is simple: one client, one mapping review, one validation before cutover.
Frequently asked questions
An MSP help desk is the ticketing and service-desk layer inside a PSA, or occasionally a standalone tool, that technicians use to log, route, and resolve requests for many different client organisations from one instance. It typically sits alongside billing, contracts, and asset records rather than functioning as a support tool on its own. Compare ITSM software for MSPs if you're choosing or reconsidering one.
MSP is a business model: a company managing IT for other businesses under contract. PSA is a software category: a professional services automation platform that runs that business, tying tickets, time entries, contracts, and billing together in one place. Most MSPs run on a PSA rather than a generic help desk, because a PSA carries a financial layer a help desk simply doesn't have. See ConnectWise migration for a common example of the category.
For an MSP, the PSA functions as the operating system for client work. Tickets, time entries, contracts, and billing are all tracked against a specific client, site, or contact, often against RMM data too. A help desk stops at "ticket resolved." A PSA continues into "hours logged" and "invoice generated." See Autotask PSA for a working example of that structure.
Different sources slice this differently, but most frameworks split data migration into storage migration, database migration, application migration, and business process migration, a model built for infrastructure, not PSA or ticket records specifically. If that's actually what you came here looking for, how Help Desk Migration's process works covers the record-level version that applies to service-desk data.
There's no single best tool. It depends on the platforms involved, whether the source has an API, and how much of the migration needs custom mapping or a straight field match. For PSA and help desk data specifically, compare Help Desk Migration's migration services against your source platform's native import tool before you decide anything.
"Best" depends on your client count, whether you need native billing and time tracking, and how deep your integrations need to run. Some MSPs run a dedicated PSA, ConnectWise or Autotask. Others run a lighter help desk alongside separate billing. Compare help desk and ITSM options built for MSPs before you assume a full PSA is the only road in.
Beyond the PSA itself, your tool stack usually includes RMM software for remote monitoring and management, a documentation platform, and sometimes a separate ticketing layer on top. PSA and RMM examples MSPs include ConnectWise PSA, Autotask PSA, Halo Service Solutions, SuperOps, Syncro, Atera, NinjaOne, and SherpaDesk, plus ITSM tools built specifically for the MSP cohort like ManageEngine ServiceDesk Plus MSP. See SuperOps competitors for a look at one newer all-in-one option.
A CRM tracks sales pipeline, contacts, and deals. A PSA tracks service delivery: tickets, time, contracts, billing against clients who are already customers, not prospects. Some platforms blend both, but for an MSP, the PSA is usually the system of record for service work, while a CRM, if you even run one, stays focused on new business. See how ConnectWise structures that data.
"MSP in cloud" usually refers to a managed service provider that manages a client's cloud infrastructure, or a client's move to cloud services like Microsoft 365. That's a different project from the one this page covers: migrating your own PSA and service-desk data rather than a client's cloud environment. See why MSPs switch platforms for the platform-side version of this question.
Common frameworks list rehosting, replatforming, repurchasing, refactoring, retiring, retaining, and relocating, a model built for infrastructure and application migration, not PSA or ticket data. If a cloud-migration search is what actually brought you here, see how the migration process works for the record-level equivalent that applies to service-desk and PSA data.