Migration guide
How to move a community to Ballastra
Moving a community is about people, not data — most migrations fail because the new home is worse organised, not because anything was lost. This guide is the practical path we recommend: design first, move what matters, invite in stages, and give the community time to commit.
- Step 1
Map your structure
List your channels and group them into categories. Each becomes a Space.
- Step 2
Create the Nexus
Set up categories, then Text, Voice and Announcement Spaces.
- Step 3
Rebuild roles
Recreate roles and set category and Space overrides.
- Step 4
Carry what matters
Repost rules, FAQs and key resources as pinned announcements.
- Step 5
Invite your people
Share an invite link and run both places side by side until people settle.
This is written for community owners moving from whatever platform they are on now, because the vocabulary and structure differ: a community container with channels is a Nexus on Ballastra and the rooms inside it are Spaces. If you have not decided whether to move at all, the Nexus and Spaces pages are the right starting points — they show what you are moving into.
Two honest facts before the plan. First: there is no automated importer yet, so content that must be kept is moved manually. Second: you do not have to move people all at once. Running both platforms side by side for a while is normal, and it is usually the difference between a migration that sticks and one that never completes.
Before you start
Design the Nexus before telling anyone
Because a Nexus is separately public or private, you can build the entire structure first: categories, Spaces, roles, permissions, announcements. Your community should arrive at a finished home, not a construction site.
Know what is worth keeping
Most chat history is not worth moving. Pinned announcements, important links, decisions, and how-to content are. The thousands of scroll-past memes are not. Decide the keep-list before you start touching content.
Expect some attrition
Any real migration loses a slice of members who do not follow a new link. That is normal and not a sign of failure — the community that remains is the community that wanted to be there.
What maps to what
If your community lives in a typical chat app today, most of what you have has a direct equivalent:
| You have | On Ballastra |
|---|---|
| Server or workspace | Nexus |
| Channel category | Category |
| Text channel | Text Space |
| Voice channel | Voice Space |
| Announcement channel | Announcements Space |
| Roles | Roles, with category and Space overrides |
| Bots | Aeros, with a managed role |
| Profile per app | One identity across Nexuses |
The five-phase move
Work through these in order. Each phase can be done alone or with a small trusted team — there is no need to involve the whole community until phase four.
- 1
Design: lay out the Nexus structure
Create the Nexus and build its categories and Spaces around how the community actually works — not how your old platform happened to be arranged. Common starting categories: Announcements, Introductions, General chat, Support or Feedback, then member-restricted Spaces for committees or maintainers. Set the visibility now (public for Discover, or private for invite-only) — you can change it later.
- 2
Set up roles and permissions
Define the roles the community needs (owner, moderators, trusted members, newcomers) and what each can do per category and per Space. This is the step that makes the new home better than the old one: do not just inherit whatever role sprawl you had — design the permission model deliberately. The roles and control page documents the model.
- 3
Move the keep-list
Create a migration Space and move the content you decided was worth keeping: pinned announcements, important links, decisions, how-tos, introductions of key people. Copy it as community-authored content, in your own structure. There is no importer yet, so manual is the way — and a migration Space keeps the move visibly in progress until it is done.
- 4
Invite in stages
Invite your core team first (they become the mods who set the tone), then the active members, then the wider community. Invite links work for public and private Nexuses alike. Post the invitation in your existing community with the straightforward framing: this is the new home, here is why, here is the link.
- 5
Run both until the community commits
Keep your old platform running as a landing page for stragglers, pointing to the Nexus. Announce the move, answer the "why" once, and let the centre of gravity shift. Most communities run both for a few weeks and only then cut over — and cutting over means closing or freezing the old space, not deleting it.
Keep and leave behind
Keep
- Pinned announcements and important links
- Decisions that still bind (guidelines, permission rules, policy)
- How-to threads people still reference
- Contact details of the core team
- The reason you are moving (say it once, in public)
Leave behind
- Thread history that is noise, not knowledge
- Inside jokes and memes that do not travel
- Permissions accidents and role sprawl from years of organic growth
- Any expectation that the move preserves your old platform’s exact layout
First-week checklist
- Nexus created, public or private chosen and internal
- Categories and Spaces laid out around the community’s real shape
- Roles and per-Space permissions designed, not inherited
- Announcement Space created and first welcome posted
- Keep-list moved into a migration Space
- Core team invited and made moderators
- Invite link posted in the old community
- Voice Space created and tested in-browser
- Both platforms running, with the old one pointing at the Nexus
- A cutover date set with the community told in advance
Questions
Realistic: one serious evening of design, a few evenings of moving the keep-list, then a week or two of running both platforms while members trickle over. Communities that try to move everyone in an afternoon do it twice. The reliable benchmark is four to eight weeks from decision to cutover — and expecting 10–30% of members not to follow is realistic, not pessimistic.
Not yet. There is no automated importer into a Nexus, so the keep-list is moved manually through a migration Space. That is deliberate: an importer would drag a channel-wall structure and its noise into the new home. The goal of migration is a better-organised community, and manual moving enforces that.
Nothing automatic. Keep it running as a pointer to the new Nexus while people migrate, then freeze or close it on your cutover date. Deleting it is optional and can be done after the community has clearly committed — most communities freeze rather than delete, which costs nothing and preserves what people made.
You will lose some people and that is normal — 10–30% of members typically do not follow a migration, however smooth it is. The people who stay are the active core, which is exactly who a community depends on. The migration is also a natural moment to prune: it is doing on purpose what most communities should have done anyway.
Yes — running both at once is the recommended path. A common split: a public Nexus for announcements, voice rooms and member Spaces, while the old platform stays for whatever still lives there. Splitting is rarely permanent; it is a ramp, not a destination.