Moving a free Discord into a paid community without emptying it

You have a free Discord with a few hundred people in it. You answer questions most days, you drop links, you run the odd voice call when you have the energy. It is genuinely useful to the people who use it, and it earns nothing. The idea of charging has been sitting at the back of your head for months, next to the fear that the moment you ask for money the room goes silent and you are left moderating an empty server you no longer enjoy.

The honest part about free to paid

Your member count is not your audience. A server counts joins, and joins accumulate for years. Open your Discord and look at who has actually posted or replied in the last month. For most creators that number is somewhere between five and fifteen per cent of the total. It feels like a demotion when you first see it. It is not. It is the only number worth planning against, and it is a far better predictor of what happens next than the figure in the header.

The second hard thing is framing. If people read your announcement as the thing I already had is being taken away, you will get resentment even from people who would happily have paid. The migration works when the paid room is a new place with something in it that the free room never had, and the free room carries on existing with a narrower purpose. Nothing is removed. Something is added.

The third thing is format. A store.fan community is a feed: posts, replies, pinned announcements. That is a different rhythm from a live chat channel. Threads stay readable a week later, which is exactly what most paid rooms need, but it is not the same as twenty people typing at once on a Friday night. If the live chatter is the whole product, keep it where it is and be deliberate about which room is the home.

What changes when access follows payment

Most people who try to monetise a free server end up gluing three tools together: the chat platform, a billing tool, and a spreadsheet where they reconcile who has paid this month. The joins are where it breaks. Someone cancels and stays in the room for six weeks because you did not notice. Someone pays and waits two days for a role because you were asleep.

The migration, in the order that actually works

This takes about three weeks of light work, most of it writing. Do not compress it into a weekend, and do not announce anything until step five is done.

1. 1Count the real room. Scroll back thirty days and list everyone who posted or replied. That list is your launch audience and your first draft of a pricing sanity check.
2. 2Pick the one thing that moves. Not everything. The weekly teardown, the office hours, the template library, the feedback thread. Choose the single item people thank you for most and make it the paid room's reason to exist.
3. 3Create the product. In your dashboard, add a new product and choose the community type. Give it a plain name, set a monthly price, and add a yearly price if you want the option of a longer commitment.
4. 4Write the product page for a stranger. Half the people who eventually read it will arrive from search, not from your server. Say what happens inside, how often, and who it is not for.
5. 5Seed the feed before you sell anything. Write eight to ten posts and pin a start-here announcement. An empty room on launch day is the single most common reason a paid community stalls.
6. 6Give the free server its new job in writing. Introductions, links, general chat, announcements. Say plainly that it is staying.
7. 7Announce with a date and a reason, in the server, in public, not as a mass direct message. Tell people what is new and what is not changing.
8. 8Run both rooms for thirty days. Post a visible excerpt from the paid feed into the free server each week so people can see what they are choosing between.
9. 9After thirty days, review. Change the free room's format if it needs it. Do not delete it.

What the arithmetic looks like

Suppose the sidebar says 620 members and, when you actually count, 74 people posted in the last thirty days. Say fifteen of them join at £9 a month in the first fortnight. That is £135 a month recurring, minus Stripe's card processing fee, landing in your own Stripe account because store.fan never holds the money and charges 0% on top. It is not life-changing. It is also the first month of something that renews without you doing anything, from people who were already in the room.

The number that matters more is the second month. Recurring revenue only compounds if people stay, and people stay when the thing you promised actually shows up on schedule. This is why step five exists. A community that publishes twice a week for eight weeks will retain very differently from one that published furiously for ten days and then went quiet. Those figures are arithmetic, not a forecast, and nobody can tell you what your room will do.

The mistake most people make

They charge for the room instead of for the work. "Access to the community" is not an offer, it is a door. The people who convert are buying a specific recurring thing they can picture: the Tuesday critique, the monthly call, the library that keeps growing. Write the product page around that thing and the room becomes the pleasant side effect. If you cannot name the recurring thing in one sentence, you are not ready to announce, and no amount of urgency in the launch post will cover for it. The feature list will not sell it for you either.

Migrations feel dramatic while you are planning them and mundane while you are doing them. You write a product page, you seed a feed, you post an announcement with a date, and then you keep publishing for two months. The free server carries on. The paid feed fills slowly with the people who were already doing the work of being in your room. That is the whole job. If you are also moving paid members across from another platform, there is a separate migration guide for that side of it.