10/14/2026
Moving a Discord bot to Bottly: what to keep, rebuild and test
A careful migration checklist for an existing Discord bot: keep control of your application, rebuild behaviour in small pieces, move persistent data deliberately, and avoid two systems running at once.
Changing bot builders is usually easy until you reach the parts nobody wrote down.
The commands are visible. The awkward details are not: a role ID in an old event, a warning count stored somewhere else, a scheduled message, or a button on a six-month-old support panel that still points at the previous system.
If you are considering Bottly as an alternative to another Discord bot builder, start with an inventory rather than your token. You need to know what you are moving before you decide how to move it.
Your Discord application and the tool running it are different things. If you control the application in the Discord Developer Portal, you can usually keep its identity while changing the system that operates it.
That does not automatically move commands, stored records or integrations. A token gives a runtime access to the bot; it is not an export of the old builder's configuration.
First, confirm who owns the application and who can reset its token. If a provider or seller owns it, do not assume you can transfer it. Resolve ownership before promising members that the bot's identity will stay the same.
Never send a token to someone offering to “check compatibility” in a direct message.
Write down what the bot actually does. Group the work by feature, not by the number of commands shown in an editor.
For each feature, record its trigger, output, role restrictions, channel targets and stored data. Include scheduled jobs, webhooks and interactive messages that are already sitting in Discord.
This inventory is also your test plan. If a feature is missing from the list, it is likely to be missing from the migration.
Do not rebuild everything simply because it exists. A command nobody has used for a year is a maintenance cost, not a requirement.
Mark each item as one of three things:
Start the Bottly build with one small command that has no stored state. That lets you check the application connection, command registration and response format before you introduce data migration or destructive actions.
The first-bot guide is a useful starting point for that test.
A visual flow from one builder is not necessarily compatible with another. Similar-looking blocks can differ in their inputs, output variables, timing or permission handling.
In Bottly, use Commands for slash commands and their responses, Design for embeds, and the flow builder for the triggers, conditions and actions a workflow needs. The workspace guide explains the sections.
Translate each old feature into a short description of its behaviour before rebuilding it. For example: “When a member clicks this button, check their role, add the selected role if allowed, then reply privately.” That is easier to verify than trying to recreate a canvas node for node.
Treat existing code separately. A visual builder is not a promise that an arbitrary JavaScript project can be pasted in and run unchanged. Review runtime requirements, dependencies and external services before choosing a code-based path.
Warning counts, member balances, giveaway entries and open-ticket records are not decoration. Losing them can change how your community works.
Check what your current provider lets you export. Keep a backup in a private place and record the export time. If the data contains member information, limit who can access it.
Then decide which records are genuinely needed in the new system and how they map to its storage. Keep Discord IDs as IDs, rather than trying to match members by display name. Display names can change and are not unique.
Do not assume that ordinary flow variables persist between separate events. If one interaction writes a value and tomorrow's command must read it, that value needs persistent storage.
Test the transfer with a few harmless records first. Check counts, identifiers and a real read-back through the feature that uses the data before importing the rest.
Where practical, build and test with a second Discord application in a private server. This avoids changing your live bot's commands while members are using them.
Use test channel and role IDs, then keep a clear list of the values that must change at cutover. A successful message sent to your testing channel is not proof that the production destination is configured.
Test with an ordinary member as well as staff. Include missing permissions, a deleted target channel and a repeated button click. Happy-path tests catch less than you might expect.
For support workflows, use the ticket privacy checklist before accepting real requests.
Pick a quiet period and tell your moderators what will briefly stop working. A cautious sequence is:
Do not leave both systems operating the same bot as your migration strategy. Depending on how they register commands and handle gateway events, you can get overwritten command definitions, duplicate actions or confusing failures.
If you reset the token during the move, update the new host accordingly. The old token should not remain a fallback credential.
A button already posted in Discord can remain visible after its original handler has gone away. The message looking correct does not mean the new system knows what to do when someone clicks it.
Check support panels, role menus and announcement buttons individually. Replace old messages with newly tested ones when needed. Update pinned instructions and channel topics that refer to commands you retired.
This is an easy place to miss a problem because the migration looks complete in the editor while members are still using an old entry point.
Before cutover, write down what would make you stop and roll back: broken essential commands, incorrect private-channel access, or missing records are reasonable examples.
Keep the old configuration and data backup until the new setup has handled real usage successfully. If you need to return to the old host, stop the new one first and make sure the token and data you restore are current.
Bottly is worth evaluating on whether your actual workflows work clearly and reliably, not on how quickly you can copy a feature list. Move one behaviour, prove it in Discord, then move the next.
The commands are visible. The awkward details are not: a role ID in an old event, a warning count stored somewhere else, a scheduled message, or a button on a six-month-old support panel that still points at the previous system.
If you are considering Bottly as an alternative to another Discord bot builder, start with an inventory rather than your token. You need to know what you are moving before you decide how to move it.
Separate the Discord application from the builder
Your Discord application and the tool running it are different things. If you control the application in the Discord Developer Portal, you can usually keep its identity while changing the system that operates it.
That does not automatically move commands, stored records or integrations. A token gives a runtime access to the bot; it is not an export of the old builder's configuration.
First, confirm who owns the application and who can reset its token. If a provider or seller owns it, do not assume you can transfer it. Resolve ownership before promising members that the bot's identity will stay the same.
Never send a token to someone offering to “check compatibility” in a direct message.
Make an inventory of behaviour
Write down what the bot actually does. Group the work by feature, not by the number of commands shown in an editor.
/help
Response: rules and support directions
Access: all members
Saved data: none
Ticket opening button
Result: private channel for requester and support
Access: all members may request; support handles replies
Saved data: open ticket → requester → channel
Welcome message
Trigger: member joins
Destination: welcome channel
Saved data: none
For each feature, record its trigger, output, role restrictions, channel targets and stored data. Include scheduled jobs, webhooks and interactive messages that are already sitting in Discord.
This inventory is also your test plan. If a feature is missing from the list, it is likely to be missing from the migration.
Choose what belongs in the first version
Do not rebuild everything simply because it exists. A command nobody has used for a year is a maintenance cost, not a requirement.
Mark each item as one of three things:
Must work at cutover: essential support, permissions or community workflows.
Can follow later: useful features with a safe temporary alternative.
Retire: abandoned commands, old experiments and redundant integrations.
Start the Bottly build with one small command that has no stored state. That lets you check the application connection, command registration and response format before you introduce data migration or destructive actions.
The first-bot guide is a useful starting point for that test.
Rebuild behaviour, not screenshots
A visual flow from one builder is not necessarily compatible with another. Similar-looking blocks can differ in their inputs, output variables, timing or permission handling.
In Bottly, use Commands for slash commands and their responses, Design for embeds, and the flow builder for the triggers, conditions and actions a workflow needs. The workspace guide explains the sections.
Translate each old feature into a short description of its behaviour before rebuilding it. For example: “When a member clicks this button, check their role, add the selected role if allowed, then reply privately.” That is easier to verify than trying to recreate a canvas node for node.
Treat existing code separately. A visual builder is not a promise that an arbitrary JavaScript project can be pasted in and run unchanged. Review runtime requirements, dependencies and external services before choosing a code-based path.
Move persistent data deliberately
Warning counts, member balances, giveaway entries and open-ticket records are not decoration. Losing them can change how your community works.
Check what your current provider lets you export. Keep a backup in a private place and record the export time. If the data contains member information, limit who can access it.
Then decide which records are genuinely needed in the new system and how they map to its storage. Keep Discord IDs as IDs, rather than trying to match members by display name. Display names can change and are not unique.
Do not assume that ordinary flow variables persist between separate events. If one interaction writes a value and tomorrow's command must read it, that value needs persistent storage.
Test the transfer with a few harmless records first. Check counts, identifiers and a real read-back through the feature that uses the data before importing the rest.
Keep a separate test application
Where practical, build and test with a second Discord application in a private server. This avoids changing your live bot's commands while members are using them.
Use test channel and role IDs, then keep a clear list of the values that must change at cutover. A successful message sent to your testing channel is not proof that the production destination is configured.
Test with an ordinary member as well as staff. Include missing permissions, a deleted target channel and a repeated button click. Happy-path tests catch less than you might expect.
For support workflows, use the ticket privacy checklist before accepting real requests.
Plan the cutover in the right order
Pick a quiet period and tell your moderators what will briefly stop working. A cautious sequence is:
Stop writes or activity in the old system where possible.
Export any final records that changed after your test export.
Stop the old host or deployment.
Connect the production application to the new setup.
Save the correct production channel and role settings.
Start the new deployment and register the intended commands.
Run the essential tests in Discord.
Do not leave both systems operating the same bot as your migration strategy. Depending on how they register commands and handle gateway events, you can get overwritten command definitions, duplicate actions or confusing failures.
If you reset the token during the move, update the new host accordingly. The old token should not remain a fallback credential.
Old buttons need attention too
A button already posted in Discord can remain visible after its original handler has gone away. The message looking correct does not mean the new system knows what to do when someone clicks it.
Check support panels, role menus and announcement buttons individually. Replace old messages with newly tested ones when needed. Update pinned instructions and channel topics that refer to commands you retired.
This is an easy place to miss a problem because the migration looks complete in the editor while members are still using an old entry point.
Keep a rollback plan
Before cutover, write down what would make you stop and roll back: broken essential commands, incorrect private-channel access, or missing records are reasonable examples.
Keep the old configuration and data backup until the new setup has handled real usage successfully. If you need to return to the old host, stop the new one first and make sure the token and data you restore are current.
Bottly is worth evaluating on whether your actual workflows work clearly and reliably, not on how quickly you can copy a feature list. Move one behaviour, prove it in Discord, then move the next.