A client recently came to us with a problem most growing services businesses will recognise. Their work was spread across ClickUp and Freshservice. They wanted more granular permissions for their highly regulated client engagements, and the automation headroom they needed to deliver consistent customer service at scale. They decided where they wanted to go: HaloPSA, and they decided that this could replace both tools. However, there was a barrier to doing this - they needed to retain years of historical data that their own customers depended on for continuity of service. This meant that the blocker on moving to a new tool was going to be the task that no one likes to do - a data migration.
The technology answer is usually clear by the time we're called in — there's a target platform that would work better. The blocker isn't which tool. It's the fear that getting there will be slow, expensive, and unpredictable. Tickets will be lost. Reporting will break. Teams will rebel. Regulators or customers may object. Costs will overrun.
But none of that is inevitable. Done well, data migration shouldn't be a barrier to running your business on the right tools. Consolidation can — and should — be a chance to improve how the business actually runs, not just to move data from A to B. Here's how we approach it.
The Two Halves of Consolidation
A consolidation project has two halves that are easy to confuse but very different in nature.
The first is the data movement — getting tickets, comments, attachments, users, custom fields, and historical records from the source platforms into the target. This is genuinely technical work. For anything beyond the simplest cases you're working through APIs, often in a strict order, because attachments depend on tickets, comments depend on users, custom fields depend on schemas, and so on. Flat-file imports get you part of the way; they don't get you all the way. This is exactly the kind of work specialist tooling — like Help Desk Migration — exists to handle.
The second is the operating model redesign — deciding how the new platform should actually work for the business. What categories of work flow through it? What does good reporting look like? Who owns which queues? What new capabilities are now available — billing and invoicing, customer self-service, integrated change management — that weren't possible before, and which of those are worth turning on now versus later?
These two halves need each other. Doing only the first gives you the old mess in a new system. Doing only the second leaves you stuck because the historical data won't come.
Where most consolidation projects go wrong is treating it as purely a data-migration exercise. The biggest gains — and the biggest risks — sit in the operating model.
Why Consolidation is Harder than it Looks
Some of the complexity is genuinely technical. Some is organisational. The traps we see most often:
1. Data mapping isn't tidy. Different tools structure the same concepts differently. Status names, priority levels, ticket types, custom fields, categories, request types — almost nothing maps one-to-one. The hard part isn't writing the mapping; it's deciding what the mapping should be, which forces operating-model decisions before you're ready for them.
2. The agent/user/customer model varies between tools. Some platforms separate internal agents from external users from external customers as three distinct entity types. Others merge them. Some let agents be external partners; some don't. The way Freshservice models people isn't the way Halo models them, isn't the way Jira Service Management models them. Migrating users is rarely a copy-paste — it's a translation, and the choices you make here shape permissions, reporting, and licensing for years.
3. Custom fields and ticket types accumulate. Most source systems have years of accumulated customisation, some of it useful, much of it forgotten. Migrating it wholesale recreates the same maintenance problem in a new tool. Migrating only what's needed forces hard conversations with the people who created those fields.
4. Permissions get more complicated, not less. A consolidated platform usually has more teams using it than any individual source did. That means new permission models, new visibility rules, and a higher bar for getting it right — because mistakes are more visible.
5. Reporting is where mistakes show up first. Source systems often have reports that depend on specific field structures, statuses, or naming conventions. When those change in the target, the reports break — and stakeholders notice immediately. Reporting requirements should be designed into the migration, not bolted on afterwards.
6. You will usually need a full dress-rehearsal migration. Not a sample, not a partial — a full UAT migration with real data, against the configured target, run by the people who'll actually use the new system. This is where the genuine surprises emerge: data shapes you didn't expect, mapping decisions that turn out wrong, integrations that need adjusting. Budget the time and the cost for it. Trying to skip this stage is the most expensive shortcut in consolidation.
7. Regulatory and customer requirements often dictate what must be preserved. Sometimes a customer wants to "leave the old system behind and start fresh" — but their own customers, or their regulators, require historical tickets, comments, and attachments to be retained for audit purposes. That changes the migration scope completely, because the comment and attachment trail is the part that requires the most API work and the most careful sequencing. We've had projects where the data-retention requirement was the single reason the migration design got complicated. Find out early.
A Practical Approach
Every consolidation we've delivered has followed roughly the same shape. The labels matter less than the order.
1. Understand what's actually being used. Before mapping anything, find out how the source systems are actually used today — not how they were intended to be used, and not what the documentation says. Pull usage reports. Talk to the people doing the work. You'll usually find that a meaningful share of the customisation in the source system is dormant or no longer relevant. That's not a problem; it's an opportunity to consolidate to a simpler target.
2. Define the target operating model. This is the question we keep coming back to: what do you want the new platform to do for the business that the old ones don't? Better SLA reporting? Integrated billing and invoicing? Self-service request portals? Change management linked to a CMDB? Each of these pulls the configuration in a particular direction. Decide what you're optimising for before you start mapping data.
3. Design the data mapping against the new model, not the old. The mistake most teams make is mapping the source data structure directly into the target. The right approach is mapping the source data through the target operating model — which fields earn their place, which get archived, which get retired, which get consolidated together. This is where the operating-model decisions and the technical migration converge.
4. Run targeted trial migrations. Before the full dress rehearsal, — a single team's tickets, or one custom workflow, or one user group — to validate that the mapping logic and API sequencing actually work end-to-end. These short trials catch problems while they're cheap to fix.
5. Run a full UAT migration. The dress rehearsal. Full data, full configuration, real users testing real scenarios. Budget the time. This is the stage that determines whether the real cutover is calm or chaotic.
6. Cut over with a plan, not a hope. Communications, rollback criteria, support cover, who-decides-what-during-the-window. The cutover itself is usually anticlimactic if the UAT was thorough.
7. Support adoption properly. A new tool that works perfectly and that nobody uses is a failed project. Adoption needs internal champions, clear documentation, training that matches how people actually work, and visible leadership backing. This is the half that purely technical migration projects underestimate every time.
A recent example
The migration had to handle three different data shapes:
- Documents from ClickUp, where the structure was wiki-like and tied to projects
- Tasks from ClickUp, where the model was nested and dependency-aware
- Tickets from Freshservice, where the model was a classic ticket schema with comments, attachments, and requester relationships
Each of these had to be mapped — not into a like-for-like replica of how they'd existed in the source, but into the operating model we'd designed for the target. Documents went one way, tasks went another, tickets went a third, and in some cases they had to be cross-referenced because the same business work was represented across systems.
There's a DIY alternative for this kind of work: writing migration scripts directly against the source and target APIs. It's something we've done on past projects, and AI tooling is making it faster. But on projects where the data shapes are varied, the destination configuration is nuanced, and the timeline matters, using Help Desk Migration's specialist tooling de-risks the data move substantially and compresses the timeline. That freed us to focus on what the customer actually came to us for: the configuration, the automation design, and the permissions model.
The outcome the customer cared about wasn't "we moved the data successfully." It was that the new platform gave them the controls and the automations their business needed — without losing the historical record their own customers relied on. That's the difference between a data-migration project and a consolidation project.
We see similar dynamics when the destination is a PSA platform — bringing in billing, invoicing, project profitability, and time-tracking capabilities alongside the operational work. For a worked example of a consolidation into HaloPSA, see our recent case study on bdq.cloud.
Where Help Desk Migration fits
We don't pretend to be a data-migration tooling company. The technical work of building and running migration scripts against multiple platform APIs, in the right sequence, handling edge cases for attachments and comments and user mappings — that's a specialist craft, and Help Desk Migration is genuinely good at it.
Just as importantly, specialist tooling keeps both the cost and the timeline of the data move predictable. Migration spend should be a known line item, not an open-ended risk — and when it is known, the business case for the broader consolidation becomes much easier to approve.
The point we keep coming back to
Data migration shouldn't be a barrier to running your business on the right tools. It can be expensive, it can be time-consuming, and it can be risky — but with the right partners and the right approach, it isn't a reason to stay on a platform that's no longer serving you.
The organisations that get the most out of consolidation are the ones that treat it as an opportunity to improve the operating model, not just to transfer data. The technicalities of API scripting and field mapping shouldn't be where the business value lives. The business value lives in better reporting, better processes, better automation, and teams that can actually see and act on the work that matters.
If you're considering a consolidation, the question worth starting with isn't "how do we move the data?" It's "what should this look like once we're done?" The data part will follow.
About BDQ
BDQ Cloud is a London-based IT consultancy specialising in migrating, consolidating, and modernising service management platforms. We work with HaloITSM, Atlassian, Freshworks, Asana, and other modern tools, and we partner with Help Desk Migration for the technical data-migration work that underpins our consolidation projects. If you'd like to talk through a specific consolidation challenge, we offer a 30-minute migration assessment focused on the operating model and outcomes, not just the data side.
