XF 2.3 vBulletin board imported in XenForo: what areas are important to test?

[Grover]

A while ago my vBulletin 3.8.11 database was imported into a test board, powered by Xenforo 2.3.3.

I am in the process now of starting to test-drive this import and I was wondering which areas are important to test, so that one can be sure the import was successfully done?

I’ve already asked ChatGPT (posting #2) and Gemini (posting #3), but I thought it would be good to ask for advice in this community too, since there must be enough experienced webmasters overhere who have gone through the same proces. (Because, let’s face it, who wouldn’t want to migrate from vBulletin to XenForo? ).

If you have any testplan or tips to share, it would be helpful.

 

[Grover]

Prompt
“I have imported a vBulletin 3.8.11 database into the latest Xenforo. Now I want to test if the import went well. What areas of the forum can you advice me to test, so I can be sure the import was successfully done?”

ChatGPT
Got it, Grover! When you’re testing a XenForo import from a vBulletin 3.8.11 database, you want to make sure that all core data migrated correctly and the forum functions properly. Here’s a detailed checklist broken down into categories:

---

1. User Accounts​

• Usernames & Display Names: Check if usernames appear correctly, including special characters.
• Email Addresses: Ensure emails imported correctly.
• User Groups & Permissions: Verify that user group memberships match the old forum.
• Avatars & Profile Pictures: Make sure they are visible and correctly linked.
• Passwords: Test logging in with a few accounts. Imported passwords should work (if you imported hashes correctly).

---

2. Forums & Categories​

• Forum Structure: Check that all categories, subforums, and permissions match the old layout.
• Forum Settings: Look at descriptions, post count permissions, moderation settings.
• Visibility & Access: Confirm that restricted forums are still restricted.

---

3. Threads & Posts​

• Thread Titles & Content: Spot-check threads in multiple forums to ensure formatting, BBCode, and line breaks are preserved.
• Post Author: Confirm that posts are attributed to the correct user.
• Post Dates & Timestamps: Make sure dates are accurate.
• Post Counts: Verify that user post counts match the original forum.
• Attachments: Check if images, files, and other attachments are visible and linked properly.
• Thread Views & Last Post Info: Confirm views and last-post details are imported correctly.

---

4. Private Messages (PMs)​

• Inbox & Sent Items: Make sure messages appear correctly.
• Attachments: Check PM attachments, if any.
• Read/Unread Status: Ensure status migrated correctly.

---

5. Polls​

• Questions & Options: Verify polls migrated with their options.
• Votes: Check that votes are associated with the correct users.
• Results Display: Ensure poll results display correctly.

---

6. Reputation / Likes​

• Reputation or Likes: Confirm that likes/reputation points from vBulletin posts were imported and appear correctly.
• User Totals: Ensure totals per user are accurate.

---

7. Attachments & Media​

• Images / Files: Make sure attachments are downloadable or viewable.
• Image Thumbnails: Confirm thumbnails work correctly.

---

8. Forums Functionality​

• Search: Test forum search for threads, posts, and users.
• Profile Pages: Ensure user profiles display all info (bio, signature, etc.).
• Notifications / Alerts: Check if alerts and notifications are working.
• Forum Breadcrumbs & Links: Confirm navigation works and URLs are correct.

---

9. Additional Items​

• Moderation Logs: Check imported logs if applicable.
• Custom User Fields: Verify any custom profile fields.
• BBCode & Smilies: Make sure BBCode renders correctly and emoticons show.
• SEO / URLs: Optional, but check if friendly URLs migrated correctly.

---

Tip: Start by spot-checking a few users and threads, then test forums with heavy activity (lots of posts, attachments, polls) to catch potential edge cases.

 

[Grover]

Prompt
“I have imported a vBulletin 3.8.11 database into the latest Xenforo. Now I want to test if the import went well. What areas of the forum can you advice me to test, so I can be sure the import was successfully done?”

Gemini
Migrating a forum is a complex process, and even with a successful import, there are many details to verify. Here's a comprehensive checklist of areas to test to ensure your vBulletin 3.8.11 database was successfully imported into XenForo.

1. User Data and Accounts​

• User Count: Compare the total number of users in your vBulletin database to the number of users in XenForo. The counts should be very close, if not identical.
• User Profiles:
  • Log in as a few different users (including admins, moderators, and regular users).
  • Check their display names, avatars, and signatures.
  • Verify that custom profile fields (if you had any) have been imported correctly.
  • Ensure their post and thread counts are accurate.
• Permissions:
  • Check that user group permissions have been mapped correctly. An admin in vBulletin should be an admin in XenForo. A moderator should be a moderator.
  • Test specific permissions for different user groups, such as the ability to post in certain forums, edit their own posts, or start new threads.
• Private Messages: Check a few user accounts to ensure their private messages have been imported and are readable.

2. Forum Structure and Content​

• Forum Hierarchy:
  • Verify that the forum and sub-forum structure is intact and appears correctly in XenForo.
  • Check the names and descriptions of your forums.
• Thread and Post Count:
  • Compare the number of threads and posts in your vBulletin database to the number in XenForo.
  • Do a spot-check on several forums to ensure the thread and post counts on the front end are accurate.
• Threads and Posts:
  • Go to various threads and check that the posts are in the correct order.
  • Ensure the post content is intact, including text formatting, quotes, and links.
  • Check that the correct user is associated with each post and that the post times are accurate.
  • Pay close attention to older posts. Sometimes, very old or obscure formatting can cause issues.
• Attachments and Images:
  • Check posts that contain file attachments (like PDFs, ZIP files, etc.). Try to download them to ensure they are accessible and not corrupted.
  • Check posts with inline images and user-uploaded attachments to make sure they are displaying correctly.
• Smilies/Emoticons: Verify that your vBulletin smilies have been imported and are usable in the XenForo editor. XenForo's importer for vBulletin can generate a smiley XML file that you then import manually. Make sure this step was completed.
• Polls: If you had polls in vBulletin, check a few to see if they were successfully migrated. Test to see if you can vote and view the results.

3. Moderation and Administration​

• Moderation Logs: Check if moderation actions (such as edited posts, deleted threads, etc.) from vBulletin have been imported into the XenForo moderation logs.
• Moderator Tools: Log in as a moderator and test the tools they use most often, such as editing posts, deleting threads, or moving threads between forums.
• User Ban List: Verify that banned users from vBulletin have been imported and are still unable to access the forum.
• Custom BB Codes: Check if any custom BB codes you created in vBulletin have been imported and are functioning as expected. This is a common area for migration issues, so you'll want to test them thoroughly.

4. Search and Redirection​

• Search Functionality:
  • Run a few searches for users, threads, and posts.
  • Test both simple and advanced searches.
  • Ensure the results are relevant and accurate.
• URL Redirections:This is one of the most critical steps, as it prevents loss of SEO and broken links from external sites.
  • Install the "XenForo redirects for vBulletin" add-on.
  • Verify that old vBulletin URLs (e.g., showthread.php?t=123) correctly redirect to the corresponding new XenForo URL.
  • Check for redirects for different content types (threads, posts, user profiles, forums).

5. General Functionality​

• Email System:
  • Test user registration and password recovery emails to ensure they are being sent and received correctly.
• RSS Feeds:
  • If you had RSS feeds in vBulletin, check if they have been migrated or if you need to set up new ones in XenForo.
• Error Logs:
  • After your tests, check the XenForo Admin Control Panel's error log for any migration-related errors. This can help you pinpoint issues that may not be immediately obvious on the front end.

By working through this list, you can be confident that the vast majority of your data has made the journey successfully from vBulletin to XenForo.

 

[Digital Doctor]

The redirection scripts are important.

of course,

chatgpt got that one.

 

[Grover]

Usergroup changes for administrator after importing vBulletin to Xenforo

Interesting…

I asked ChatGPT:

“In vBulletin, my account (as the Webmaster) is set up with Administrators as the primary usergroup, and I don’t belong to any secondary groups. However, after importing the forum into XenForo, my account shows Registered as the primary usergroup, while Administrative and Moderating are listed as secondary groups. Can you explain the difference?”
—-

Answer from ChatGPT:

Got it Let me explain the difference.

In vBulletin, your account’s primary usergroup is what really matters. If your primary group is Administrators, then that group defines your permissions, title, and visibility. Secondary usergroups in vBulletin are optional — they can be used to layer on extra permissions, but many admins don’t even use them.

In XenForo, things work differently:

• Every user is required to have Registered as their primary group. That’s the base group all members belong to, and it defines the “minimum” set of permissions for everyone.
• Administrative and Moderating rights are then added on through secondary groups (like Administrative and Moderating). This allows permissions to be layered consistently.

So, when your forum was imported from vBulletin into XenForo, the migration tool restructured the groups to match XenForo’s model:

• You were placed into Registered as the primary group (since that’s required).
• Your Administrator and Moderator roles were added as secondary groups, giving you the extra powers on top of the base “Registered” permissions.

In short: vBulletin relies more on the primary group, while XenForo uses a layered permission system with Registered as the foundation and other roles stacked as secondary groups.

Would you like me to also show you a permissions example (like how posting/viewing permissions stack) to make it crystal clear?

 

[Digital Doctor]

Every user is required to have Registered as their primary group

It's weird.
I suspect there is a database permissions programming reason why Xenforo started with this but no one from vBulletin likes it (at first).

 

[Grover]

Would you like me to also show you a permissions example (like how posting/viewing permissions stack) to make it crystal clear? - ChatGPT:

vBulletin Example​

Suppose your account has:

• Primary group: Administrators
• Secondary groups: none

Your permissions come entirely from the Administrators group. You don’t need to be in “Registered” or “Moderators” — the Administrator group alone gives you full access.

---

XenForo Example​

In XenForo, everyone must be in Registered as the primary group. So your setup after import looks like:

• Primary group: Registered
• Secondary groups: Administrative, Moderating

Now permissions are layered:

• Registered = baseline permissions (viewing threads, posting replies, editing own profile, etc.)
• Moderating = adds moderation powers (edit posts, delete posts, move threads, etc.)
• Administrative = adds admin powers (access Admin Control Panel, manage users, change settings, etc.)

---

How Permissions Stack​

Let’s say the permission is “Can delete posts”:

• Registered = (not allowed)
• Moderating = (allowed)
• Administrative = (allowed)

Final result for you = (allowed) because any secondary group with “yes” overrides a “no” in Registered.

---

So in XenForo, the Registered group is just the foundation. The real power comes from the stack of secondary groups. This makes permission management more flexible, since admins can combine groups instead of relying on one all-powerful primary group like in vBulletin.
—

Would you like me to also show you a table comparison between vBulletin and XenForo usergroup logic? That might make it even easier to see side by side.

 

[Grover]

Confirmed by the XF manual

User groups | Manual | XenForo

End-user documentation for XenForo

xenforo.com

 

[Grover]

Would you like me to also show you a table comparison between vBulletin and XenForo usergroup logic? That might make it even easier to see side by side. - ChatGPT

Here’s a side-by-side comparison of how vBulletin and XenForo handle usergroups:

---

vBulletin vs XenForo Usergroup Logic​

Feature / Concept	vBulletin	XenForo
Primary Usergroup	The main group that defines your permissions, title, and status.	Always Registered for every user — acts as the baseline group.
Secondary Usergroups	Optional; used to grant extra permissions on top of primary.	Required for roles like Administrative and Moderating.
Admins/Mods Setup	Admins can simply be put in the Administrators primary group.	Admins must be Registered (primary) + Administrative (secondary).
Permission Inheritance	Primary group = base; secondary can add on.	Registered = base; secondary groups stack permissions together.
Example: Delete Posts	If Primary = Admin → allowed. Secondary not needed.	Registered = , Moderating = → final = (secondary overrides base).
Flexibility	More rigid; relies heavily on primary group choice.	More modular; lets you combine groups for layered permissions.
Import Result	You were Primary = Admin, Secondary = none.	After import: Primary = Registered, Secondary = Admin + Mod.

---

So the key difference: vBulletin treats the primary group as the identity, while XenForo treats Registered as the universal base and layers roles as secondary groups.

 

[Grover]

Administrator imported in the Xenforo way, but Moderators are not

[correct] As the admin of my vBulletin website, my account (as the Webmaster) is set up with Administrators as the primary usergroup, and I don’t belong to any secondary groups. After importing the forum into XenForo, my account shows Registered as the primary usergroup, while Administrative and Moderating are listed as secondary groups. So this is according to XF's way of handling things.

[not correct] However, the moderators of my vBulletin website, their accounts are set up with Moderator as the primary usergroup, and Moderator - Full Blog Access as the secondary group (it's a redundant usergroup, since I don't use the blogs anymore). After importing the forum into XenForo, their moderator account shows Moderating as the primary usergroup, while Moderator - Full Blog Access is listed as secondary groups. So this is not according to XF's way of handling things. Because why are my Moderators not in the Registered primary group in XF now?

 

[Digital Doctor]

ChatGPT is good for learning to code / feeling your way through new software.

 

[Grover]

As I am almost totally new to Xenforo (believe it or not) when it comes to running a forum on it, I am a bit confused about Usergroup permissions.

As you can see in the attached PDF’s, almost all permissions for both the Administrative and Moderation Usergroups are set to ‘No’. It was automatically set like this after the vBulletin forum was imported into Xenforo.

If all these permissions are set to ‘No’, how can an administrator or moderator properly execute their administrative tasks? I must be overlooking something. Anyone that can shine some light on it?

 

[Grover]

(Not a bug) Possible bug in vBulletin importer

I am not sure (since I am not technically inclined on this level), but I might have discovered a bug in Xenforo’s vBulletin importer.

@Slavik took care of a test import for us. I am now testing this testboard and I immediately noticed this:

The avatar of my account (administrator) was changed into a photo of Ernie (yes, from Sesamestreet). All other users seemed to have their original avatar, so I thought maybe Slavik played a joke on me. Because my name on this Xenforo.com community is Grover (from… yup).

However, I coincidentally needed to test the permissions of a user that (let’s say) is called “Moderator-test-account-A”. So I went to the Analyze permissions function in the Xenforo testboard. But when I entered this account name, I got confronted with this error message:

“The requested user of could not be found”.

I was puzzled, because I know this moderator test account does exists. I checked my live vBulletin board and yes, this account did exists. However, it was not imported into the Xenforo testboard!

Then I saw that this account on my vBulletin board had the exact same Ernie avatar as well. And I also noticed that this account had the exact same e-mail address as my administrator account. I didn’t use the Moderator test-account for years and years, so I didn’t remember it had an Ernie avatar. And I was also not aware that I myself gave it (years ago) the same email address as the administrator account.

But the odd thing is still, that after my vBulletin board was imported into Xenforo, that the “Moderator-test-account-A” was not imported, but that my administrator account actually got the avatar that belonged to the moderator test account.

Once again, I am not sure if this is a bug, or a glitch in the import maybe. But I assume the first, since both accounts had the same email-address and maybe this causes confusion in the importer?

—

Edit.

See: https://xenforo.com/community/threa...rted-and-avatar-switched.233184/#post-1759010

It’s not a bug, but apparently how the importer works: it merges users with the same e-mailadres.

 

[Kirby]

If all these permissions are set to ‘No’, how can an administrator or moderator properly execute their administrative tasks? I must be overlooking something. Anyone that can shine some light on it?

vBulletin
Permissions can have values Yes and No; Yes overrides No.
It is not possible to set permissions for an indivudal user
When calculating effective permissions for a usergroup, permissions from all (primary and secondary) usersgroups are taken into account if option Allow members groups for the primary usergroup is set to Yes - if no only permissions from the primary usergroup
When customitzing permissions for a usergroup in a forum or category, all permissons for that usergroup must be customized.
Moderator permissions are their own system, they can only be set to individual moderators - not per usergroup.
Admin permissions are their own system and can only be set per admin.

XenForo
Permissions can have values Yes, No and Never - Yes overrides No and Never overrides both; a never can ... well ... never be overriden to anything else.
It is possible to set permissions for an individual user
When calculating effective permissions for a user or usergroup, permissions from all (primary and secondary) usersgroups are taken into account.
When customitzing permissions for a user or usergroup in a forum or category each permission can be customized individually while all others are left untouched.
Moderator permissions are just permissions as all other permissions, just flagged as being moderative permissions - they can be set on usergroup level or for individual moderators.
Admin permissions are their own system and can only be set per admin, usergroups don't matter.

So basically vBulletin permission system is a subset of XenForo, you can use permissions eaxactly like in vBulletin - but it's stronlgy recommended not to do that as it tends to create way too many permission entries which makes it difficult to maintain.

The importer tries to 1:1 map vBulletin permissions to XenForo, this also creates a waay too complicated setup.

Recommendation
Reset all permissions after import.
Start over with Registered, give them all permissions every regsitered user should have and make every user primary Registered.
Add additional usergroups as needed any only set permissions taht are different from Registered.
This gives you a clean, easy to understand and maintainable permission setup.

 

[Grover]

Thank you @Kirby for your explanation.

Admin permissions are their own system and can only be set per admin, usergroups don't matter.

Can you @Kirby confirm in the following AI explanation is correct?


I asked the following to Google Gemini:

It's about Xenforo. In the Admin control panel (ACP) section Groups & permissions, then Staff - Administrators, I am listed as a Super administrator. This gives me full access to the ACP backend functions, right?

At the same time I am also a member of the Administrative user group. A usergroup controls the frontend forum permissions, right? In that Administrative user group almost all permissions are set to 'No'.

I don't understand this. Shouldn't many of my permissions in the Administrative user group be set to "Yes"? Since my Super administrator status only applies to the ACP functions and not the frontend? Or does a Super administrator by default already have a ''Yes" permission for all the frontend permissions listed in the Administrative user group?

Answer from Gemini:

Your understanding is correct; your Super administrator status in the XenForo Admin Control Panel (ACP) gives you full access to all backend functions, while user groups control front-end forum permissions. You're right to question the conflicting permissions.

Your confusion stems from a common misunderstanding of how XenForo's permission system works, specifically how Super administrator status interacts with user group permissions.

Super Administrator Status​

Your Super administrator status grants you an unconditional "Yes" for all front-end permissions, regardless of the user group permissions set. Think of it as a master key that bypasses all the locks. This is why you can have a user group where all permissions are set to "No," and it won't affect you. The Super administrator status overrides all other permission settings. This is a failsafe to ensure that you always have full control of the forum, even if user group permissions are misconfigured.

Administrative User Group​

The Administrative user group is a separate entity that, like any other user group, controls front-end permissions. The permissions set within this group would apply to any user who is not a Super administrator but is a member of this group. For example, you might create a "Forum Moderator" user group with specific permissions to moderate a certain section of the forum. The permissions set for that group would apply to anyone in it, unless they are also a Super administrator.

The reason your Administrative user group permissions are set to "No" is likely a measure to prevent users who are in this group, but not Super administrators, from gaining elevated permissions. It's a way of segmenting the roles and permissions.

In Summary​

• Your Super administrator status provides an unconditional override for all permissions, both in the ACP and on the front end. It's the ultimate permission.
• The Administrative user group permissions you see are for other users in that group who do not have Super administrator status.
• Your Super administrator status essentially makes the permissions set for any user group you're in irrelevant to your account.

In essence, your Super administrator status is the permission that matters most for your account, overriding all others.

 

[Kirby]

Can you @Kirby confirm in the following AI explanation is correct?

No, it's partly (or even mostly?) nonsense

Your Super administrator status grants you an unconditional "Yes" for all front-end permissions, regardless of the user group permissions set.

This is nonsense. Being aa super amdinistrator does not grant any frontend permissions, it also does not override a Never set for a usergroup you are a member of.

Think of it as a master key that bypasses all the locks.

Not directly, but indirectly:
As a Super administraotr you have all administrator permissions, as such you can change all settings and permissions - obviously including your own frontend permissions.
So if you don't have a spefific fontend permission, you could just change the permission setup.

This is why you can have a user group where all permissions are set to "No," and it won't affect you. The Super administrator status overrides all other permission settings. This is a failsafe to ensure that you always have full control of the forum, even if user group permissions are misconfigured.

This is nonsense as well.

The Administrative user group is a separate entity that, like any other user group, controls front-end permissions. The permissions set within this group would apply to any user who is not a Super administrator but is a member of this group. For example, you might create a "Forum Moderator" user group with specific permissions to moderate a certain section of the forum. The permissions set for that group would apply to anyone in it

This is correct.
But "apply" does not necessarily mean it will be the effective permission for a user.

Example
A user is a member or Registered, Administrative and "Disallow avatar upload".
Usergroup Adminstrative has Permission Upload an avatar = Yes, usergroup "Disallow avatar upload" has this set to Never.
The effective permission for taht user will bo No, no matter if he is super admin or not.

unless they are also a Super administrator.

... and this is wrong.

The reason your Administrative user group permissions are set to "No" is likely a measure to prevent users who are in this group, but not Super administrators, from gaining elevated permissions.

No. The reason why many permissions are set to No is because those are (usually) set to Yes for Registered so it's not necessary to have them Yes as well for Administrative (if you follow the recommended permission design, eg. every user is primary Registered).

It's a way of segmenting the roles and permissions.

Correct.

Your Super administrator status provides an unconditional override for all permissions, both in the ACP and on the front end. It's the ultimate permission.

No. It does not automatically grant any frontend permissions.

The Administrative user group permissions you see are for other users in that group who do not have Super administrator status.

No.

Your Super administrator status essentially makes the permissions set for any user group you're in irrelevant to your account.

No, not directly. But as stated before you can change any permissions as super administrator.

In essence, your Super administrator status is the permission that matters most for your account, overriding all others.

No, not directly. But as stated before you can change any permissions as super administrator.

XenForo permissions system isn't really that difficulet once yo got it.

Basically you need to know just 4 things:

1. Frontend permissions can be idividually set per user or usergroup
2. All permissions sources are taken into account
3. Yes overrides No
4. Never is a final permission, once this gets into the calculation from any source the final result is No and cannot be overridden

 

[Grover]

Thank you @Kirby for your extensive explanation.
I am gonna testdrive everything you explained on my testboard, concerning the Super Administrator permission and if I feel the need I will report back my findings here (so people can learn from it).

I believe it would be helpful for people totally new to administrating Xenforo (like myself) (and also who make the switch from vBulletin to Xenforo) if there would be a consolidated document/FAQ where all these things are explained. I did read the manual, but could use more in depth information indeed on the subject matter of permissions.

 

[Grover]

Banned Usergroup permissions have changed after import to Xenforo

See the screenshots. I noticed that quite a few permissions inside the Banned Usergroup were suddenly set to YES, after the import to the XenForo testboard. In my live vBulletin board, all these settings are set to NO.

I might overlook something again (since I am totally new to administrating XenForo and dealing with an import), but why have these specific permissions changed to YES?

Furthermore, all these post- and thread permissions that are now set to YES for the Banned Usergroup have no effect on banned users anyway, right? When a user get’s banned, he/she get’s a banned “status” so to speak from being banned via a ModCP or AdminCP. And when you get that status you can not access the board anymore. So all these permissions inside the Banned Usergroup have no effect whatsoever. Since your banned status overrules all these Usergroup permissions, if I understand it correctly.

 

[Grover]

(Tiny thing)

I noticed that the forum descriptions were not visibly displayed, when viewing the forum on a desktop PC. This made the whole forum overview appear quite bare bones. The forum descriptions did however appear inside a tooltip when you hover over them, just like overhere at xenforo.com

My forum descriptions are not so extensive, so I put the appropriate setting “Description display style” on Inline

It says in the ACP concerning this setting:

To save vertical space, it is possible to hide node descriptions until the node title is hovered, at which point they are displayed in a tooltip

I noticed this: when the setting is on Tooltip , it only applies to viewing your forum on a desktop PC. Because on Safari on iPad, the forum descriptions are displayed inline regardless. And on Safari on iPhone, the forum descriptions are not displayed, regardless of this setting.

On iPad this makes sense that there is no tooltip, because without a mouse how would you be able to mouse over the forum to reveal the tooltip description? On iPhone it makes sense to that there is no description displayed, because that would take up way too much space.

 

[USCSS_Nostromo]

Banned Usergroup permissions have changed after import to Xenforo

See the screenshots. I noticed that quite a few permissions inside the Banned Usergroup were suddenly set to YES, after the import to the XenForo testboard. In my live vBulletin board, all these settings are set to NO.

I might overlook something again (since I am totally new to administrating XenForo and dealing with an import), but why have these specific permissions changed to YES?

Furthermore, all these post- and thread permissions that are now set to YES for the Banned Usergroup have no effect on banned users anyway, right? When a user get’s banned, he/she get’s a banned “status” so to speak from being banned via a ModCP or AdminCP. And when you get that status you can not access the board anymore. So all these permissions inside the Banned Usergroup have no effect whatsoever. Since your banned status overrules all these Usergroup permissions, if I understand it correctly.

ChatGPT is a good tool when writing small pieces of code, but it cannot fully answer questions about how a forum works.

For example, you wrote above about a "banned group".
In XenForo, there is no banned user group. You see it only because you imported it from vBulletin.
If you install XF from scratch, you will see that such a group does not exist.

https://xenforo.com/docs/xf2/groups-permissions/

1. Unregistered / unconfirmed
2. Registered
3. Administrative
4. Moderating

That’s it. There are no more groups.
Your banned users group will not work.
Yes, it will only contain users you banned on vBulletin.
But it will not include users you ban on XF. Will you have two sets of banned users?

What’s the point of this group? Why assign any permissions to it?
In XF it’s simple - a banned user cannot do anything. He doesn’t even deserve to have a group.

If you want to have a separate group that includes those you have banned, you will need to look for an add-on for this. Alternatively, you can manually add each user there.