Almost every forum can be migrated to XenForo. What differs is which version of your current software the platform's own importer reads, and whether your migration is therefore a bounded import or a conversion built for your schema. That answer is published below rather than discovered during the project.
A community's history lives in a schema that was designed for a different piece of software, and every platform has made different decisions about how threads, permissions, messages and attachments are stored. Some of those decisions map cleanly onto the target; others have no equivalent at all. The migration is therefore not one process applied to different inputs. It is a different project per source, and establishing which one you have is the first piece of work.
The current platform is not where the community should be, and you need the move scoped honestly rather than quoted optimistically.
A support date has made the decision for you, and you need to know what moving actually requires before committing.
You have taken on a forum with a long history and no documentation, and you need to establish what is there before deciding anything.
Engineering faults are rarely confined to the engineering layer. These are the commercial consequences we see most often.
A source within the target platform's importer coverage follows a known, bounded path. One outside it needs the conversion built for that schema. Assuming the wrong one produces an estimate that is wrong in the direction that hurts.
Threads, private messages, attachments and member accounts are what the community is. Losing a category of them, or leaving them reachable but unlinked, degrades the thing the migration existed to protect.
Every discussion address changes. Without a complete redirect strategy the community's accumulated authority points at addresses that return nothing, and the decline is gradual enough to be attributed to something else.
A new interface is forgiven quickly. A lost post, a broken private message thread or a fortnight of disruption is not. Migration quality is assessed by the community, in the first week, against the platform they remember.
Each of these is work we carry out, not an area we advise on.
Which source versions the target platform's own importer reads is published on this page, with the document it came from and the day it was read. Where your version falls inside that list the migration is a bounded import; where it falls outside, it is conversion work built for your schema. Both are achievable and they are not the same project, which is why the answer is given before anything is scoped.
See the coverage matrixEstablishing which platform and which version, from the installation, not from what anyone believes. Extensions, direct modifications and undocumented customisations are catalogued, because they determine what can be converted and what has to be decided.
Determining plainly whether the source falls inside the target platform's own importer coverage. That answer is given in writing before anything is scoped, because it is the difference between a supported import and custom conversion work.
Where the source falls outside coverage, building the conversion for that schema, including the legacy structures a general-purpose importer cannot know about. This is genuinely different work from running a supported import, and it is priced and sequenced as such.
A written decision for each source construct: forums to nodes, threads to threads, groups to permission sets, private messages, subscriptions, polls, attachments, and an explicit outcome for the structures with no direct equivalent.
Accounts, primary and secondary group memberships, moderator assignments and custom permission sets mapped onto the target's model. Years of permission configuration are the least visible thing to get wrong and the most disruptive when it is.
A complete inventory of indexable URLs and a rule for each, activated with the new platform rather than after it. The gap between the two is where search visibility is lost.
Repeated runs against a copy of the real database, with counts compared per content type between source and destination. A migration without reconciliation has an unknown error rate, which is not a defensible position to take a community into.
A rehearsed single cutover with a tested rollback and a defined trigger, followed by discussion, messaging, attachments and permissions exercised with real data: plus search signals monitored after the move.
The sequence is deliberate. The order is usually what determines whether the work holds or has to be repeated.
Before scope, before timeline, before anything is promised. Every downstream estimate depends on whether this is a supported import or custom development, and a plan built on the wrong assumption is worse than no plan.
Extensions and undocumented modifications change what can be converted and how. Anything the source has drifted into has to be understood before its content can be mapped, because the mapping depends on what produced it.
The failures that surface late are the decisions nobody made: a reputation system with no equivalent, message semantics that differ, an attachment model that lives on the filesystem, not in the database. Each gets a written outcome: converted, approximated with the limits stated, or excluded with the consequence made clear.
The migration runs against a copy of the production database repeatedly. Rehearsal is where the parts that do not convert are found, and finding them there costs nothing but time.
Source against destination, per content type. Totals, spot checks, and each discrepancy either resolved or explicitly accounted for. Counting is what turns 'it looks right' into a statement that can be checked.
The final delta, the DNS change and the redirect activation are one rehearsed sequence. Afterwards, the engagement continues through the weeks in which real members find the edges that testing did not.
Documentation is part of what you receive. On most of these engagements a large part of the value is a defect report precise enough for another team to act on.
This decides the shape of the engagement, so it is answered before anything is scoped.
| Source platform | Versions inside coverage | What that means for the project |
|---|---|---|
| vBulletin | 3.6 – 5.3 | Official importer. Releases 2.x and 6.x fall outside it and are custom conversion. |
| Invision Community (IPS / IP.Board) | IPS 4.x | Official importer. IPS 5 and older IP.Board generations fall outside it and are custom conversion. |
| phpBB | 3.2 – 3.3 | Official importer. phpBB 2.x and 3.0.x fall outside it and are custom conversion. |
| Simple Machines Forum | 2.0 | Official importer. SMF 1.x falls outside it and is custom conversion. |
| MyBB | 1.8 | Official importer. MyBB 1.4 and 1.6 fall outside it and are custom conversion. |
| Discourse | 3.x | Official importer. Earlier Discourse releases fall outside it, and the structural differences are decisions rather than conversions. |
| WoltLab (WBB / Suite) | None | No official importer. Custom conversion per version, because the major versions changed the data model. |
| Bespoke or abandoned platforms | None | No importer. The data model is read from the installation and the conversion is built for it. |
Coverage moves, and this list is a snapshot, not a standing promise. We confirm your version from the installation before quoting. A version outside this list is not a refusal: it changes the shape of the project, which is a different answer and a more useful one.
Engagements where this capability was the substance of the work.
Since 2019, Soludome has managed infrastructure and platform operations for one of Spain's largest online communities. The work covers server and performance optimisation, CDN architecture, load balancing and site security under sustained traffic.
An established community platform had accumulated three separate problems that compounded each other: page loads that had degraded with growth, search visibility that had not kept pace with the community's authority, and a security posture that had not been revisited as the platform's profile grew. The engagement addressed all three concurrently.
These overlap at the edges. Sending you to the right page is more useful than having you work it out.
A source with its own importer coverage position and its own version constraints.
vBulletin to XenForo migrationOne page covers Invision, IPS and IP.Board; the version position differs.
Invision to XenForo migrationA source close enough to the target that the migration usually goes well, with the exceptions in permissions and attachments.
phpBB to XenForo migrationTwo platforms that disagree about what a thread is, so the differences are decisions rather than conversions.
Discourse to XenForo migrationNot one source: the major versions changed the data model, and the applications beyond the forum are separate migrations.
WoltLab to XenForo migrationCovered by the target's importer in some versions and not others; the version decides which, and outside it the conversion is built.
Custom forum importersA conversion built for a schema nothing covers off the shelf.
Custom forum importersLong-running imports, repeated delta loads and a cutover window that has to be rehearsed, not estimated.
Large forum migrationRedirects, canonicals and indexation recovery as a project in itself.
Forum SEO migrationOur client reviews are published on our public Google Business Profile. We reproduce them verbatim, with attribution, so you can read the original feedback and verify it at the source.
Soludome recently handled a forum upgrade and migration for me, and they delivered outstanding results. Communication was excellent, which was crucial as we worked through various tasks, testing, and post-launch issues. I highly recommend Soludome and will definitely rely on their expertise for future projects.
Soludome recently handled a critical database migration for us, and we couldn't be more impressed with their professionalism, excellent communication, and timely execution. Highly recommended!
XenForo's own importer reads vBulletin 3.6 to 5.3, Invision Community (IPS) 4.x, phpBB 3.2 to 3.3, Simple Machines Forum 2.0, MyBB 1.8 and Discourse 3.x. The full table, with the versions each one covers and where the coverage stops, is on this page and names the document it came from. Everything outside those versions (WoltLab, bespoke forums, older releases, and additional applications on an otherwise supported platform) is conversion work rather than a supported import, which is a different project.
Yes, at specific versions: Simple Machines Forum 2.0 and MyBB 1.8 are both inside XenForo's official importer coverage. SMF 1.x and MyBB 1.4 or 1.6 are not, and a community on one of those is a custom conversion: usually a smaller one than the platform's age suggests, because both are well documented, but a conversion nonetheless. We do not publish a separate page for either yet; the assessment is the same one described here and on the custom importers page.
Neither is inside XenForo's official importer coverage, and both are commonly described as if they were. vBulletin 6 and IPS 5 installations need the conversion built for those schemas, which is genuinely different work from running a supported import: more scope, more time, and knowable from the version rather than discovered part-way through. Anyone quoting either as a standard import has not checked, and it is worth asking them which importer they intend to run.
Almost always, and the honest qualification is that the answer depends on the source. Sources inside the target platform's importer coverage follow a known path. Sources outside it need the conversion built specifically, which is development work rather than configuration. Both are achievable; they are different projects with different scopes, and establishing which one yours is comes before we quote anything.
No, and we would rather say that plainly than imply otherwise. The target platform's own importer covers a defined set of sources and versions; anything outside that set is custom work. If your source is one we have built for before we will say so, and if it is one we have not we will scope it as the development project it is rather than discovering that part-way through.
They are at risk in any platform move, because every URL changes. The mitigation is completeness: a full inventory of existing addresses, a redirect rule for each, and canonical signals that agree with the new structure. Done properly a migration can hold visibility and sometimes improve it, because the new platform is faster and structurally cleaner. Done without a redirect strategy the loss is real and arrives slowly enough to be misattributed.
A short window at cutover, with everything rehearsed in advance against a copy of the live database. The rehearsal runs happen while the forum keeps serving, and the bulk of the data moves before the window; the window handles what changed since. We will not promise zero downtime: the cutover is a real event, and the honest measure of its quality is preparation and a tested rollback.
Yes, if they are planned for, and they are treated as first-class content rather than as an afterthought. They are frequently the largest part of the database and the part most likely to be mishandled. Attachments may live on the filesystem, not in the database, which means an import that reads only the database will silently omit them. Both are explicitly in scope and both are reconciled by counting before cutover.
Describe what is happening. If we are not the right people for it, we will say so.