Moving a bespoke forum onto XenForo
There is no importer for a forum somebody built. The work is reading a data model nobody documented, working out what its columns mean, and constructing the verification that a reference implementation would otherwise have given you.
A custom forum encodes its meaning in the code, not the schema
A bespoke forum was written for its own requirements by people who knew what the columns meant. Ten years later the schema is the only surviving documentation, and it does not say that a status of 3 means deleted-but-visible-to-moderators, or that a user with a null group and a row in a second table is a banned member. Every one of those meanings has to be established before it can be converted, and the establishing is the project.
- The forum was built in-house or by an agency that no longer exists
- The original developers are unavailable and the documentation is absent or wrong
- The schema has columns nobody can confidently explain
- Status flags, soft deletes and moderation states are encoded in integers
- Content lives across tables joined in ways the application decided
- There are members in states the current interface does not produce
- Nobody can say how many posts there actually are
- A previous migration attempt produced content that was subtly wrong
The people who usually bring us this problem
An owner of a forum nobody can maintain
The original developers are gone and the platform cannot be updated or extended.
Someone whose previous migration produced wrong data
Content arrived but something about it was subtly incorrect, and the cause has not been established.
An owner who needs the data understood
Before anything is moved, you need to know what is actually in the database and what its states mean.
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.
There is no reference implementation to check against
With phpBB or vBulletin the target's own importer and the source's own semantics give you something to compare. With a bespoke source there is nothing: the only way to know the conversion is correct is to construct the verification yourself, before converting, because afterwards there is no baseline to check against.
Every encoded meaning is a decision nobody recorded
Status integers, soft deletes, moderation flags, hidden content, banned members, orphaned rows from removed features. Each is a rule the application enforced and the schema does not state. Deriving them means reading what remains of the code, examining the data's own distribution, and confirming with whoever still remembers.
The data contains states the application cannot produce
A forum that has been modified, patched and partly replaced accumulates rows its current code would never create: members with impossible combinations, posts attached to missing threads, content from a feature that was removed. These have to be identified and given a decision, because converting them faithfully reproduces a decade of accidents in the new platform.
The source's quirks become the destination's problems
Anything carried across faithfully arrives in XenForo and stays. The migration is the only opportunity to reconcile anomalies, and it is cheaper to decide what to do with them here than to explain them to a community afterwards.
Capabilities
Each of these is work we carry out, not an area we advise on.
Data model reverse-engineering
Establishing what each table, column and state actually means: by reading whatever code survives, by examining how the values distribute across the real data, and by confirming with anyone who remembers. The output is a documented model where previously there was a schema.
Meaning extraction from encoded states
Status integers, flags, soft deletes, moderation states and permission encodings translated into statements about what they represent. This is the work that decides whether the conversion is correct, and it is done before any conversion is written.
Anomaly identification
Rows the application could not have produced: impossible state combinations, orphans, content from removed features, members in states no longer reachable. Each identified and given a decision rather than converted faithfully.
Verification construction
The checks that will establish the conversion is correct, built before it runs — per content type, derived from the source's own counts and relationships. Where no reference exists, the verification is the only thing standing between a plausible migration and a correct one.
Importer development
A converter written for this source specifically, in stages that record their progress and can be resumed, with the mapping from the source's model to XenForo's documented as it is written.
Content and relationship conversion
Threads, posts, members, private messages and the relationships between them, with the relationships treated as structure rather than as fields — the part a bespoke model most often encodes in ways a generic tool would miss.
Members, permissions and states
The source's own model of who can do what, translated into XenForo's groups and permissions, with the states the current application cannot produce given a decision rather than a mapping.
Cutover, reconciliation and the decision record
A staged cutover with a tested return path, reconciliation against the constructed verification, and a written account of every interpretation made — which is the document that tells the community what its own history meant.
Engineering methodology
The sequence is deliberate. The order is usually what determines whether the work holds or has to be repeated.
Establish the model before writing any conversion
What each column and state means, documented and confirmed. On a bespoke source this is most of the work, and a conversion written before it is a conversion built on guesses that will be discovered as errors later.
Read the data's distribution, not only the schema
A status column with four values in the schema and two in practice tells you which branches are dead; one with a value nobody expected tells you the schema is incomplete. The distribution is evidence, and it is frequently the only evidence available.
Construct the verification before converting
Per-type counts, relationship integrity, and the specific properties that establish correctness for this source. Afterwards there is no baseline, so the checks have to exist first — which is the opposite of the order a migration with a reference implementation can afford to work in.
Decide every anomaly, rather than carrying it faithfully
Orphans, impossible states and content from removed features are given a decision: converted, repaired, or excluded with the reason recorded. A faithful conversion of a decade of accidents produces a new platform full of them.
Document the interpretation as it is made
Each meaning derived, its evidence, and the decision taken. This is what makes the conversion auditable, and it is what a community needs afterwards to understand what its own records meant.
Convert in resumable stages and reconcile each
Content, then relationships, then the dependent structures. Each stage verified against the constructed checks before the next begins, so an interpretation error is found where it affects one type rather than the whole estate.
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 and verification
- The data model documented: what each table, column and state means, with the evidence
- Anomalies identified, with a decision for each
- The verification checks, constructed before any conversion is written
- The mapping from the source's model to XenForo's, written down
- What could not be established, stated plainly
Importer and conversion
- A converter written for this source, in resumable stages
- Content, relationships and members converted
- Permissions and states translated, with unreachable states decided
- Anomalies handled as decided rather than carried faithfully
- Progress recorded per stage, so an interruption costs a stage
Cutover and record
- Staged cutover with a tested return path
- Reconciliation against the constructed verification
- A written record of every interpretation and its evidence
- URL inventory and redirect mapping where the source had its own addresses
- What the community should know about its own history
Architecture and technology
What has to be established about a bespoke source
- What each status, flag and state integer represents
- Where soft deletes and hidden content are encoded
- How members' states are represented, including bans and inactive accounts
- Which relationships live in join tables and what they mean
- Which tables belong to features that no longer exist
- Which rows the current application could not have created
Why this source is the hardest to verify
- No reference implementation to compare the conversion against
- No documented semantics for the columns being converted
- No importer to establish what is expected to arrive
- Relationships encoded in ways specific to the original application
- A decade of anomalies that look like data
- Nobody remaining who can confirm an interpretation from memory
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 conversion needs a custom importer only
Where the model is understood and the gap is tooling.
Custom forum importersSearch visibility is the main risk
Redirect mapping at volume and indexation recovery.
Forum SEO migrationThe volume is the constraint
Transfer windows, staging and reconciliation at scale.
Large forum migrationFrequently asked
Can you migrate a forum nobody has documentation for?
Yes, and that is the normal case for a bespoke source — the schema is usually the only surviving documentation and it does not say what its columns mean. The work is establishing that meaning: from whatever code survives, from how the values actually distribute across the data, and from anyone who still remembers. That produces a documented model where previously there was a schema, and it is most of the engagement rather than a preliminary to it.
How do you verify a migration with nothing to compare against?
By constructing the verification before converting rather than after. With a known platform there is a reference implementation and an importer that establish what is expected; with a bespoke source there is nothing, and afterwards there is no baseline. So the checks are derived from the source's own counts and relationships, written down first, and the conversion is reconciled against them. It is the opposite order from a migration that has a reference, and it is the only order that works here.
What do you do with data that looks wrong?
Identify it and decide, rather than converting it faithfully. A forum that has been modified and partly replaced over a decade contains rows its current application could not have produced: members in impossible combinations, posts attached to threads that no longer exist, content from a feature that was removed. Each is given a decision — converted, repaired, or excluded with the reason recorded. A faithful conversion of those accidents produces a new platform full of them, and the migration is the only opportunity to reconcile them cheaply.
Do you need the original source code?
It helps considerably and it is not always available. Where any of it survives it establishes what the encoded states mean directly, which is the fastest route to the model. Where none survives, the meaning is derived from the data's own distribution — which values occur, in what combinations, in what proportions — and confirmed against what the community's members and moderators remember about how the platform behaved. That is slower and it is usually sufficient, with the parts that remain uncertain stated as uncertain rather than presented as established.
Who owns the data, and does that matter?
It matters, and it is a precondition rather than something we can resolve. Migrating a forum means extracting its content, its members and its private messages, which requires the right to do so — whether the platform was built in-house, by an agency, or under a licence whose terms address the data. It is worth establishing before the engagement rather than during it, and where there is any doubt about who holds that right, that is a question for you and your advisers rather than one we can answer.
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.