Moving a phpBB board to XenForo
phpBB is one of the sources a forum migration is most likely to go well from, because the structures are close. What decides the outcome is the part the importer does not carry — permissions, attachments, and the details an old board accumulates.
The conversion is routine and the board is not
A phpBB board that has been running for years is not the board the importer was written against. It has been through phpBB's own major versions, it has modifications and extensions layered on it, it may have been converted from something else before that, and its permission model has accumulated per-forum and per-group overrides nobody has looked at since they were set. The importer handles the content; the accumulated detail is the project.
- The board has been through at least one phpBB major version upgrade
- Modifications or extensions were installed over the years
- Per-forum and per-group permissions have been customised and nobody has the full picture
- Attachments were stored on the filesystem or in the database, and nobody is sure which
- The board was itself converted from another platform at some point
- Custom profile fields or ranks are in use and are expected to survive
- The URL structure matters and the board's addresses are not what a default install produces
- The board has thousands of members and years of posts and a downtime budget of hours
The people who usually bring us this problem
An owner moving a long-running phpBB board
The board is active, its history matters, and you need to know what will and will not survive.
Someone whose previous conversion attempt lost something
Permissions, attachments or content did not arrive intact and you need to know which part failed.
An owner who has inherited an old board
Nobody knows what has been installed over it, and the migration is also an audit.
What this costs while it goes unfixed
Engineering faults are rarely confined to the engineering layer. These are the commercial consequences we see most often.
The importer carries content, and permissions are a separate project
phpBB's permission model and XenForo's are both built from groups, forums and overrides, and they do not correspond one-to-one. The importer maps the content faithfully and the permission model needs deliberate translation, including the overrides that were set years ago for a reason nobody recorded.
Modifications and extensions have no destination
Anything installed over phpBB — a gallery, a portal, a custom profile field system, a reputation feature — is not part of the platform and is not in the importer. Each one is either rebuilt as a XenForo add-on, replaced by an equivalent, or dropped with the decision recorded. Discovering this list after the migration is what turns a project into a crisis.
Attachments are the largest part and the least examined
phpBB stores attachments on the filesystem or in the database depending on its configuration, and boards have been configured both ways at different times. The volume is frequently the largest part of the migration and the part nobody has measured, which matters because it determines the transfer time and the window.
An old board is usually a converted board
Many phpBB installations started somewhere else. That history leaves structures and anomalies that the importer will carry faithfully into XenForo, where they will be visible — so the migration is also the opportunity to reconcile them, and it is better done deliberately than inherited.
Capabilities
Each of these is work we carry out, not an area we advise on.
Source audit before any conversion
The phpBB version and its history, installed modifications and extensions, attachment storage, permission configuration, custom profile fields, ranks and groups. On a board with years behind it this is the deliverable that determines the whole plan.
Importer scope and gap analysis
What the current importer carries, established for this board rather than assumed from documentation, and an explicit list of what it does not — each item with its handling: rebuilt, replaced, or dropped by decision.
Content and attachment conversion
Posts, threads, forums, private messages, attachments and the references between them, run in stages so the volume is manageable and each stage is verified before the next begins.
Permission and group translation
phpBB's groups, forums and overrides mapped onto XenForo's model deliberately, with the accumulated overrides examined rather than carried across blindly. This is where a migration is most likely to produce access that is wrong in one direction.
Members, ranks and profile data
Accounts, their state, ranks and custom profile fields, with the fields that have no equivalent in XenForo identified and a decision made about each rather than left to arrive as nothing.
Modification replacement
Each installed modification assessed: an equivalent XenForo add-on where one exists, custom development where the function is still needed, and removal where it is not. The list is produced before the cutover, not after.
URL preservation and redirect mapping
phpBB's address patterns — forums, topics with their offsets, member profiles, and any SEO extension's rewritten form — inventoried and mapped onto XenForo's, activated with the cutover rather than after it.
Staged cutover and verification
The bulk converted in advance, the cutover covering the delta, with reconciliation by content type and a tested return path. Publishing continues throughout, because a board that stops taking posts for a week loses members.
Engineering methodology
The sequence is deliberate. The order is usually what determines whether the work holds or has to be repeated.
Audit the board, not the platform
The importer was written against a default phpBB installation. What matters is this board: its version history, its modifications, its permission configuration and where its attachments live. The audit comes before any plan.
Establish the importer's actual coverage for this board
By testing against a copy rather than by reading documentation. The gap list is what the project is planned from, and it is produced before the cutover is scheduled rather than discovered during it.
Decide every modification's fate explicitly
Rebuilt, replaced or dropped, with the reason recorded. A modification that is simply absent after the migration is a feature the community notices and nobody can explain, which is worse than one that was deliberately removed.
Translate permissions rather than importing them
Mapping the models deliberately and examining the accumulated overrides. A board whose permissions have been adjusted over years has rules nobody can justify, and the migration is the moment they can be reviewed.
Inventory URLs before choosing the new structure
Every pattern the board has served, including the rewritten forms an SEO extension produces. phpBB boards frequently have two address patterns live at once, and both need mapping.
Convert in stages and verify each
Content, then attachments, then the structures that depend on both. Each stage reconciled by count per type plus inspection, so an error is found where it affects one content type rather than the whole board.
What an engagement produces
Documentation is a deliverable, not an afterthought. On most of these engagements a large part of the value is a defect report precise enough for another team to act on.
Audit
- phpBB version, version history and any prior conversion
- Installed modifications and extensions, with the fate of each
- Attachment storage and volume, measured rather than estimated
- The permission configuration, including accumulated overrides
- Custom profile fields, ranks and groups, with their equivalents or their absence
- What the importer carries for this board, and what it does not
Migration
- Content, members, private messages and attachments converted in verified stages
- Permissions and groups translated deliberately
- Ranks and profile fields handled, with decisions recorded
- Modifications rebuilt, replaced or removed
- URL inventory and redirect mapping, activated with the cutover
Cutover and after
- Staged cutover with a tested return path
- Reconciliation by content type, plus inspection
- Crawl, indexation and impression tracking against a pre-migration baseline
- A written account of what was converted, replaced and dropped
- What the community should expect to work differently
Architecture and technology
What a phpBB board carries that the importer does not
- Permission overrides set per forum and per group over the years
- Modifications and extensions with no XenForo equivalent
- Custom profile fields and their data
- Attachment storage, which may be filesystem or database and may have been both
- Structures inherited from a previous conversion into phpBB
- URL patterns produced by an SEO extension alongside phpBB's own
Where a phpBB migration most often loses something
- Permissions mapped by assumption rather than by translation
- Modifications discovered missing after the cutover
- Attachments referenced but not transferred, or transferred without references rewritten
- Custom profile fields arriving as nothing
- A second URL pattern from an SEO extension left unmapped
- An earlier conversion's anomalies carried forward unexamined
If this is not quite your problem
These overlap at the edges. Sending you to the right page is more useful than having you work it out.
The source is not phpBB
vBulletin and Invision have their own positions and their own pages.
Forum migration to XenForoSearch visibility is the main risk
Redirect mapping at volume and indexation recovery.
Forum SEO migrationFrequently asked
Is there an official phpBB importer, and does it work?
There is, and it is the reason phpBB is one of the more favourable sources to migrate from — the platforms are close enough in structure that the content conversion is routine. What it does not do is carry everything a long-running board has accumulated: permission overrides, custom profile fields, and anything installed as a modification or extension. So the question is not whether the importer works but what it covers for your board, and that is established by testing against a copy rather than from documentation. The gap list becomes the project.
Will our permissions survive?
They are translated rather than imported, and the difference matters. phpBB and XenForo both build permissions from groups, forums and overrides, and the models do not correspond one-to-one — so the mapping is done deliberately, and the accumulated overrides are examined rather than carried across. On a board that has been running for years there are usually rules nobody can justify, and the migration is the moment they can be reviewed. That is also why this is the part of a migration most likely to produce access that is wrong in one direction, and why it gets its own verification.
What happens to our modifications and extensions?
Each one is assessed and given a fate before the cutover: an equivalent XenForo add-on where one exists, custom development where the function is still needed, and removal where it is not — with the reason recorded. This list is produced during the audit, because a modification that simply is not there after the migration is a feature the community notices and nobody can explain. Discovering the list after the cutover rather than before is what turns a routine conversion into a project.
How long will the board be offline?
The window covers the delta rather than the whole board, because the bulk content and attachments are converted in advance. Its length follows the board's activity rate over the conversion period rather than its total size, which is why a busy board is not automatically a long downtime — it is the change rate during the transfer that decides. We will not promise zero downtime; the cutover is a real event and the plan states its length once the volume and the activity rate are measured.
Do you have a phpBB migration you can show?
No. Our published forum migrations are from other sources, and presenting one of those as a phpBB reference would be claiming a case we do not have. What the page describes is specific to phpBB and therefore checkable: what the importer carries, why permissions are translated rather than imported, and where attachments actually live on a board that has been configured both ways over the years. That is the part a reader has to plan around, and it does not depend on a logo.
Related capabilities and work
Bring us the problem you have not been able to fix
Describe what is happening rather than what you think the cause is. If we are not the right people for it, we will say so.