From Your Own Bot to a Managed Store

To migrate a self-hosted Telegram bot to a managed platform sounds like a project — and for most sellers it is a weekend at most, because the asset that matters, the bot's identity, moves with one paste. Your users do not re-subscribe, the chat history does not move, and the bot they know simply starts answering better. This guide covers the honest path: what transfers, what does not, and the step-by-step.

Why developers migrate (honest reasons)

The vs GitHub bot comparison prices the DIY route in full; the short version of why maintainers give it up:

• The bot was the easy part. A working proof-of-concept from a tutorial runs for months; the catalog UI, the cart, checkout, receipts and the admin panel are the other 90% that never ships.
• Ops debt compounds silently. The VPS bill, the TLS renewal that quietly failed, the SQLite file the backup script forgot, the Bot API update that broke a handler at 2 a.m. — each is small, together they are a part-time job with no salary.
• The storefront gap. A hand-rolled bot answers commands; buyers increasingly expect a tappable catalog — a Mini App — and building that alone is a different project than the bot was.

None of this means the DIY build was a mistake. It means the store outgrew the hobby. The migration guide exists because the sunk cost of the old build is the worst reason to keep paying its real costs.

What transfers: token, users, catalog

• The bot identity — completely. The token you created in BotFather is the bot. Paste it into the platform's shop settings and the same @yourbot answers the same users. Nothing re-installs, nothing re-subscribes; from the users' side, the bot simply gained a storefront overnight.
• The audience — as-is. Subscribers stay subscribed; chats keep their history. If you migrate with a catalog import, the pinned message changes and the storefront link appears — that is the whole announcement.
• The catalog — with honest effort. There is no automatic import from a DIY codebase (every self-hosted bot stores products differently — in code, in a database, in a spreadsheet). The practical path: export your assortment to a flat list, then create the top sellers by hand in the visual editor — a plain product card takes under a minute. Bulk CSV import is on the roadmap; the honest advice is not to wait for it, because the top-20-products-first pattern outperforms a perfect import anyway.
• Payments — reconnected, not migrated. Provider credentials (Stripe keys, ЮKassa settings) are pasted into the payment screen like fresh; Stars need no setup beyond the product pricing. The payment gateway page walks the screen.

What does NOT transfer: the custom code itself — your handlers, your jokes, your edge cases. The AI agent and the storefront cover the standard flows; genuinely custom logic either becomes a feature request or lives alongside as a separate tool.

The migration path step by step

1. Export the essentials from the old bot: product list (name, price, description, photo URLs), any user notes you keep, provider credentials from the old config.
2. Create the shop on the platform (free plan is enough to rehearse): name, theme, categories mirroring the old bot's sections.
3. Enter the top products first — the ones that actually sold. Launch beats completeness; backfill the long tail in week one while orders run.
4. Paste the bot token in settings. The moment of migration is this paste: the platform's webhook takes over answering. Users notice nothing except the new menu button opening a storefront.
5. Connect payments per rail — Stars for digital goods, provider keys for physical.
6. Rehearse end-to-end: place a test order, mark it paid, check the receipt link, click through the storefront as a buyer would.
7. Announce once: pin the storefront in the channel, send one message — "the catalog is now tappable" — and retire the old server on its next renewal date, not before.

Total honest estimate: an evening for the mechanical steps, a weekend with catalog backfill and testing. The launch in 10 minutes guide covers the same steps for a fresh store — the migration is that checklist with an export prefix.

What you give up and gain

Give up: the code (if you loved it, fork it — it stays yours on GitHub), the illusion of zero platform fees, and the freedom to break your own bot at will.

Gain: the storefront (Mini App + web + PWA from the same store), checkout on both rails, receipts, an admin cabinet with orders/stock/clients/promo codes, updates as a line item instead of a weekend — and your month back. The builder home page shows the full feature set; the migration math is the same as the DIY comparison's, one transfer earlier.