Moving WoltLab to XenForo
WoltLab is not one source. Its major versions changed the data model substantially and its applications are separate products with their own tables — so the first question is which WoltLab, not whether WoltLab is supported.
The version and the applications decide the work
WoltLab's forum has been through generations that differ enough in their data model that a converter written for one does not read another. Alongside the forum there are separate applications — a blog, a gallery, a filebase, a calendar — each with its own tables and its own relationships into the community's members and content. A migration scoped as "WoltLab to XenForo" without establishing which version and which applications is scoped against an assumption.
- The board is on a WoltLab version nobody has confirmed
- The suite is installed with applications beyond the forum
- A gallery, blog or filebase is in use and carries content the community values
- An earlier conversion attempt read the tables incorrectly
- Custom plugins or packages were installed from the WoltLab ecosystem
- The board's own version history is unclear — it may have been updated across generations
- Nobody can say how much content there is, across which applications
- The migration is being scoped before the source has been established
The people who usually bring us this problem
An owner moving a WoltLab board
You need to know what your installation actually is before anyone can tell you what the migration involves.
Someone with the full suite rather than the forum
Applications beyond the forum hold content that has to be accounted for.
Someone whose previous conversion read the data wrong
The content arrived incorrectly and the cause has not been established.
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.
A converter written for one version does not read another
WoltLab's generations differ in their data model enough that the tables, their relationships and their meanings change between them. Work done on one version establishes what that version requires; it does not establish what another requires, and treating it as though it does is how a conversion reads the wrong columns and produces content that is subtly wrong.
The applications are separate products with separate tables
A gallery, a blog, a filebase and a calendar each store their content independently and each reference the community's members and content in their own way. A migration scoped to the forum moves the discussion and leaves the rest, which is frequently where the community's most-referenced content lives.
Packages and plugins have no destination
WoltLab's package system allows plugins from its ecosystem, and anything installed through it is not part of the platform and not in any converter. Each one is rebuilt as a XenForo add-on, replaced by an equivalent, or dropped with the decision recorded — and the list has to be produced before the cutover.
Version history is frequently not what the current version suggests
A board that has been updated across generations carries structures from each of them, and its current version number describes the software rather than the data. Establishing what the data actually looks like is a separate question from establishing what version is installed.
Capabilities
Each of these is work we carry out, not an area we advise on.
Source identification before scoping
The exact version, its generation, and what the data actually looks like — which is not always the same thing as what the installed version implies. The migration cannot be scoped until this is established, and it is the first deliverable.
Application inventory
Which applications beyond the forum are installed and in use, how much content each holds, and how each references members and forum content. This determines the scope of the project and it is consistently larger than expected.
Data model analysis per version
The tables, relationships and encoded states for this version specifically, established from the data rather than assumed from another version's structure. It is work that is per version by nature, and it does not generalise.
Converter development
A converter written for this version and this set of applications, in resumable stages, with the mapping documented as it is written. Where tooling exists for the version, it is assessed and used or extended rather than assumed adequate.
Cross-application content handling
Gallery entries, blog articles, filebase entries and calendar events each mapped to a destination in XenForo or to a decision that they are not carried — with the community's most-referenced content identified before that decision is made.
Package and plugin assessment
Every installed package assessed for an equivalent, a rebuild, or a deliberate removal. Produced during the audit, because a feature that is simply absent afterwards is one the community notices and nobody can explain.
URL preservation across applications
WoltLab's address patterns for the forum and for each application, inventoried and mapped. A suite produces a wider URL estate than a forum alone, and each application's addresses need their own mapping.
Cutover, reconciliation and the record
Staged conversion, a cutover covering the delta, verification against checks derived from the source, and a written account of what was carried, rebuilt and dropped.
Engineering methodology
The sequence is deliberate. The order is usually what determines whether the work holds or has to be repeated.
Identify the source before scoping anything
Version, generation, installed applications and what the data actually contains. This is a real piece of work rather than a preliminary, and a migration scoped without it is scoped against an assumption about which WoltLab this is.
Do not generalise across versions
Each generation's model is established from its own data. Prior work on a different version is evidence about that version and is treated as such — which is why this page claims no coverage beyond what it can establish.
Inventory applications as separate projects
Each with its own volume, its own relationships and its own mapping. A suite migration is several migrations that share a cutover, and treating it as one is how an application's content is discovered after the forum has moved.
Establish what the community actually references
Gallery entries and filebase items are frequently the most-linked content in a community, because they are what people come for. Identifying that before deciding what to carry prevents a decision made on volume alone.
Assess every package
Each installed package given a fate before the cutover: rebuilt, replaced, or dropped with the reason. The WoltLab ecosystem is large and a board with years behind it will have accumulated from it.
Derive the verification from the source
Per-type counts and relationship checks across every application, constructed before converting. With several applications and a version whose semantics were established rather than documented, the verification is what establishes the conversion is correct.
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.
Source identification
- The exact version and generation, and what the data actually contains
- Installed applications, with volume and relationships per application
- Installed packages, with a fate for each
- What the community's content depends on, established before deciding what to carry
- What could not be established, stated plainly
Migration
- A converter for this version and these applications, in resumable stages
- Forum content, members and relationships converted
- Each application's content mapped or deliberately not carried
- Packages rebuilt, replaced or removed
- URL inventory across the forum and every application, with redirect mapping
Cutover and after
- Staged cutover with a tested return path
- Reconciliation per application against source-derived checks
- Crawl, indexation and impression tracking against a baseline
- A written record of what was carried, rebuilt and dropped
- What the community should expect to find in a different place
Architecture and technology
What makes WoltLab several sources rather than one
- Major generations whose data models differ enough that a converter for one does not read another
- Applications installed separately, each with its own tables and relationships
- A package system whose plugins are outside the platform and in no converter
- Version histories that leave structures from several generations in one database
- Address patterns per application, each needing its own mapping
What a suite migration has to account for
- Which applications are installed, and which are actually used
- How much content each holds, and what depends on it
- How each references members and forum content
- Which of it the community actually links to
- What is carried, what is rebuilt elsewhere, and what is dropped
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 known platform
vBulletin, Invision, phpBB and Discourse each have their own positions.
Forum migration to XenForoThe gap is tooling rather than understanding
Importers for a model that is understood.
Custom forum importersSearch visibility is the main risk
Redirect mapping across a suite's wider URL estate.
Forum SEO migrationFrequently asked
Do you support WoltLab migrations?
That question has no single answer, which is the point of this page. WoltLab's major generations differ enough in their data model that a converter written for one does not read another, and the suite's applications are separate products with their own tables. So the honest answer is that support is per version and per application, established by looking at your installation — not asserted as a general capability. We have worked on a bespoke importer for one of these applications, and that establishes what that one required; it does not establish anything about a different version.
Why can't you just say whether it is supported?
Because a general claim would be a guess dressed as a capability: one bespoke gallery importer is not proof of every WoltLab version. Generalising from one engagement to a whole product line is how a migration gets scoped against an assumption and discovered to be a different project partway through. What we can do is identify your version and applications, establish what the data looks like, and tell you what the conversion involves for that installation specifically.
What about our gallery and filebase?
They are separate migrations sharing a cutover, not part of the forum migration. Each application has its own tables, its own relationships into members and forum content, and its own address patterns. They are also frequently where a community's most-referenced content lives, because a gallery or filebase is often what people come to the site for — so what the community actually links to is established before any decision about what to carry, rather than deciding on volume alone.
What happens to our installed packages?
Each one is assessed and given a fate before the cutover: rebuilt as a XenForo add-on, replaced by an equivalent, or removed with the reason recorded. Anything installed through WoltLab's package system is outside the platform itself and is not carried by any converter, so the list has to come from the audit rather than from the conversion. A board with years behind it will have accumulated from the ecosystem, and a feature that is simply absent afterwards is one the community notices and nobody can explain.
How do you handle the version differences?
By establishing the model from the data rather than from the version number. A board that has been updated across generations carries structures from each of them, so what is installed describes the software and not the data. The analysis establishes the tables, relationships and encoded states as they actually are for this installation, and the converter is written against that. Work done on another version is treated as evidence about that version, not as a template — which is the discipline this page is built 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.