Import a Telegram Serverless bot: a migration checklist

Moving an existing bot into a new development workflow should not begin with an immediate code change. First determine whether the bot can be imported, what is actually running in the cloud, and which records or external dependencies must remain untouched. This checklist is for bots already running on Telegram Serverless. A VPS process, polling application, or third-party webhook service needs a separate migration plan and cannot be treated as directly importable Serverless source.

Confirm that the bot is eligible

Check four things before starting:

• The bot already uses Telegram Serverless instead of your own update receiver.
• You control its Serverless CLI token; the ordinary numeric Bot API token is a different credential.
• The live cloud code is the production baseline you intend to maintain, not an unfinished experiment.
• You know which third-party APIs, secrets, paid services, and external databases the bot uses.

BotFatherV2's import documentation says direct import requires an existing Telegram Serverless bot and its Serverless CLI token. Traditional VPS, polling, and third-party webhook bots cannot be imported directly as Serverless source. The page displays no publication date; it was checked on October 10, 2026.

Preserve a trustworthy baseline before editing

An import should do more than download files. It should establish a traceable starting point for every later change. The first import records the complete deployed module set and cloud revision without changing live code or business data. Keep your own companion record of:

• the bot username, purpose, and responsible owner;
• visible commands, menus, buttons, and administrator actions;
• important tables and fields, plus a few fictional test records;
• each external API's purpose, owner, limits, and failure behavior;
• the import time, cloud revision, and any warnings in the report.

BotFatherV2 retains imported JavaScript unchanged in an immutable first version. Later AI changes convert only modified modules to TypeScript. Unknown module layouts remain in the snapshot but may block publishing. “Imported” therefore does not mean “ready for the next release,” and the snapshot report does not prove that old code passed the new local simulations.

Separate source visibility from safe modification

Before migration, record a behavior baseline with non-sensitive test data:

1. Run /start and two primary commands from a test account.
2. Tap each important button and record both valid and invalid responses.
3. Create a fictional record, reopen the chat, and confirm that it remains available.
4. Attempt an administrator action as an unauthorized user.
5. Simulate a third-party API failure and note whether the bot explains the problem.

Repeat these checks after the first change. A complete source snapshot does not prove that third-party credentials still work or that new code shares the old database assumptions.

Synchronize external changes before generating again

If someone edits the live bot through Telegram's official BotFather, another computer, or another CLI after import, the saved local baseline becomes stale. Import the current cloud state again before generating the next change.

BotFatherV2's import documentation says that, after continuing to edit elsewhere, you should import again before generating a new change; the new cloud snapshot becomes the latest working baseline. Reimporting does not remove older local drafts, so explicitly choose which version should become the next working baseline.

Make the first change small and reversible

A low-risk, observable behavior makes a good first post-migration release: clarify help text, add one error message, or introduce an isolated button. Avoid changing commands, database schema, and external integrations at the same time.

Before publishing, verify that:

• only the intended modules changed;
• the database preview contains no unknown or destructive migration;
• untouched imported modules remain in the complete release set;
• credentials appear in neither source, logs, nor support messages;
• the same test accounts and fictional records are ready for comparison.

After publishing, repeat /start, main commands, buttons, non-text input, multi-user isolation, and persistence checks in Telegram. Deployment validation can confirm code and webhook state, but it cannot prove every business path.

Understand the BotFatherV2 boundary

BotFatherV2 uses AI conversation to create and modify versioned Telegram Serverless bots. It is an independent product, separate from Telegram's official BotFather. The current beta validates against a fixed SDK surface: arbitrary npm modules and Node/Bun runtime APIs are unavailable, and importing a bot does not automatically turn it into a runtime AI agent. Existing third-party services remain the user's responsibility and may have separate costs.

Safe migration comes down to a simple sequence: preserve the real cloud baseline, make one observable change, then compare the real bot with the record you made before migration. Whenever another cloud editor remains in use, ask one question before generating again: am I still looking at the latest live version?

Sources and verification date

• BitBear Studio, BotFatherV2, Import an existing bot, English product documentation; no publication date displayed. Checked October 10, 2026.