Replatforming solves a missing capability. An AI layer solves excess volume. If you cannot name the helpdesk feature you need and do not have, the problem is volume, and moving the same queue to a different tool changes nothing except your invoice and your team's familiarity.
Key takeaways
- Name the missing capability in one sentence or the problem is volume.
- Migration cost is dominated by rebuilt configuration, not exported data.
- A layer takes an hour and can be reversed. A migration takes weeks and cannot.
- Doing both at once is how support projects fail visibly.
Support is struggling. The queue is growing, costs are rising, and the team is stretched. The instinct is to look at a different helpdesk.
Sometimes that is right. More often it is an expensive way to keep the same problem.
The diagnostic question
Write down, in one sentence, the capability you need and do not have.
If you can, migration is on the table. Something like “we need conditional routing by contract value and our tool cannot do it” or “we need audit logs for a compliance requirement”.
If you cannot, the problem is volume or cost, and a different helpdesk holds the same number of tickets at a similar price. That is the entire diagnostic and it takes thirty seconds.
What each intervention actually addresses
Replatforming changes what your tool can do. New routing capability, better reporting, different permissions, a different data model.
It does not change how many tickets arrive, how many need a human, or how long each takes. Those are properties of your customers and your product, not of your ticketing system.
An AI layer changes how many contacts reach a human. Documented questions get answered before they become tickets. Everything else arrives as it did before.
It does not add routing capability, fix your reporting, or give you audit logs.
Different problems, different tools. The confusion arises because both get pitched as fixing support.
The cost comparison
Migration. Two to twelve weeks depending on accumulated configuration. The export is easy. Rebuilding triggers, automations, views, macros, and integrations is what consumes the time, plus retraining every agent and deciding where history lives.
It is also difficult to reverse. Once you have migrated, migrating back is a second project.
A layer. Roughly an hour to connect content and set escalation rules. Reversible by removing a script. No history to move, no team retraining, no configuration to rebuild.
That asymmetry matters more than the licence difference. One is a decision you can unwind, the other is not.
The sequencing argument
If you think you need both, do the layer first.
Two reasons. It takes an hour, so it costs almost nothing to try. And it changes what you know: with a month of reduced volume behind you, the capability gaps you thought you had frequently turn out to have been coping mechanisms for an overwhelming queue.
Teams that migrate first often discover the new platform has the same problem, because the problem travelled with them.
When replatforming is genuinely right
Four situations:
A named capability you cannot get. Conditional routing, granular permissions, a compliance requirement, a specific integration. Concrete and checkable.
Your vendor changed the deal materially. A free tier removed, a feature moved several tiers up, packaging that no longer fits. Even then, negotiate and reduce volume first, because both improve your position.
The data model is wrong for your business. A ticket model where you need a customer timeline, or the reverse. This is a genuine architectural mismatch and no layer fixes it.
Vendor risk. Acquisition, deprecation, or a support relationship that has broken down.
When the layer is right
Queue volume is the pressure. You cannot name a missing feature and the pile keeps growing.
Cost is the pressure and seats drive it. Fewer tickets reaching agents means fewer agents, which changes the bill more reliably than a licence negotiation.
Coverage is the pressure. Overnight and weekend volume is creating a morning backlog you never dig out of.
You are mid-contract. A layer does not require unwinding a commitment.
The failure mode to avoid
Doing both simultaneously.
A migration and an automation deployment at the same time means you cannot attribute any outcome to either. If quality drops, you do not know why. If it improves, you do not know what to double down on.
Worse, both consume the same people during the same period, which is how support projects end up half-finished.
A practical sequence
- Write down the missing capability, in one sentence, or accept that there is not one.
- Run a queue analysis to see what your volume is actually made of.
- If topics are concentrated and documented, add a layer and measure for a month.
- Re-ask the capability question with a smaller queue.
- If the gap is still real, migrate deliberately, outside a peak period, with a full export taken first.
Steps one to four cost an afternoon and a month of patience. Step five costs weeks. Doing them in that order is worth it even if you end up at step five anyway, because you will arrive with a clearer specification of what you are buying.
Frequently asked questions
Should I migrate helpdesk or add AI?
How long does a helpdesk migration take?
Can I add AI resolution to my existing helpdesk?
What if I need both?
Resolve, don't deflect.
See Fidiora resolve a ticket, capture a lead, and keep the bill predictable.