Migrate your helpdesk without shutting down support
We move open tickets, templates and articles from your current helpdesk into AgentDesk, with both systems running side by side until cutover. Your team keeps working during the migration and your customers don't get any notification.
How the move from your current helpdesk to AgentDesk works
While both systems run, AgentDesk reads the mailboxes in parallel without marking messages as read, and the team keeps working in the old tool. A rule in that tool closes any thread that already carries the AgentDesk reference, so nobody replies twice. Those weeks are used to test classification and AI on real email.
Cutover happens channel by channel. For chat, intake is switched off in the old system and the chats still open are reconciled one by one: those already handled there are closed with a note and the rest move to the AgentDesk queue. Then every open ticket from each channel is loaded via API, and the team keeps working while the load runs.
No customer receives an email because of the migration: the previous conversation goes into each ticket as an internal note. The old tool is cancelled once reconciliation adds up, ideally before its renewal date. Closed cases aren't loaded as live tickets; they stay in a read-only search inside AgentDesk, where the team looks them up when a customer writes about something old.
What we pull from your current helpdesk
If your helpdesk runs in the cloud, it usually has an API to read tickets and contacts; if it's installed on your own server, we read the database. In both cases we run a test extraction first, because each API leaves out different things.
What gets migrated and what doesn't
The final list comes out of the test extraction, before the cutover date is set.
Migrated
- Open tickets from every channel, however old, with the previous conversation as an internal note
- The customer linked to each ticket
- Reply templates and macros, including email templates and ticket templates
- Knowledge base articles, with internal and public content separated
- The history of closed tickets, in a read-only search
- Departments and tags, reviewed by hand to make the most of the change
Not migrated as is
- Assignment rules and SLAs when the API doesn't expose them. They're set up again in AgentDesk with the team
- What each macro does: some APIs give the name but not the actions, and then they're rebuilt
- The help center. It's usually worth rebuilding it instead of copying it
- Old attachments in bulk. We decide whether to copy them or fetch them on demand, depending on their size and when the old system is switched off
- Closed cases the customer reopens: if they write again about a migrated, closed case, a new ticket is created
Whatever your tool's API doesn't provide is best found out during the test extraction, not on cutover night.
The migration, step by step
Six phases. During the first four your team keeps working in the current tool as usual.
Inventory and test extraction
We ask for read access to the API (or to the database if the helpdesk runs on your server) and pull a sample of tickets, conversations, templates and articles. This is where you find out what the API won't give you.
Field and category mapping
Statuses, departments, tags and custom fields from the old tool are mapped to AgentDesk. It's a good moment to rebuild categories from data instead of dragging along the ones from years ago.
Running side by side
AgentDesk starts reading the mailboxes without marking anything as read, and a rule in the old system prevents double replies. That way classification and AI get tested on real email without customers noticing.
Templates and knowledge
Templates, macros and articles are imported. Internal material becomes the team's canned replies and public content goes to the help center, after review.
Cutover, channel by channel
Intake in the old system is switched off one channel at a time, live cases are reconciled and open tickets are loaded without sending anything to customers.
Reconciliation and switch-off
We count tickets at source and destination, clean up duplicates and check what the API claimed to have done. Only then is the old tool cancelled.
What can go wrong and how we handle it
Four typical problems when migrating a helpdesk and how we solve them.
The API says yes and does nothing
When closing tickets in the source system, the API can return 200 and leave the ticket open. That's why reconciliation counts at both source and destination, and a sweep closes again whatever was left half done.
Duplicate tickets while both systems run
A customer emails while their ticket is being migrated and it shows up twice. We match on the customer's email with a two-day window either side, and the few that slip through are cleaned up afterwards.
The mail server stops responding
If email fails while both systems are running, a scheduled job rescues whatever is still pending in the old tool, so no message is lost until it comes back.
The network locks the AI out
A network restriction on the AI service can leave it unable to work right when it's needed most. That's why, before migrating, we test the AI from the same server and network you'll use in production.
How we avoid losing data
Reconcile before switching off
We count tickets per channel at source and destination and check for duplicates. Until the numbers add up, the old system isn't cancelled.
No service interruption
Both systems run side by side for weeks beforehand. Cutover happens channel by channel and the team keeps working during the load.
A way back
While the previous helpdesk is still active you can return to it. Anything cleaned up after migrating goes to a recycle bin and can be restored.
Common questions about migrating a helpdesk
Can we migrate to AgentDesk without losing our history?
Yes, as long as the data can be read through an API or from the database. Before committing to a scope we run a test extraction on your tool, because each API leaves out different things. Closed history can live in a read-only search inside AgentDesk.
How long does a helpdesk migration take?
The cutover is short; preparing it is what takes time. Both systems run side by side for weeks before open tickets are loaded, and the load happens while the team keeps working. The timeline depends on volume, how many channels there are and what the source API lets you extract.
Do we have to stop customer support during the migration?
No. AgentDesk runs alongside the old system reading the same mailboxes, and cutover happens channel by channel. Live cases in each channel are reconciled at cutover and the team keeps working while tickets are loaded.
Are macros, assignment rules and SLAs migrated?
It depends on what your tool's API exposes. Some APIs provide templates but not macro actions, assignment rules or SLAs; in that case they're set up again in AgentDesk with the team. We always check this during the test extraction.
Will our customers notice we've changed tools?
They don't get any notification: loading tickets sends no emails and the previous conversation goes in as an internal note. If the help center changes too, old URLs are redirected with a 301 so saved links keep working.
Before and after the migration
Tell us which helpdesk you're leaving
With the tool, the channels and a rough volume, we'll tell you what would be migrated, what would need rebuilding and how we'd plan the cutover.