Migrating from MyBB or phpBB

This is the procedure: what to do, in order, to move a MyBB or phpBB board onto Meith with its members, content and old URLs intact. If you are deciding whether your community will feel at home here rather than how to run the move, read MyBB parity decisions or phpBB parity decisions instead — each is the list of places Meith deliberately behaves differently from that board, with the reasoning and what an imported board loses. This page assumes you have already made that call.

The importer is one command, run against the old board's database. It is resumable — interrupt it or its budget runs out, run the same command again, and it continues from where it stopped — and it is designed to be rehearsed: point it at a copy of the old database as many times as you like before you point it at the real one.

Before you start

What comes across, and what does not

Not imported from either source, and what to do instead:

Run it

docker compose run --rm web community import --help

IMPORT_SOURCE_PASSWORD=… docker compose run --rm web community import \
  --source mybb --host db.old --user reader --database mybb \
  --uploads-dir /mnt/old-board/uploads

IMPORT_SOURCE_PASSWORD=… docker compose run --rm web community import \
  --source phpbb --host db.old --user reader --database phpbb \
  --prefix phpbb_ --uploads-dir /mnt/old-board

The password is never a flag — set IMPORT_SOURCE_PASSWORD in the environment instead (MYBB_PASSWORD still works, for scripts written before phpBB support existed). A flag ends up in your shell history and in ps for every other user on the box; an environment variable set inline on the command, as above, does not.

Without --uploads-dir

The importer still runs. Every attachment row is written marked failed, with the legacy path recorded rather than a file; avatars are skipped outright. Run the exact same command again, this time with --uploads-dir, and the files are filled in — nothing about the run before it needs redoing.

Large boards, and stopping partway

--budget is not a safety limit to raise once and forget — it is what makes one invocation predictable. A board with hundreds of thousands of posts run with the default budget will print Stopped after 2,000 rows (the budget). Not an error — run the same command again to continue from here. and mean it literally: run the same command again, as many times as it takes, or raise --budget to cover more of the board per invocation. Interrupting the process (Ctrl-C, a container restart, a lost connection) leaves it in the same resumable state — the last completed page's progress is saved before the next one starts, so a run picks up where it stopped rather than skipping or repeating a page.

Rehearse, then cut over

Because the importer only ever reads rows past its saved cursor, running it a second time against the same source picks up whatever is new since the first run — new members, new posts, new everything with a higher id than last time. What it will not pick up is a row it already imported that was later edited on the old board: the cursor for that kind has moved past it, so it is never read again.

That makes the practical sequence:

1. Rehearse against a copy of the old database until you trust the run.
2. When you are ready to actually move, put the old board into read-only mode (or take it offline) so nothing changes underneath the import.
3. Run the importer against the real database, to completion.
4. Point your domain at the new board.

Skipping step 2 does not corrupt anything — it just means a post edited on the old board between your last import run and the cutover keeps its pre-edit text here.

After the import

docker compose run --rm web community task:run counters.reconcile
docker compose run --rm web community search:reindex

The first rebuilds post counts, thread counts, reputation totals and warning points from the rows that now exist, rather than trusting numbers carried over from the old board's own (possibly already drifted) counters. The second builds the full-text index for the posts the import just wrote — new posts get indexed as they are made, but ten thousand imported ones did not go through that path.

Then, in /admin/settings?group=board, turn on Redirect old forum URLs (board.legacy_redirects) — it defaults to off, on purpose: turning it on before an import has actually run would answer every legacy address with a 404 instead of nothing configured to try. With it on, showthread.php, forumdisplay.php and member.php links (MyBB) or viewtopic.php, viewforum.php and memberlist.php links (phpBB) — including the rewritten route forms — permanently redirect to the matching content here, so search engine results and old bookmarks keep working.

Before you announce the move, check:

• Promote yourself — and any other former staff — to administrator before you do anything else. The importer does not carry legacy group membership across at all: every migrated account, including the old board's own administrators, lands in the ordinary registered group. Nothing about the sign-in page hints at this, so a board where nobody runs community user:promote (or grants access in /admin from an account that already has it) has, silently, no administrator. Do this first.
• Sign in as a migrated member, using their old password. The stored hash is your evidence the import worked, not a formality: Meith recognises the legacy MyBB or phpBB hash on that first sign-in, verifies the password against it, and silently replaces it with the board's own scheme — the member never sees a "reset your password" step, and every later sign-in uses the native hash.
• Walk the forum tree and a few threads. Structure, order and post content should all read the same as the old board.
• Open an imported attachment and avatar, if you ran with --uploads-dir. A broken image here means the uploads path was wrong, not that the import failed.
• Follow an old thread link and an old member-profile link and confirm they land on the new address, now that redirects are on.
• Rebuild the rest of your groups and forum permissions, add back any custom profile fields you need, and re-post announcements — the three things the table above says are on you, not the importer.

Content conversion

MyBB and phpBB posts are both BBCode; Meith posts are Markdown. The importer does not convert content at read time — every imported post, private message and signature is rewritten once, in the background, the same way an in-place upgrade converts an existing board's content. Both sources go through the same converter — a phpBB post has its bbcode_uid markers and stored smiley/link markup cleaned up first, but the BBCode itself parses identically either way. What survives the conversion and what is degraded to plain text is documented in full — with the exact list of tags — in The markup language is Markdown, not BBCode; the phpBB-only parts (smilies becoming their typed code rather than their image, and what happens to a global announcement) are in phpBB parity decisions. Read whichever applies before telling members what to expect; the short version for both is that formatting (colour, size, underline) is lost and the words are not.

Troubleshooting

For everything about running the container stack itself — logs, docker compose ps, mail and the worker — see Operations.

Next