XenForo ships official importers for seven platforms, and four of them stop at a version older than what the vendor currently ships.
That is the first thing to check before you price a migration or book a weekend for it. The gap is not obvious from the outside. It shows up in the version numbers.
Before you commit, get familiar with the thread and node model you are migrating into, because your old category tree will not map across one-to-one. Some content survives the trip untouched. Other content arrives reshaped.
vBulletin is the widest gap. The importer stops at 5.3, while vBulletin itself now ships 6.2, released in March 2026. Everything from 5.4 upward sits outside the official path.
Invision tells a shorter version of the same story. XenForo covers the IPS 4 line, and Invision Community has moved on to 5, reaching 5.0.19 in July 2026.
SMF is a smaller gap and still a real one. The importer targets SMF 2.0, and SMF has been shipping the 2.1 line since February 2022, currently 2.1.6.
Discourse is the strange case. XenForo lists Discourse 3.x, and Discourse dropped that numbering entirely for calendar versions, so a current install reports something like 2026.1 instead.
Two sources are genuinely aligned. phpBB 3.3 remains the live line with no version 4 released, and MyBB is still on 1.8. Run either of those, and you are on the supported path.
The XenForo 2.x entry on that list is not a typo. It exists so you can merge one XenForo board into another, which is how most forum consolidations actually happen.
One more detail deserves attention. Only a single importer of the seven has a system-specific notes page, and it belongs to vBulletin. The other six ship with no documented caveats, which is not the same thing as having none.
None of this means a newer board cannot move. It means nobody has committed to making it work, so you are buying custom migration work or downgrading the source first.
Start with backups of both the database and the files, on both servers. An import is not a reversible operation, and there is no undo button waiting at the end of it.
Threads, posts, and members transfer cleanly. The friction is in everything that is not a thread.
vBulletin FAQ pages can arrive as XenForo help pages, which is the closer match of the two options, but any parent and child relationships between them are lost. A flat set of pages replaces your structured FAQ.
Blogs convert rather than transfer. Each user blog becomes a forum-style node, entries become threads, and comments become replies. You have to name that node during setup, and there is no way around it.
vBulletin 5 hands you a fork during setup. Bring across forums, blogs, and groups together, or take only forums, threads, and posts and leave the rest where it is. The second option gives you a tidier board and costs you real content.
vBulletin 4 blog attachments need their own separate import step, run after the older blog attachments have gone through. Skip that step and the files are simply absent.
Attachments and avatars are the practical bottleneck. If your old board stored them on disk rather than in the database, you have to supply the full system path to each folder.
That one requirement shapes the whole plan. XenForo advises keeping the source data and the destination on a single server for the fastest run, which is awkward when the old host and the new host are different companies.
Empty it or drop it and the redirects stop working immediately, with no way to repair them.
This catches tidy administrators more than careless ones. A year after a successful move, the table reads like leftover import junk, and clearing it out feels like good housekeeping.
It is not. Keeping your old thread URLs alive depends on that mapping for as long as anything on the internet still points at them, which for an established board is effectively forever.
Back it up with the rest of your database and leave it there. Once the source forum is gone, the mapping cannot be rebuilt from anything.
That is the first thing to check before you price a migration or book a weekend for it. The gap is not obvious from the outside. It shows up in the version numbers.
Before you commit, get familiar with the thread and node model you are migrating into, because your old category tree will not map across one-to-one. Some content survives the trip untouched. Other content arrives reshaped.
Four of the seven import sources have moved on
The documented list covers XenForo 2.x, vBulletin 3.6 to 5.3, IPS 4.x, phpBB 3.2 to 3.3, SMF 2.0, MyBB 1.8 and Discourse 3.x. Read those version numbers slowly.vBulletin is the widest gap. The importer stops at 5.3, while vBulletin itself now ships 6.2, released in March 2026. Everything from 5.4 upward sits outside the official path.
Invision tells a shorter version of the same story. XenForo covers the IPS 4 line, and Invision Community has moved on to 5, reaching 5.0.19 in July 2026.
SMF is a smaller gap and still a real one. The importer targets SMF 2.0, and SMF has been shipping the 2.1 line since February 2022, currently 2.1.6.
Discourse is the strange case. XenForo lists Discourse 3.x, and Discourse dropped that numbering entirely for calendar versions, so a current install reports something like 2026.1 instead.
Two sources are genuinely aligned. phpBB 3.3 remains the live line with no version 4 released, and MyBB is still on 1.8. Run either of those, and you are on the supported path.
The XenForo 2.x entry on that list is not a typo. It exists so you can merge one XenForo board into another, which is how most forum consolidations actually happen.
One more detail deserves attention. Only a single importer of the seven has a system-specific notes page, and it belongs to vBulletin. The other six ship with no documented caveats, which is not the same thing as having none.
None of this means a newer board cannot move. It means nobody has committed to making it work, so you are buying custom migration work or downgrading the source first.
What a vBulletin to XenForo import quietly leaves behind
The importer lives in the admin control panel under Tools, listed as Import data. You choose the source software before anything else, and that choice decides what the rest of the setup asks you for.Start with backups of both the database and the files, on both servers. An import is not a reversible operation, and there is no undo button waiting at the end of it.
Threads, posts, and members transfer cleanly. The friction is in everything that is not a thread.
vBulletin FAQ pages can arrive as XenForo help pages, which is the closer match of the two options, but any parent and child relationships between them are lost. A flat set of pages replaces your structured FAQ.
Blogs convert rather than transfer. Each user blog becomes a forum-style node, entries become threads, and comments become replies. You have to name that node during setup, and there is no way around it.
vBulletin 5 hands you a fork during setup. Bring across forums, blogs, and groups together, or take only forums, threads, and posts and leave the rest where it is. The second option gives you a tidier board and costs you real content.
vBulletin 4 blog attachments need their own separate import step, run after the older blog attachments have gone through. Skip that step and the files are simply absent.
Attachments and avatars are the practical bottleneck. If your old board stored them on disk rather than in the database, you have to supply the full system path to each folder.
That one requirement shapes the whole plan. XenForo advises keeping the source data and the destination on a single server for the fastest run, which is awkward when the old host and the new host are different companies.
The redirect table is permanent, not scaffolding
The import writes a log table that maps old content IDs to new ones. That table is what lets old links reach the right thread on the new software.Empty it or drop it and the redirects stop working immediately, with no way to repair them.
This catches tidy administrators more than careless ones. A year after a successful move, the table reads like leftover import junk, and clearing it out feels like good housekeeping.
It is not. Keeping your old thread URLs alive depends on that mapping for as long as anything on the internet still points at them, which for an established board is effectively forever.
Back it up with the rest of your database and leave it there. Once the source forum is gone, the mapping cannot be rebuilt from anything.
