Moving a Discourse community to XenForo
Discourse and XenForo disagree about what a thread is, how identity works and how trust is expressed. None of those has a conversion — they have a decision, and making them is the migration.
The content converts and the model does not
Discourse is a flat, category-and-tag system with a trust-level model and a single identity provider; XenForo is a hierarchical forum with group-based permissions and its own accounts. Posts and topics have equivalents. Categories, tags, trust levels and the relationship between them do not, and neither does the way the two platforms treat a conversation's shape. A conversion that carries the text and not the decisions produces a community that is recognisably not the same place.
- The community is on Discourse and the reasons for that have changed
- Categories and tags are both in use and their relationship is not obvious
- Trust levels are doing real work and there is no equivalent to map them to
- Authentication is delegated to an external provider and the move raises the question
- Discussions rely on the flat, chronological model rather than pages
- The community expects to keep its identity and its history
- Somewhere in the Discourse history there is content that has to be preserved exactly
- The move is being planned and nobody has compared the two models
The people who usually bring us this problem
An owner moving a community off Discourse
The reasons vary — cost, control, hosting, the model itself — and the migration is the consequence.
Someone whose community relies on trust levels
The trust model does real work here and there is nothing in XenForo that maps onto it directly.
Someone with delegated authentication
Identity lives outside the community and the move raises whether it should.
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.
Categories and tags do not become forums
Discourse's categories and tags are a flat taxonomy with a many-to-many relationship; XenForo's forums are a hierarchy with per-node permissions. A category becomes a forum, but a tag has no equivalent, and a topic carrying several tags has no single place to go. This is the first decision and it determines the URL structure of everything.
Trust levels have no equivalent and have to be redesigned
Discourse's trust levels are earned from activity and confer specific capabilities; XenForo's permissions are granted through groups. There is no conversion — there is a decision about what the community's earned standing should become, whether it is reproduced as a group that members are promoted into, expressed as something else, or dropped. Each answer changes what the community is.
The conversation shape is different
Discourse is flat and chronological, with replies in order and a single stream; XenForo is paginated with quoting and threading conventions. Long Discourse discussions do not have a natural page boundary, and the migration has to choose one — which affects URLs, quoting and how a long conversation reads.
Identity is usually external and the move forces the question
Discourse is commonly deployed with authentication delegated to an external provider, which is a decision that was made once and never revisited. Moving to XenForo means either keeping that arrangement or bringing identity into the community, and the second has consequences for every other system that reads it.
Capabilities
Each of these is work we carry out, not an area we advise on.
Model comparison before any conversion
The two platforms' structures placed side by side: categories, tags, forums, permissions, identity, trust and the conversation model. This is the deliverable the whole project is planned from, and it is what turns an unpredictable migration into a list of decisions.
Category and tag mapping
Categories to forums, and a decision for tags — promoted to forums where they carry real structure, kept as XenForo's own prefixes or tags where they do not, or retired. Multi-tag topics are the case that forces the decision, and they are common.
Trust and permission design
What the community's earned standing becomes in XenForo: a promotion path into groups, a reputation expression, or a deliberate simplification. Designed with the community's own rules in mind rather than mapped by assumption.
Identity decision and implementation
Whether the community keeps delegated authentication or takes identity into itself, and the consequences either way for the systems that currently read it. Implemented as part of the migration rather than left as a gap.
Content conversion
Topics, posts, users and the references between them, converted with the platform's own tooling where it covers the source and with a custom importer where it does not — including the content types that are not posts.
Conversation shape and pagination
Where page boundaries fall in a discussion that never had them, chosen deliberately so long threads read coherently and their URLs are stable.
URL preservation and redirect mapping
Discourse's address patterns mapped onto XenForo's, including the topic-slug-and-id form and the reply anchors that a flat model produces. Activated with the cutover, because a community with years of inbound links loses visibility without it.
Cutover and reconciliation
Staged conversion, a cutover covering the delta, verification by count and by inspection, and a written account of every decision made about the models — which is the document the community will need afterwards to understand its own history.
Engineering methodology
The sequence is deliberate. The order is usually what determines whether the work holds or has to be repeated.
Compare the models before converting anything
Structure, identity, trust and conversation shape, written out side by side. It is the only way the decisions become visible as decisions, and it is what stops a conversion being planned against an assumption that the platforms are equivalent.
Decide tag fate explicitly, per tag
Promote, keep, or retire — with the reason. Tags that carry real structure deserve forums; tags that are descriptive belong in XenForo's own taxonomy; tags that were never used consistently should be retired rather than carried forward as noise.
Design trust rather than translating it
There is nothing to translate. What the community's earned standing becomes is a design decision, made with the people who run the community, and stated so members understand what changed about their standing and why.
Settle identity as part of the migration
Not afterwards. Whether authentication stays delegated or moves into the community determines what the other systems do, and leaving it undecided means the community arrives without a working sign-in path — which is the first thing every member notices.
Choose page boundaries deliberately
A flat discussion has no natural page size and XenForo's threads do. Choosing where the boundaries fall affects how long threads read, what their URLs are, and how quoting behaves — so it is a decision rather than a default.
Inventory URLs including the anchors
Discourse's topic addresses and its reply anchors, which are frequently linked from outside. Anchors are where forum redirect maps most often break, and on a source that produces a flat stream they are more common than usual.
Record every model decision
What each category, tag, trust level and identity arrangement became, and why. The community will need it — to explain its own history, and to understand why something it used to do is now done differently.
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.
Model comparison
- Categories and tags against XenForo's forums, prefixes and tags
- Trust levels against XenForo's groups and permissions
- Identity arrangements, and the consequences of each option
- Conversation shape, and where page boundaries will fall
- What converts, what is designed, and what is dropped
Migration
- Content, users and references converted in verified stages
- Categories mapped to forums, and a decision recorded per tag
- Trust and permission design implemented
- Identity implemented, whether delegated or local
- URL inventory and redirect mapping including reply anchors
Cutover and after
- Staged cutover with a tested return path
- Reconciliation by content type plus inspection
- Crawl, indexation and impression tracking against a baseline
- A written record of every model decision and its reason
- What members will notice as different, documented for them
Architecture and technology
Where the two platforms disagree
- Discourse's flat categories and tags against XenForo's hierarchical forums with per-node permissions
- Trust levels earned from activity against permissions granted through groups
- Delegated authentication against the community's own accounts
- A flat chronological stream against paginated threads with quoting conventions
- Topic slugs with ids against XenForo's URL patterns
The decisions a Discourse migration forces
- What each tag becomes — a forum, a prefix, or nothing
- Where a multi-tag topic lives when it carries several
- What earned trust becomes, and whether members are promoted
- Whether identity stays external or moves into the community
- Where page boundaries fall in a discussion that had none
- What is deliberately not carried, and how members are told
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 a conventional forum
vBulletin, Invision and phpBB have their own positions and pages.
Forum migration to XenForoSearch visibility is the main risk
Redirect mapping at volume and indexation recovery.
Forum SEO migrationThe destination needs custom functionality
Add-ons where the platform does not provide what the community had.
XenForo add-on developmentFrequently asked
Is there a Discourse importer for XenForo?
There is community tooling for parts of it, and it is not the same thing as a supported conversion path — which is why this page leads with the model rather than with a tool. Discourse is the source where the two platforms disagree most: categories and tags against a forum hierarchy, trust levels against groups, delegated authentication against local accounts, and a flat stream against paginated threads. Some of that converts, some of it is designed, and a project planned on the assumption that a tool will handle it is planned on the wrong basis.
What happens to our trust levels?
They are redesigned rather than converted, because there is nothing in XenForo that corresponds to them. Discourse's trust levels are earned from activity and confer specific capabilities; XenForo's permissions come from groups. So the question is what the community's earned standing should become — a promotion path into groups, some other expression of reputation, or a deliberate simplification. Each answer changes what the community is, which is why it is decided with the people who run it rather than mapped by assumption.
Can we keep our single sign-on?
Yes, and whether you should is a decision rather than a default. Discourse deployments commonly delegate authentication to an external provider, which is an arrangement that was decided once and rarely revisited. Moving to XenForo can keep it or bring identity into the community — and the second option affects every other system that currently reads identity from that provider. Either way it is settled as part of the migration, because a community that arrives without a working sign-in path is one where the first thing every member notices is that they cannot get in.
How do long discussions convert?
With chosen page boundaries. Discourse is a flat chronological stream, so a discussion that ran for two thousand replies has no natural break; XenForo's threads are paginated. Where those boundaries fall is decided rather than defaulted, because it affects how a long thread reads, what its URLs are and how quoting behaves. It is a small decision with a visible consequence, which is the kind that is worth making deliberately rather than discovering.
Do you have a Discourse migration you can show?
No. Our published forum migrations are from other sources, and the honest position is that Discourse is the source where we would want to establish the model comparison before committing to a plan — the platforms disagree enough that the work is substantially a design exercise rather than a conversion. What this page can offer is that comparison written out: what has an equivalent, what has to be decided, and what changes about the community as a result. That is the part a reader has to plan around.
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.