How to Switch Discord Ticket Bots Without Losing Your History

What actually transfers when you switch Discord ticket bots

Short answer: almost nothing, and the exceptions are not the ones people expect. Ticket bots do not share a data format, and none of them ship an importer for a competitor's history. Every switch is a fresh install that happens to sit in a server with an existing support culture.

That sounds worse than it is. Most of what you lose is configuration you can rebuild in an evening, and rebuilding is often an improvement, because the category list you designed two years ago is usually longer than the one you need now. The genuinely irreplaceable part is history.

The last row is the one that causes support tickets about your support system. Everything else is work you can schedule.

The one thing you can genuinely lose

Transcripts. On most ticket bots, including ours, the ticket channel is deleted when the ticket closes and the transcript link becomes the only copy of that conversation. Access to that link depends on the bot still being installed and still being run by the same people.

So before you touch anything, answer three questions from your current bot's own documentation rather than from a search result:

• Where do its transcripts live, and for how long?
• Does removing the bot from your server end your access to them?
• Is there any export, or is the link the only artefact?

If the answer to the last one is "the link is it", then collecting the links you care about is not optional housekeeping, it is the migration. Disputes, refund arguments and staff conduct reviews all reach back further than people expect, and the moment you notice a transcript is missing is always months after the switch.

Our own retention is public and worth using as a yardstick when you evaluate anyone: transcripts are kept for 90 days on the free plan and 730 days on paid plans, the readable copy is removed at the end of that window, and closed tickets cannot be reopened. If a bot you are considering does not state a retention number anywhere, that is a question to ask rather than an assumption to make. There is more on how transcript links and privacy work in our guide to Discord ticket transcripts.

Do you actually need to switch?

This is worth thirty seconds before you spend an evening. Most people looking at a new ticket bot are not unhappy with ticketing itself. They are unhappy that the same twenty questions arrive every week and a human answers all of them. If that is the real complaint, replacing the panel bot does not fix it, and there is a smaller move available.

Our /ticket connect command attaches our AI to tickets opened by another ticket bot, on every plan including the free one, up to ten connected bots per server. When the other bot creates a ticket channel, we notice, and our AI answers inside it using the same per-server brain it would use in our own tickets.

The limits on that path are real and worth stating plainly, because they are the reason it is not always the right answer. External tickets store no messages, no transcript and no staff statistics on our side. Closing stays with the other bot: our AI cannot close, rename or delete a ticket it did not create. There is no panel behind an external ticket, so there is no wired staff role for an escalation to ping. Our bot needs the View Audit Log permission to attribute a new channel to the bot that made it, and it may need adding to the other bot's ticket access before it can see inside. And because the 14-day Premium trial is granted when you publish a panel of ours, a server that only ever uses connect never receives one.

If any of that matters to you, switch properly. If none of it does, you have just saved yourself a migration. The longer version of this path is in adding AI to Ticket Tool or any ticket bot, and the page for it is /connect.

How to run two ticket bots in one server without confusing anyone

Two ticket bots coexist fine. Each one only manages channels it created, so they do not fight over permissions, numbering or close buttons. The failure mode is not technical, it is human: if two panels are visible, members click whichever one they see first, and half your queue ends up on the bot you are retiring.

The rule is simple. Two bots, one panel. The old bot stays installed so its existing tickets can still be worked and closed, but its panel message comes down the moment the new panel goes up. Nobody can open a ticket on the old system after that, and everything already open finishes where it started.

The cutover, in the order that works

That order exists because every step before the last one is reversible. If the new bot turns out to be wrong for you, you put the old panel back up and nothing has been lost. Reverse the order, remove the old bot first to "make room", and you have destroyed your fallback before testing your replacement.

Close the old tickets before you remove the old bot

This is the step people skip, and it leaves a mess that is annoying to clean up.

Removing a bot from a Discord server does not remove the channels it created. Those channels are yours, and they stay. What goes away is the bot's ability to manage them. An open ticket channel whose bot has been kicked is a private channel with stale permission overwrites and a close button that does nothing, and the only way to clear it is for an admin to delete each one by hand.

More on those limits, and what else changes once the queue is permanently busy, is in what breaks on a large server.

What happens to your data when a bot is removed

Ask this of any bot you use, and check the answer against its documentation rather than its marketing. Here is ours, stated so you can hold us to it.

That 48-hour window is deliberately a grace period for accidents, not a safety net for a planned switch. If you are leaving on purpose, assume the data is gone the moment you remove the bot, because after two days it is.

The same logic applies in the other direction. If you remove your current bot to try ours and then decide to go back, whatever grace period that vendor offers is the only thing standing between you and a clean slate. Which is the whole argument for removing it last.

Rebuilding panels, categories and staff roles

The rebuild is the part people dread and it is usually the easiest hour of the project. Three notes from watching servers do it.

Cut the category list. Most servers arrive with a category list that grew one entry at a time and now has fourteen options, four of which get used. Members do not read a long list, they pick the first plausible one, and your routing is wrong before the ticket is even open. Five or six categories that describe outcomes is better than fourteen that describe departments.

Re-wire the staff permissions deliberately. Your Discord roles survive the switch, but the mapping of which role can claim, close, train the AI or see transcripts does not. That is a chance to fix the mapping rather than recreate it. Permissions are also where day one goes wrong most often, and the specific ones that break setups are covered in Discord ticket bot permissions explained.

Publish to a staff channel first. A panel you can see and members cannot is a full rehearsal. Open a ticket on it, claim it, close it, read the transcript, then move the panel where it belongs.

On our bot, /setup builds the whole starting shape in one command: a category, a panel, a staff role and the permissions it needs. Then you adjust. There is a step by step version in how to set up a Discord ticket bot, and the same walkthrough lives on /start.

Teaching a new AI what the old bot never knew

If the new bot answers questions, it starts knowing nothing about you, and this is the one part of the rebuild that is genuinely new work rather than re-entry.

Our per-server brain is taught with /ai train, or from the Train tab in the dashboard. You can hand it plain text, links, or files: a link is crawled as a real site crawl rather than a single page fetch, and attachments cover text, markdown, CSV, JSON, PDF, DOCX and images at up to ten per message. Training rewrites what you give it into structured entries rather than storing your wording verbatim, near-duplicates are blocked on write, and a newer fact supersedes an older one so two contradictory answers never both survive.

The practical advice is to seed it from the archive you just saved. Your old transcripts are a list of the questions your community actually asks, which is a far better starting point than a policy document nobody reads. Take the twenty most repeated questions, teach the answers, and the AI is useful on day one instead of month two.

Across that lifetime, roughly half of tickets were resolved by the AI without a human joining, and replies arrive in seconds. Both figures are live at /api/stats/global if you want to check them rather than take our word for it. There is a fuller guide to the teaching side in how to train an AI ticket bot.

What to tell your members, and when

Members do not care which bot you use. They care that the button they used last week still works. So say less than you think, and say it at the right moment.

How long a switch actually takes

The waiting is not padding. It is the difference between a switch nobody noticed and a switch that abandoned live conversations.

When not to switch

We would rather say this plainly than sell a migration nobody needed. If your current setup files tickets correctly and your team is happy in it, adding answers on top of it is a smaller, cheaper and less risky change than replacing it. If you do want the full system, the comparison of what is on offer is in Ticket Tool alternatives compared, and the free tiers are broken down in what free Discord ticket bots actually get you.

Before you remove anything

Work down that list and the removal is a formality. Skip it and the removal is the moment you find out what was only stored in one place.